Slow Cheetah - XML transforms for config files

Today I have found another nice visual studio extension: Slow Cheetah. Using this extension you can transform configuration files during the build. It's really useful if you want to change the contents of your config files depending on the build configuration, e.g. adapting connection strings, paths, hostnames, wcf settings etc. With Slow Cheetah you can transform all kind of configuraion files in your project not only the app.config or the web.config.

Change the Target Framework for all Projects in a Solution

There is a great Visual Studio macro written by Scott Dorman that can be used to automate the changing of the target framework of all projects in a visual studio solution: Visual Studio 2010 and Target Framework Version. The macro is available on Scotts Sky Drive: ProjectUtilities.vb. Download it to \Documents\Visual Studio 2010\Projects\VSMacros80\MyMacros. Then open the the Macro IDE (Alt+F11), add the downloaded .vb file to MyMacros and run it. The solution must be opened in Visual Studio when you run this macro of course. The macro works well with 4.0 as target version (haven't tested it with other framework versions yet). Have fun!

ReSharper: remove unused references.

Today I was cleaning up unused references in a Visual Studio solution. Thanks to ReSharper it was not as tedious as I fought at first. Another great feature provided by this tool saved me a couple of minutes (or maybe hours):  http://www.jetbrains.com/resharper/features/navigation_search.html#Find_ReferencedDependent_Code.
To use it select the referenced assembly in the solution browser and choose "Find Code Dependent on Module" from the context menu. If the assembly isn't used anywhere in the current project ReSharper will show a message box saying: "Code dependent on module XXXXXXX was not found". In this case you can remove this reference safely.

Magic GUIDs, ReSharper and more...

Here are some tricks I discovered today:

• Magic GUIDs: Creating unit tests in Visual Studio is quite easy when you are doing it 'the right way'. But sometimes when I want to write tests first and create a new project for them I mistakenly choose the class library project type instead of a unit test project. However these are two different project types so when I try to run my tests from the class library project the Visual Studio won't find them. Fortunately you can convert an existing visual studio class library project to unit tests project: http://blog.drorhelper.com/2008/12/how-to-convert-net-class-library-to-ms.html
• ReSharper: There is a great new feature in ReSharper 5.0 called value tracking.
• Another nice ReSharper feature useful when you want to restructure you code: Move code elements up and down: [Ctrl]+[Alt]+[Shift]+[Up|Down]. You can move single lines but also entire methods.
• Sourcemaking: A website with lots of stuff about design pattern, antipatterns and refactoring: http://sourcemaking.com/

Auto-incrementing version numbers with Visual Studio

There are lots of web sites describing how to achieve this. Surprisingly most of them are "roll your own" solutions including custom add-ins, MSBuild-tasks or even custom tools.
But there is an obviously little-known feature in Visual Studio that allready provides this functionality. All you have to do is to edit the AssemblyInfo.cs file in project. Just replace the line [assembly: AssemblyVersion( "1.0.0.0" )]; with [assembly: AssemblyVersion( "1.0.*" )]; and remove the line [assembly: AssemblyFileVersion( "1.0.0.0" )];. You still have the possibility to manually set the major and minor version numbers (first two numbers). The build and the revision number (the last two) will be incremented automatically after each build. Thanks to Marc Charbonneau for telling the world ;) about this feature in his blog.
Edit: It seem like the auto-incrementing the assembly version has an annoying side-effect when applied to an assembly with custom ui controls or WF activities: https://connect.microsoft.com/VisualStudio/feedback/details/568672. The Visual Studio fails to release the handle to that dll during the build.