Browsing on codeproject

Codeproject is a tremendous ressource to provide some good examples on how to deal with certain problems/technologies. For that matter, you usually would want to download the sample-code provided by the author and just go right to the source.

This typically involves a number of repetitive steps: browse to the article, download the source, unzip it to a unique directory, open it with Visual Studio and finally review the code with the article.

I just stumbled across a knowledge-base entry, which originally dates back to 2007. This article introduces a codeproject browser extension to visual studio. So now you can just download the source from within visual studio jump to the project and reference back to the article – all without leaving Visual Studio – this is cool.

Show them keys

If you’re a keyboard-shortcut-junkie just like me, you want to have all your currently assign keybindings memorized … but there’s a way to supply you some kind of cheat.

With this little macro you can list all currently active keybinding of visual studio:

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports System.Diagnostics
Public Module KeyboardShortcuts
Function GetOutputWindowPane(ByVal Name As String, Optional ByVal show As Boolean = True) As OutputWindowPane
Dim window As Window
Dim outputWindow As OutputWindow
Dim outputWindowPane As OutputWindowPane
window = DTE.Windows.Item(EnvDTE.Constants.vsWindowKindOutput)
If show Then window.Visible = True
outputWindow = window.Object
Try
outputWindowPane = outputWindow.OutputWindowPanes.Item(Name)
Catch e As System.Exception
outputWindowPane = outputWindow.OutputWindowPanes.Add(Name)
End Try
outputWindowPane.Activate()
Return outputWindowPane
End Function
Sub ListCommands()
Dim outwin As OutputWindowPane = GetOutputWindowPane("List Commands", True)
outwin.Clear()
For Each cmd As Command In DTE.Commands
Dim bindings() As Object
bindings = cmd.Bindings
For Each binding As String In bindings
outwin.OutputString(cmd.Name.ToString() + vbTab + binding + vbCrLf)
Next
Next
End Sub
End Module

IntelliSense for MSBuild community tasks

OK, you probably know it by now … there is a whole lot of stuff writte in nice angle-brackets, but there is way to little intellisense support for all this.

Just like others (NHibernate, WCF) the solution is quite simple: just copy the appropriate xsd file to C:\Program Files\Microsoft Visual Studio 9.0\Xml\Schemas\1033. In this case the MSBuild.Community.Tasks.xsd can be found in C:\Program Files\MSBuild\MSBuildCommunityTasks.

Pluggin NHibernate into Visual Studio

OK, so you’ve managed to work with NHibernate as well as with the hbm-files; respect!

But after looking at Visual Studio 2008, and at what ease you can create some domain-model using Linq to SQL …

But wait! NHibernate Plugin offers a visual aid to get your mappings done.

As always there seems to be some catch 🙂 I’m running a german localized version of Visual Studio 2005, so my item-templates should reside in a folder below my language-code (1033 instead of 1031). Unfortunatly the installer does not recognize my locale, so the item-templates are placed in the wrong directory. Just move the Nhibernate.zip from C:\Programme\Microsoft Visual Studio 8\Common7\IDE\ItemTemplates\CSharp\1031 to C:\Dokumente und Einstellungen\[USERNAME]\Eigene Dateien\Visual Studio 2005\Templates\ItemTemplates\Visual C#\1033 and the item-template will show up 🙂

LC.EXE exists with an error

Today I experienced some strange error with LC.EXE of Visual Studio 2005. So far my project was always building just fine, but all over sudden I was getting an error, that LC.EXE was existing with code -1. So what the heck is that supposed to mean?

Well, after checking everything in my code, and what I did in the last couple of days.

So one or two hours later it came to me … the license.licx was referencing to an assembly that did not exist (anymore). After cleaning out the invalid assembly every worked like a charm again.

Versioning Assemblies with MSBuild

OK, so I try doing more with MSBuild … like: bumping the version number of my assemblies 🙂

So far so good – so let’s get startet. First of all you need to grab a AssemblyInfoTask extension for MSBuild. Just install it and you’re all set.

Next you have to modify your *.csproj file. Just add:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\AssemblyInfoTask\Microsoft.VersionNumber.Targets"/>

to the end of the file. OK, this could already be all. But wait – what are all those errors in my newly build?

First I use subversion for source-control, so I have an addition AssemblyInfo.cs somewhere in my .svn folder-structure. This is not working with the AssemblyInfoTask :(. So navigate to your ‘$(MSBuildExtensionsPath)\Microsoft\AssemblyInfoTask\Microsoft.VersionNumber.Targets’-file and edit it (with notepad or whatever). Then lookout for the itemgroup defining the files to process and modify it to exclude any .svn folders. This could look like this:

<!-- The items that get processed by the task -->
<ItemGroup>
<AssemblyInfoFiles Include="**\AssemblyInfo.*" Exclude="**\.svn\**\AssemblyInfo.*"/>
</ItemGroup>

OK, for now you’re set – it compiles!! At least kinda. So next you’ll get some error about the version-number not being correct. Well no error without a fix :). There have been quite some discussions about this problem and a lot of various fixes. Well, Neil explains in his blog about why this is, and makes the point “So, I’m sad to say, we will be stuck with 16-bit build numbers forever.”. So this means no cure for this error.

OK, for me I just wanted to control the version number of my assemblies from outside visual studio. So I want to fix the version number. So I though adding the properties:

<AssemblyBuildNumberType>NoIncrement</AssemblyBuildNumberType>
<AssemblyFileBuildNumberType>NoIncrement</AssemblyFileBuildNumberType>

would do the trick. But far from right. I still would get at least incremented revisions. Looking at the code I noticed that:

<AssemblyRevisionType>NoIncrement</AssemblyRevisionType>
<AssemblyFileRevisionType>NoIncrement</AssemblyFileRevisionType>

would solve my problems. So my complete PropertyGroup looks like this (with a version number of 2.1.1.1 for my Assembly, and 1.0.0.0 for my File-Version):

<PropertyGroup>
<AssemblyMajorVersion>2</AssemblyMajorVersion>
<AssemblyMinorVersion>1</AssemblyMinorVersion>
<AssemblyBuildNumber>1</AssemblyBuildNumber>
<AssemblyRevision>1</AssemblyRevision>
<AssemblyRevisionType>NoIncrement</AssemblyRevisionType>
<AssemblyBuildNumberType>NoIncrement</AssemblyBuildNumberType>
<AssemblyFileRevisionType>NoIncrement</AssemblyFileRevisionType>
<AssemblyFileBuildNumberType>NoIncrement</AssemblyFileBuildNumberType>
</PropertyGroup>

You might notice that I don’t set the Assembly-File version in the PropertyGroup. This is still managed from visual-studio (you don’t have to understand why I would wanna do this).

Debugging multiple applications

Well, the more complex the application context becomes, the more complex becomes the debugging process.

Since the remote-debugging of .Net 2.0 based applications has been dramatically improved this isn’t any challenge anymore. But there is hope: suppose you have an application, which consists of a console-application which is providing services via WCF and a second application consuming these services. So, how to debug this? Obviously you kneed to debug both apps … but how? Since they have to communicate via WCF (this is the crucial thing!!) this is not as easy as it might seem.

  1. OK, first start your console-app providing the WCF services. Right click on the project and select Debugging\Start New Instance.
  2. Suppose you’re using TestDriven.NET, you just start your main app and choose to test it using the debugger. You should be asked wether you would like to stop the debugging now – this should be answer with no.

Basically that’s all there is to do. But life isn’t always that simple. Because of the multi-threaded (parallel) nature of multiple applications, you might encounter some strange behaviors within Visual Studio …