.Net Portal – Links to .Net Resources

http://www.kraftsoftware.com/portals/0/dotnetportal.htm is a simple web site that provides links to some of the best .Net resources including podcasts, videos, tutorials, conferences, books, blogs, and tools.

Post Build steps for both 64bit and 32bit development

We recently upgraded a developer workstation to 64bit windows and learned that our project post-build steps did not work because the folder names are different.  To remedy this problem we replaced the post build with a call to a batch file that gave us more control over the post build logic.

The post build in most of all our projects now only contains something like this:

Call “c:\dev\Postbuild.bat” $(TargetPath) $(ProjectName) ourProjectName

The “Call” command is always recommended for invoking batch files.  We hard-coded the folder that contains the .bat file.  The 3 pieces of data following that are input parameters to the DOS batch file.

To install to the GAC on the 64bit or 32bit machines, our batch file has this code:

IF EXIST “c:\Program Files (x86)\”. (set gacexe=”C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\gacutil”) ELSE (set gacexe=”C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\gacutil”)

%gacexe% /u %3
%gacexe% /if %1

To copy files to the correct nunit folder we have code in the batch file like this:

IF EXIST “c:\Program Files (x86)\”. (set nunitdir=”c:\program files (x86)\nunit\bin\net-2.0″) ELSE (set nunitdir=”c:\program files\nunit\bin\net-2.0″)

echo off
xcopy %1 %nunitdir% /Y

I hope someone else gets some value from this.

Running Nunit post Visual Studio 2010 and .Net 4

Prior to our upgrade to Visual Studio 2010 and .Net 4 (which also forced us to upgrade Nunit), we were able to easily launch nunit.exe from a visual studio project by setting the “Start external program” property on the debug tab to the nunit.exe.  From there, we could set break points and step through our nunit  tests.  But after all of our upgrades, we find that setting break points and doing step through debugging is not so convenient, though certainly still possible.

For starters, we need to specify that our projects launch nunit-x86.exe instead of nunit.exe in the “Start external program” of our projects.  Then you can run the project which will launch nunit-x86.exe.  Before running a test, go to Visual Studio and select “Attach to Process” from the debug menu.  Select the process named nunit-agent-x86.exe.  Then you should be able to set your breakpoints and hit them for step through debugging.

If you find the above does not work, check the following:

1) Use task manager to kill any instances of nunit-agent-x86.exe.  This can easily be left hanging in memory if you stop a test by ending the debugging session in Visual Studio rather than closing the nunit-x86.exe through its normal program close method.  If nunit-agent-x86.exe is already running you are likely to see a message “System.ApplicationException” “Unable to find test  in assembly”.  “Assembly Not Loaded”.

2) If you are still unable to hit breakpoints, then open nunit-x86.exe and go to the Tools – Settings and select the Assembly Reload section under the Test Loader section.  Make sure that only the “Reload when test assembly changes” option is checked.

Happy debugging!