I've been playing around with Visual Studio 2010, and of course the latest ReSharper, version 5. Unfortunately my NUnit tests wouldn't run inside the ReSharper runner. Instead they would spin for a second then turn grey, like nothing happened.

Running the tests under the debugger turned up an interesting exception in the VS output window: BadImageFormatException. I also noticed a bunch of DLLs being loaded out of the v2.0 framework GAC, and not .NET 4. Shouldn't my .NET 4 app be using the .NET 4.0 GAC?

<!-- Needed in dev10, not needed in dev9/8 --> <startup> <requiredRuntime version="v4.0.21006"/> </startup>

Now you can run unit tests via ReSharper in VS 2010 beta 2.

Ive spent the last couple of days writing visual studio web tests to create a load test scenario for a critical section of application. Unfortunately i find it repetitive and boring.

The web tests recorder in VS doesn't capture everything and additionally it hurts to look at the produced code. I did find fiddler much better at recording tests but they still needed serious cleaning up.

I wish there was a more polished tool for this kind of test. I doubt other tools like JMeter are much better, and for .NET their probably worse because of viewstate and other platform specifics.

I just found another useful thing that resharper does for you, it can generate code to check for null method parameters.

Just put the cursor on the parameter….

Nice huh!?

Thanks to Justin Burns who submitted the required code changes to upgrade my MsTest plugin to ReSharper 4.5.  I just applied the patch and posted the new plugin DLL.  For those of you who wonder why you would use this over the JetBrains provided MsTest runner, one word: speed.

This has been pretty low on my priority list since I don’t use MsTest very often anymore since converting of all but one of our test projects to NUnit, but for the rest of you, enjoy!

I finally downloaded Simian today to give it a test drive, and already I think I'm going to love this tool. If you don't know what Simian is, its a tool to automatically locate duplicate lines of code and any good programmer should love to delete duplicated code, which where I work is pretty important. 

Simian being a console application is pretty useful, but being able to click a button from Visual Studio, see the output in the output window, and then being able to navigate to the duplicated lines by double clicking is what I really wanted.  So that's what I did, I created a Simian output formatter that transforms the output to MSBuild formatted output that is clickable!  Cool, how do we use it?

Download and copy the formatting tool somewhere, I put it in my Simian bin directory.  Create a batch file in this same directory, the batch file is used to pipe the Simian results to the formatter because Visual Studio doesn't let you from the external tools menu.  My batch file looks like this:

@ECHO OFF
REM Run simian redirecting output to the MSBuild formatter
C:\"Program Files (x86)"\Simian\bin\simian-2.2.24.exe %1 | C:\"Program Files (x86)"\Simian\bin\SimianMsBuildFormatter.exe

With that out of the way we need to setup Simian as an external tool within Visual Studio.  In this example I will setup Simian for the current file:

Now Simian - Current File will show up in the Visual Studio Tools menu.  With a file open in the editor we just need to click our new menu item to run Simian and get our output. Here's an example output run.

The interesting and useful part is that the source files listed in the output are now clickable, just like from the csc compiler.  Happy dupe finding!

Update: Resharper 4.5 beta is out, and it natively supports MsTest.

Update: I updated this plugin to work with ReSharper 4.5

Chances are, if you have ReSharper you're using the built in ReSharper test runner. The Resharper test runner is pretty frictionless assuming you're using one of the open source testing frameworks like NUnit.

If you're stuck using MSTest for some reason, like in my unfortunate case my company has standardized on it... then you're pretty much stuck using the MSTest runner, which really sucks for numerous reasons.

