Well I've been using VS.NET 2005 for a while now and in general I'd have to say that they've done a good job with the update. However there are a number of little usability "enhancements" that they've added that drive me nuts. They've also managed to loose options that used to be available. One of the biggest complaints I have is the forced memory of collapsible state in the editor. I use a very specific file layout so that the outlining system really helps me see the class and it's members. With 2003 each time I closed the file it would reset the outlining so that it was fresh each time. I like this. Certainly there are those that didn't so Microsoft changed the behavior to allways remember the collapsible state of the document between editing sessions. I hate this! Oh it's not so big to prevent me from using the editor but I should be able to turn this off. I think all new software should try as much as possible to allow users to configure it ro run like the older versions as desired. I mean, how hard would it be to add a simple toggle option to let the user choose. In fact I posted a request to their dev team and the response was - "Too late in the development cycle and there aren't enough developers that care." So, I'm asking all those that want the option like I do, to voice their opinion on their site.
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=2e5207f3-57dd-43b9-b673-0074b102075b
I'd also encourage you to post other requests as you see fit, it's a great way to get involved. I've had the opportunity to report a couple bugs and they've been great about fixing those, but feature requests need a real "show of force".
One of the things I routinely do when building websites or applications is develop a utility library that handles mundane, but common stuff. While building out the XHEO line of products I've built a pretty extensive library of stuff. We've been publishing the library for free for quite some time but we've just recently pushed an update to the site. We don't do it frequently, but I was talking to Robert McLaws about the need for a tri state value. I've been using a custom version for some time now and never really thought to let anyone else know about it. Anyway, its in the latest post and has some neat features like implicit casting to/from a literal boolean value so that you can use it like a regular boolean value.
Check out the free library on the XHEO website.
Download the library now.
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.