One of the things that I find most tedious is typing certain constructs over and over again. We've got collection generators now, but what about entire funtions? Comment Blocks? Other Standard Classes? There are a few other generic generators out there but I've found something that I really like that is a bit more universal. It's a little program called As-U-Type. It watches your key-strokes and responds to certain patterns (Well actually it's a resident spell checker that I use for stroke-recognition). So when I want to create a new colleciton I just type .collection. and it spits out the template in code as if I typed it. (OK I typed that just now and it spit the code out for me in this entry...see it works in any program which is what makes it so cool).
Anyway for those interested just go to www.asutype.com and get the free trial.
Just another thought I'd throw out. I was wondering how many developers actually use
FxCop? We use it continually throughout the development process to catch problems early and to adopt better programming practices. Anyone else use it on a regular basis?
My good friend Robert McLawsy over at Interscape has finally convinced me to share some of my ideas and ramblings with more than just him. Since I've tried to be an active participant at asp.net forums I've received a lot of questions from developers on how I accomplished certain things, how to do something right, etc. So I figured I'd just answer some of them publicly.
One of the biggest frustrations as a developer for a component vendor is minor upgrades. If while working on a bug for a customer you make changes to your code, the last thing you want to force them to do is recompile their application and distribute it to all their customers. I'd really like to be able to give them an updated assembly that works out of box. In the old days that was no problem, just ship a new DLL with all the fixes...which of course introduced a whole slew of problems collecively known as DLL Hell. Microsoft has done a stunning job putting together the .NET Framework, but versioning remains a difficult problem. The versioning scheme that they have built into the framework works wonderfully for application developers that have control over the entire installation process. However when you're a component developer your options are some what limited.
Publisher Policy File
When I first came across this in the framework, I figured that would basically solve all the various versioning problems. I figured, fine when we release a component update, we'll include a publisher policy file with it. However we found that distributing the policy file required a higher level of understanding of the framework than many of our customers had. It also doesn't work for web deployed components when the customer is on a shared host - as they don't have access to the GAC. The end customer could of course always update their .config files with the assembly binding information, but again that is a support nightmare.
Couple Options, Pros & Cons
If you opt not to use a publisher policy file you have a few options available. I'll share my experience with each, but of course for each vendor YMMV.
- Increment the assembly version and require your customer to recompile their application. Pros: Simple and clean. It also follows the recommended versioning policies in the documentation and the generally feeling of .NET all together. Cons: Requires a recompile. If your component is used only one level deep that's no problem (Your customer uses it directly), but if your customer uses your component in an application they sell this becomes a problem since the entire application (or config files) must be redistributed. If two assemblies use different versions of the same component they cannot be used on the same website, even with a policy redirect in the .config file since their can only be one DLL with the same name in the \bin folder. One option with that of course is to add additional private search paths but that's another support nightmare.
- Don't increment the assembly version at all. Pros: You can just copy over any existing assemblies and they will be used immediately. Cons: Introduces much of the same incompatibilities that were commonly found with DLL Hell. Also makes it very difficult to determine which version of an assembly a User is referencing when trying to troubleshoot.
- Increment only the AssemblyFileVersion. Pros: You can just copy over any existing assemblies and they will be used immediately. You can still tell which version of the assembly is being used during trouble shooting. Cons: Still potentially opens the door to DLL Hell style problems - especially when you install the assemblies in the GAC. You'll get no help from the .NET runtime in resolving versioning conflicts.
What I recommend
If you are developing applications I'd just increment the assembly version and keep as much out of the GAC as possible. Ideally, you should be able to distribute a ZIP file that when extracted will run from any directory. If you're developing components, not-for-resale, I'd still recommend versioning the assemblies directly. If you're developing components for resale you have to get a gauge on your customers. Personally, we've found that incrementing the AssemblyFileVersion allows us to provide quality support without compromising too much versioning control. We also distribute Windows Installer Merge Modules with our components so other vendors can include them in their installer packages and have the assemblies installed (version protected) propertly.
OK, well that's a lot for my first post but that's what's been on my mind of recent. I'll be posting more. BTW, if you have a question I'd love to ponder it for a while.