Real buggy coding night. I'm in the process of putting together a site for myself when I ran into this problem:

http://forums.microsoft.com/msdn/showpost.aspx?postid=98346&siteid=1

Basically "Failed to generate user instance" and "An attempt to attach...failed".

For "An attempt to attach....failed" I was able to get around this by simply rebooting my development machine. Apparently there is some local cache of files stored on the hard drive that SQL Server Express uses and this was getting out of wack - somehow rebooting the system did the trick for me. It went away, but I was not able to identify exactly what caused the problem; to me this is a bad thing - I really like knowing WHAT happens when something goes wrong.

The "Failed to generate user instance" came from me being remoted into work from home (that'll teach me to work from home). Oh well, I guess I get my site done tomorrow.

Hrmph. :-(

We've all been pounded with "beware of SQL Injection Attacks" - yet I found a rather nice blog post here: http://blogs.msdn.com/dglover/archive/2005/06/01/423727.aspx that hands out a nice filter method for SQL Server. You might as well have a look and see if you can introduce it into your stored procedures....

Source: http://msdn.microsoft.com/msdnmag/issues/07/06/WickedCode/.

The main thing to take away from this article is that the UpdatePanel is a great control, but it definitely has its limitations when it comes to efficiency. Why? The article I linked to above does a fairly decent job of explaining why from a high level. The main, core, point to take away is that the UpdatePanel is good for purposes of simplicity; it will take whatever child controls are contained within it and make sure they participate in a partial post-back when one of them - or a control associated with the UpdatePanel - triggers a post-back event.

However, because the UpdatePanel must do so much for you it must believe that every control within it - or associated with it - could, potentially, need to be updated. These controls are mostly valid ASP.NET controls and, therefore, have ViewState that also must be maintained. In short, the UpdatePanel, in an attempt to be complete, will basically perform a pseudo full-postback to the server (even though the response message is optimized for use by the UpdatePanel). I guess, for a lack of a better analogy, think of the UpdatePanel as a mini page all to itself; I guess that somewhat holds up....

....so, bleh. If we're trying to be effecient, what do we do?

There are a couple options (one of which wasn't mentioned in the article but I would like to mention).

1. Utilize PageMethods. PageMethods are static methods of your ASP.NET page class that are treated as web service'able methods. You can reach those methods through your script and the PageMethods proxy class: yet another proxy class auto-generated by the ScriptManager and its bretheren.
   
2. Use a standard web service. If your ScriptManager has web services registered with it, it will auto-generate proxy classes for use when calling those methods from javascript. What this enables you to do is basically script against those methods.
   
3. And, the one that was left out - use the asynchronous scripting methods of ASP.NET AJAX:  http://ajax.asp.net/docs/ClientReference/Sys.Net/WebRequestClass/default.aspx

...being somewhat of a gearhead, I like the WebRequest class because it gives me absolute control over things; but it's definitely overkill for 99% of all uses (it's what Microsoft used to build the UpdatePanel and the asynchronous page-framework of ASP.NET AJAX). Basically MS "dogfooded" the WebRequest class for all async behavior in ASP.NET AJAX.

This last TechEd I went to a session on getting work as an independent consultant and ever since then I have been really focused on optimizing not only my own searching but that of other consultants. A couple more things I would like to mention:

1. If you have no problem getting certified for a security clearence, the government is hiring right now. People at the session really pushed the fact that the government is really looking into independent consulting at the moment (for one reason or another), and that it might be a good opportunity for independent developers.
2. Charity is, suprisingly, a good option. Even though you may not make a lot of money (or any) helping out a charity, charities have benefactors - people that donate money - and your good deeds go noticed. Benefactors do have money; doing a good job for something a rich person cares about might have its benefits.
3. Staffing agencies are there to help. Staffing agencies like this one: http://www.teksystems.com/Services/Staffing-Services/Default.aspx are there to link up parties. These people, obviously, take their cut, but it's a great way to get started. Remember - beggars can't be choosers.

...just a few more things to think about.

In my opinion, what seperates the "wo/men from the mice" in the world of software development is the tools. I have known some incredibly brilliant individuals who could wip out some of the cleanest, fastest algorithms I'd ever seen,  yet they were burned when it came time to develop real-world software because somebody with half their talent knew how to engage the debugger in the right fashion, or they knew how to use perfmon, etc. etc. etc. These days my mantra is "Resist the urge to overcomplicate your life", and if you're a developer, that often means getting to know your tools a bit better.

A few questions to ask yourself:

1. If you were developing a heavily multithreaded application in .NET (client-side) and it deadlocked on a test machine, would you kill the process and inspect the debug logs or would you attach a remote debugger to the process and identify exactly where the threads were hung?
   
2. If you had code that needed to be transferred from one developer to another (say you had a bit of source you wanted to share), would you email it to them as a copy-paste and leave it be from there, or would you instruct them how to use code-snippets in Visual Studio to better the source and share it with everyone else?
   
3. How many know how to use WinDBG? SOS (Son of Stike)?
   
4. Do you have debugging symbols enabled on your machine and those of your testers? Do you have a symbol server? Do you know what that is?
   
5. When was the last time you enabled tracing in your ASP.NET application to fix a performance issue? Did you immediately hit the source code or did you let the tools work for you?
   
6. FXCop?
7. Have you ever ran your application against perfmon? Have you ever used perfmon's remote machine feature?
   

The list goes on and on. The important thing to remember, though, is that at the end of the day you will have to fight with code that is insanely complicated, distributed and (often) not yours - if you try to fix/find/discover/analyze a code problem through code, you're probably looking at it from the wrong level; there are many, many great applications out there (for free or that come with Visual Studio) that will mitigate your problems and reduce the amount of time needed to identify bugs.

So, before you start your next task ask yourself if you're doing everything you can to not overcomplicate your life....

http://msdn2.microsoft.com/en-us/library/ms364069(vs.80).aspx

Writing code that is fully interoperable with two different runtimes can blow; 'nuff said. The single-most valuable thing to remember when doing COM interop (in my opinion) is to add your damn .NET module to the GAC. Why?

The reason lies in the internals of COM, and if you've ever had the distinct pleasure of pounding your head against the desk while working on COM you'll quickly understand what I'm trying to say. COM was built with the ideals of interoperability in mind: so long as the two, distinct components stuck to a particular contract-based communcation (through "interfaces") then everything worked nicely.

In COM to get at a particular bit of functionality (which is exposed via an "interface") you must get at the Com Class (coclass) which implements the interface. A particular COM server houses the Com Class (coclass) which implements the interface. Basically, to get at functionality, then, you must locate the physical module, then ask the physical module to activate a particular "object" and then ask the "object" for an interface pointer to the functionality; the rest is done through vtable pointer arithmetic (this is all if you're using "IUnknown" semantics, otherwise the game is slighty different).

.NET interops with COM by having the mscorlib.dll module be the server - it is responsible for loading the necessary DLL files that implement your .NET functionality and doing all the proper dirty work of interoperating with COM. Say you have a COM plugin, then, for some application - but the plugin is written in VB.NET. The main application attempts attempts to create a com instance (through CoCreateInstance()) of your .NET module - this routes the COM runtime to Mscorlib.dll which attempts to locate your DLL; however, how does Mscorlib.dll find it? Well, if you haven't placed it directly next to (in the same directory as) the main application or in the GAC, MScorlib.dll will not be able to find your module and you're, effectively, "dot screwed".

....by placing the module in the GAC you'll be able to guarantee mscorlib.dll will find your module.

I am going to be published in MSDN this September on the internals of the ASP.NET AJAX ScriptManager control. For those that are currently reading this blog and have an interest in other subjects related to this topic, please feel free to comment and/or drop me a line (ben@sideshowsystems.com).

I've got another article in the works (another reason why blogging has been so sparse lately); but again no reason to believe it'll make it to MSDN again, but I'll try. I promise I'll try to post more regularly here too.

I'm a consultant, and as a consultant I spend a great deal of time concerning myself with the "next job". I may not always be a consultant (I don't believe it's related in any way shape or form to my eagerness to be one, just that times change, etc) but for the time being I am one and so must constantly be on the outlook for the next great "gig".

How do you go about getting a consulting job? Well, for me the challenge is my locality. I'm located in Nebraska which, for the most part, is a relatively barren wasteland for modern technology. Most of my "gigs" have been acquired through word of mouth and diligence on my part to help people in times of need when they requested it - you treat someone well and they'll treat you well back, it's the basic law of the land.

First - I would not look on sites like rentacoder.com. I have tried it, and I don't like it. Why? The reason is simple, for the most part people you will find on rentacoder (on both ends of the spectrum: developer or "buyer") are unrealistic. It's not their fault; they're not "stupid" in any way shape and or form, they're just somewhat naive about the nature of software and how much it costs to develop something correct. Take this for example: say you find someone on there who bids for a full-featured ASP.NET site for $20.00 (I've seen it); chances are they will be back bidding again in a month or two to correct the myriad of mistakes the $20.00 wunderkind caused.

Oh well.

Second - I would join local organizations, clubs, etc. and become active members of them and rub elbows with business-folk. One thing we, as developers, are relatively poor at is communicating with the outside world. You can make a business person fall in love with you if you express, in some way, an appreciation for their situation and, especially, a firm understanding of it. At the end of the day everyone is out for the same thing in business: to make money. Being an active member of this world will clue business people onto you as someone who "understands" the needs and processes of real-world business software. Remember, the stereotype most business dudes have of us is that we're cowboys - loose cannons who sleep by day and hack by night. For the most part they treat you as a risk - you wield a black magic that they do not understand; do not use this force for evil, use it for good.

Third - Do things with the end in mind. You have a choice as to whether you get yourself certified as a Microsoft developer or master your latest XBOX game. Look at your resume' and think about what it says about you - as a person. Does it project someone willing to explore the depths of a project for someone, or not?

Fourth - have a reachable presence. I'm not promising I'll be doing this consulting stuff in a year, but I am promising that as I continue to write, and continue to learn, I will continue to grow my presence/influence wherever and however I can.  This means things like blogging, speaking, writing for magazines, etc. The first step is always advertising your presence because without a presence you cannot be reached, period (well, duh).

Fifth - try your damndest to say atop of the needs of your area. Note how I say, "Of your area" - this is extraordinarily important. Areas differ on their needs and requirements for software; different places require different talents - you will succeed if you have a good rap sheet and expertise on those needs. Consider that and ask around, talk, discover, etc.

...I think the most important thing to take away is opening the lines of communciation, being accessible and being real. Believe it or not, but if you can make those things happen you can probably (probably) make it as a software consultant.