The MSTest runner likes to muck around with vsdmi and testconfig files (or something like that, I can't remember) and is pretty slow. Up until VS 2008 it was almost completely useless for TDD.

Its almost usable in VS 2008, but I still hate the test failure reports. I can't just scan a bunch of grouped tests to see which one's failed and why. To really see why, I have to open a new test report tab in VS. Even more annoyingly, MSTest refuses to find my resource satellite assemblies without additional hoop jumping. I like to call that friction.

After finally having enough of this I decided to create my own MSTest ReSharper 4 plugin (Apache 2.0 license). It was actually quite easy to hook into the ReSharper test infrastructure, especially since JetBrains gives you most of the code to do it in the form of a csUnit plugin. A few deletes and edits later, and I have a functional MSTest plugin.

Not only does it work, it works better. My satellite assemblies are found right out of the gate, reports are inline with the runner, and for a moment I almost lapse back into mistakingly typing NUnit attributes.

Now mind you, its not perfect, but it works really well for my needs. Some gotchas, or differences between the standard MSTest runner and my plugin:

• TestContext is always null, the runner doesn't provide that. Unit tests shouldn't need it anyway.
• AssemblyInitialize is not honored, much like like TestDriven.NET. I get around this using a static initializer in my base class test fixture (I need this for some slow integration tests if you're wondering).
• MSTest seems to create a new test fixture instance between each test run, this plugin only creates a single instance of the fixture. Generally this shouldn't be a problem if your TestInitialize method is written correctly.

Binaries and source are available on my Google Code web site. To install, just drop the DLL into the ReSharper bin\plugins folder and restart VS 2008. Happy testing!

I was going to do some quick coding this morning on a project.  Haha...  2 hours later I still haven't started to write any code.  Why?  Visual Studio 2008 updates which I needed to be able to open the solution and be productive.

1. Installed the TFS client, which took a while.
2. Installed VS 2008 SP1.
3. I had to reinstall VS 2008 checking the "Unit Testing Tools" checkbox (see image).
4. Upgraded ReSharper 4.0 to 4.1
5. Installed the VS 2008 SP1 hotfix (KB958502) to add JScript intellisense support from "-vsdoc.js" files.

Number 3 was a bit strange.  I opened the solution only to find VS complaining about an unsupported project type.  I guess when I initially installed VS 2008 I figured I would never be using MSTest.  If only that were still true.

I installed KB958502 to get intellisense specifically for JQuery, since there is now a -vsdoc.js file available on the JQuery site.

You know, it seems like VS 2008 isn't all that far behind VS 2005 in regards to the number of installation steps/packages required to get a usable environment (at least for this project).

Just today I realized that I'm using a fair number of Visual Studio 2008 addins. Visual Studio is starting to look more and more like Eclipse to me, a general work bench of tools. Which is surprising considering how painful it can be to write a Visual Studio addin in the first place.

So what addins am I using today?

• VisualSVN - Seamless and painless, I almost forget that its there.  If you use SVN and Visual Studio, do yourself a favor and fork over the $50 for it.
• ReSharper 4.0 - My refactoring/template tool of choice.  Coding without Re# is like digging a hole without a shovel.  I also use it to drive my unit tests, but TestDriven.NET is superior IMO.
• TargetProcess - This shows all my current tasks and bugs right from within Visual Studio so there's no need to jump over to my web browser to find work or update status.
• GhostDoc - I use this to bootstrap any XML documentation I might need.
• ActiveWriter - I just installed this, so we'll see how it goes.  I'm going to use this to map some entities to a new view or two.

I really like what Microsoft has done with the web development capabilities of Visual Studio 2008, they seem so much more mature and refined than in previous versions.

For instance, when you open up a new project in Visual Studio 2008 that has been configured to run under IIS, it now asks you if you would like VS to create the virtual directory for you in IIS.  No need to open up inetmgr and manually type in directory paths and virtual directory names.

Not only that, it creates the virtual directory in the correct place which is source control friendly, i.e. in place, not under some c:\inetpub\wwwroot folder like it used to do with Visual Studio 2003.  Microsoft finally figured out that .NET developers actually use source control.

Additionally you can now apply the settings on a per project basis, not on a per developer basis.  This is very handy when you want to share settings between devs, like when you have tests that are dependant upon web URLs.

While looking for information on multi-threaded debugging for Visual Studio 2005, I found this article by Peter Bromberg that has some decent Visual Studio 2005 debugger tips.  Its definitely worth reading over if you use Visual Studio 2005.  I know I learned a thing or two.

One tip I would add to this article is to use the immediate window when debugging.  It seems like all VB'ers know about this one, but relatively few C# developers do. 

The immediate window allows you to evaluate code while debugging.  Lets say I wanted to print out the value of a property in the immediate window, I could do any these expressions:

I find this is often faster than trying to dig through a watch window, especially on a large class.

You can even call code directly from the immediate window, which I think is where it's real power lies.  With this you can create a generic debug method in your code that prints out all the values of a collection, which can then be called from the immediate window passing in any collection.

internal static void PrintAll(IEnumerable coll)

{

    foreach (object item in coll)

        Debug.Print(item.ToString());

}

I created a new utility called ConfigPoke for creating application configuration files from a template and one or more property files.  The property files allow you to create a set of property files in which each subsequent file overrides any settings in the previous.

The input property files are just plain text files with key value pairs, for example:

dbConnectionString        = server=localhost;database=Northwind;integrated security=SSPI
sessionConnectionString = server=localhost;database=AspState;integrated security=SSPI
smtpServer                  = localhost

This allow me to define a base set of shared developer properties and then I can define my own property file for me which overrides just properties, like the local database connection string.  I also define property files for each of my environments I deploy the application too: dev, test, release, live.

This utility integrates tightly with MSBuild and Visual Studio 2005/2008 using it's own target file.  There is also a command line interface for the application that can be used from NAnt or in your deployment process (NSIS in my case).

Per developer configuration happens automatically and is always up to date with the input template and property files with Visual Studio integration.  The output configuration files are conditionally built only if the input templates file or input property(s) files are changed, just like any regular source file in Visual Studio. If a Rebuild action is initiated in Visual Studio, the output configuration files are always rebuilt, even if the input files have not changed.

I've been using this utility for the past week at work, and it has worked really well.  Edit a property and everything just works.  Machine specific settings have proven invaluable especially on my laptop which has a lot of non-standard settings because I usually work disconnected on it.

You can download the MSBuild target DLL, console EXE, and MSBuild targets file from Google Code.  The code and the binary is release under the Apache 2.0 license.

Visual Studio 2005/2008 Integration Outline

1. Import Sneal.Build.ConfigPoke.targets file into your VS project file.
2. Create a ConfigTemplateFiles ItemGroup.
3. Create a ConfigPropertyFiles ItemGroup.

Detailed Visual Studio 2005/2008 Integration Instructions

Include the Sneal.Build.ConfigPoke.targets file in your Visual Studio project file (csproj) using the following element:

<Import Project="Sneal.Build.ConfigPoke.targets" />

With the ConfigPoke MSBuild targets file included, the configuration building will automatically be hooked into the Visual Studio clean, build, rebuild process.

The Sneal.Build.ConfigPoke.targets file requires two MSBuild item groups as input: ConfigTemplateFiles?, and ConfigPropertyFiles?. These must be specified in your MSBuild (csproj) project file. Each ConfigTemplateFiles? item should be the destination filename + some arbitrary extension, I use '.template'. You may also probably want to set the "InProject?" item meta data to false so these templates or property files don't show up in VS solution explorer.

Here's an example ConfigTemplateFiles? ItemGroup? that you would put into your csproj file:

<ItemGroup>
  <ConfigTemplateFiles Include="$(MSBuildProjectDirectory)\Configs\web.config.template"/>
  <ConfigTemplateFiles Include="$(MSBuildProjectDirectory)\Configs\windsor.config.template" />
</ItemGroup>

To create user and machine specific overrides, you can include a base properties file and then optionally include a per user and per machine config, if they exist. This would allow each developer to create their own override properties file which can then be optionally checked into source control. To automatically set this up, you can take advantage of the built in MSBuild properties: USERNAME and COMPUTERNAME.

Here's an example ConfigPropertyFiles? ItemGroup? that you would put into your csproj file:

<ItemGroup>
  <ConfigPropertyFiles Include="$(MSBuildProjectDirectory)\Properties\App.Properties.base"/>
  <ConfigPropertyFiles Include="$(MSBuildProjectDirectory)\Properties\App.Properties.$(USERNAME)" Condition="Exists('$(MSBuildProjectDirectory)\Properties\App.Properties.$(USERNAME)')"/>
  <ConfigPropertyFiles Include="$(MSBuildProjectDirectory)\Properties\App.Properties.$(COMPUTERNAME)" Condition="Exists('$(MSBuildProjectDirectory)\Properties\App.Properties.$(COMPUTERNAME)')"/>  
</ItemGroup>

Note: You cannot pass in non-existant property files to the ConfigPoke utility, hence the Condition check above.

Optionally you can specify a ConfigPokeDirectory? and a ConfigOutputDirectory? property to override the default directories. The ConfigPokeDirectory? property should point to the directory where Sneal.Build.ConfigPoke.MSBuild.dll is located on your machine, if not specified this property will default to the current MSBuild project file directory. The ConfigOutputDirectory? property should point to the directory where the output configuration files are written too. If not specified this property will default to the current MSBuild project file directory.

For additional usage see the example in SVN, http://sneal.googlecode.com/svn/trunk/ConfigPoke/Sneal.Build.ConfigPoke.Example/Sneal.Build.ConfigPoke.Example.csproj

I have no proof of this other than my changes weren't showing up, but it seems like MSBuild project files that are directly imported into a project are cached in Visual Studio between builds.  I had to make changes to my imported build script, exit Visual Studio, then restart VS before my changes would take affect.  Luckily if you build from the command line this doesn't happen.

ReSharper 3.1 just came out, and of course I immediately installed it.  So far so good.  It fixed a couple of annoying crashes for me and added a new feature.

• I can now open my MSBuild project files without ReSharper crashing constantly.
• Visual Studio has yet to crash on exit.
• And the best reason to upgrade: solution wide error analysis has been added.  Pic below.

I downloaded the NHibernate VS2005 plugin and started to use it - its very similar to the Hibernate support built into Eclipse.  Unfortunately after playing around with it for about 20 minutes I realized my data model (in the DB) was complete poo and the plugin wasn't built to handle legacy databases, which I completely understand because that's where the majority of NHibernate's complexity lies IMO.

I really don't want the crappy data model to leak into my object model - even though it would be super easy and fast to "whip it out" using the plugin or another code generator.  I'm kind of stuck on what to do right now.  Part of the problem is I'm not sure I have time to "do it right." I have a hard deadline looming from a 3rd party that can't budge.

I think I may start out modeling my object model from scratch, which isn't too bad with Re# installed.  Then from there start manually mapping some of this stuff to the existing sprocs or creating some new views.  I also have the problem that this will all be serialized and sent over a web service and/or NServiceBus, so I'm not sure how to handle relationships.  Probably in most cases I'll just have IDs of the FKs and then explicitly make another fetch from the service since lazy loading is pretty much out of the question.

Setting up a new Windows development machine is a pain.  In fact it's more work than setting up a Linux development machine.  In Linux the package manager for the OS, the Rails package manager, and/or the Eclipse update manager handles most of this for me.  In Windows I'm forced to install things individually using separate installers.  Here's the minimum I had to install on my brand new Windows Vista box to get a decent development environment:

• Visual Studio 2005
• VS 2005 SP1
• VS 2005 SP1 patch for Vista
• Windows Vista SDK
• WCF for VS 2005
• .NET 1.1 Runtime (yes, I still have a project that compiles .NET 1.1)
• ReSharper 3 for C#
• SVN
• TortoiseSVN
• VisualSVN

That's just to get my machine compiling our code, that doesn't even include the numerous other tools I need to be productive like Paint.NET or MS Office.  All in all, I had to install around 30 applications yesterday!  No wonder I've been dragging my feet on getting a new system for the past month.  The good news is, I'm now done and this new 3GHz dual core system with 3GB or RAM freakin' rocks compared to my old Dell Dimension 4600.

Today our product manager was trying mocking up some new UI elements in Visual Studio 2005 when he came to me with this error, "one or more errors encountered while loading the designer."  This is something that probably doesn't come up very often, or at least I hope not - especially in this specific case.

In our WinForms application we have a custom resource manager that the main form uses.  This custom resource manager makes use of a MarketSegment class which is created based off a setting in the app.config via the MarketSegmentManager class.  This market segment object is used to conditionally load resources depending on the current market segment selected in the app.config.  This way we can display different text and graphics depending on the current customer's segment.

Apparently when the Visual Studio designer builds and then runs, it doesn't give your code access to the app.config - at least when its loading resources.  I ended up having to change our MarketSegmentManager class to return a default MarketSegment object when the app.config setting was read in as null - like when its running under the VS designer.  I don't really like this because it is anything but fail fast, but its better than not having the VS winform designer.

1. All my build output for all projects are setup to be copied to <working path>\build\<configuration>.  So when building a release build, that path is really d:\source\build\release.
2. Add a reference to the release or debug version of the external file based assembly located in the directory mentioned in step 1.
   
3. Unload the .csproj file from within Visual Studio that has the reference to the external assembly.
4. Edit the unloaded project file and change the HintPath from ..\..\build\release\commons.dll to ..\..\build\$(Configuration)\commons.dll.
5. Save, then reload the project.