Easy Commerce Server Pipeline Component Debugging with IIS7s appcmd.exe

If you have worked on a large Commerce Server implementation, you have likely built a custom pipeline component or two.  This makes you part of a very special band of brothers (requires Facebook login).  It also means that you have probably seen your fair share of the build error "Unable to copy file ... The process cannot access the file XYZ" (pictured below in all it's namespace censored glory)...

Picture of build error, unable to copy file ... the process cannot access the file XYZ.

This error usually occurs when you build pipeline component project, having just run a pipeline that contains the same physical component (or another component in the same assembly).  The reason it occurs is that the process hosting your website (in my case w3wp.exe) has an open file handle to the assembly containing your pipeline component.  Hence you can't copy over it :(

In the past I have resolved this using one of the following methods:

However, all of these involve what I call micro-tedium.  Micro-tedious tasks are those computing tasks that are so small that they appear insignificant, but in reality suck the life out of you (like the Large Hadron Collider is also probably doing right now).

Anyway, I digress.

My Slightly Funky but Practical Solution to "The Process Cannot Access the File" Tedium

IIS7 ships with a new tool called Appcmd.exe.  It is a command line tool that lets you do useful stuff like create and configure sites, view information about worker processes and start and stop application pools!

So, for pain free pipeline component development, use appcmd.exe in the pre and post-build events of your pipeline component project, to stop and start the application pool that hosts your Commerce Server site.  My build event commands look like this (you will need to replace DefaultAppPool with the name of the Application Pool your Commerce Server site is running in):

Picture of pre-build command line: %systemroot%\system32\inetsrv\appcmd.exe stop apppool DefaultAppPool

Picture of post build command line: %systemroot%\system32\inetsrv\appcmd.exe stop apppool DefaultAppPool

Configuring your build event commands like this results in the following occurring in order when you build your pipeline component project:

  • Before the build, the application pool is stopped.
  • Your project builds.
  • After the build the application pool is started again.

It works for me.  Does it work for you?  Any elegant(er) solutions out there?

Important Note about Exit 0The exit 0 command is included so that the return code is always success, even if appcmd has a non-success return code.  I do this because Appcmd will fail to stop the application pool, if the application pool is not already running.  This would then cause your build to fail.  The exit 0 command stops that happening.  If you have other commands in your build event, exit 0 could mask their failure.

Stuck on IIS 6?  If you are stuck on IIS 6 you may want to hack up something similar using one of the IIS 6 Command Line Tools (I think it is possible!).

Appendix:  Paste-able Version of the Appcmd Commands Used
%systemroot%\system32\inetsrv\appcmd.exe stop apppool DefaultAppPool
exit 0

%systemroot%\system32\inetsrv\appcmd.exe start apppool DefaultAppPool
exit 0

  Posted: 07:16:11 Mon 15 Sep 2008  Tags: Commerce Server 2007 | Commerce Server Mojave | Micro-Tedium | IIS 7 | Pipeline Components | Visual Studio
   Permalink Comments [0]

Get xUnit.net Working with Resharper 4.1

Update 17/09/2008:  You no longer need the patch in this post.  Brad Wilson and the team at xUnit.net have just released xUnit.net Version 1.0.3.  This release supports ReSharper 4.x via a new, smarter installer.

Hi, my name is Ben and I am a ReSharper fanboyIf you ever have the misfortune of pair programming with me, I promise not to shout Ctrl+Alt+V , Ctrl+Q etc over your shoulder (sorry Mike).

Anyway, being a fanboy, I rushed out and installed ReSharper 4.1 as soon as it came out.  Unfortunately, this resulted in the loss of the the xUnit.net ReSharper integration that I also use!  Why you ask?  Well ReSharper plugins have to live in a sub-directory of the ReSharper install folder and every time ReSharper rev, they move the install location and the registry settings.  This means that when you run VS.NET you lose the test runner functionality and when you try and re-install xUnit R# integration you see red....  Bad R#. Boo.

sshot-2

So, I popped off to the xUnit.net discussions on CodePlex to find out about plans for R# 4.1 support and I ended up writing a patch to make it work (big thanks to Brad Wilson for his R# related patience and quick responses).  My installer now looks like this:

 sshot-3

I could not submit patches to xUnit for some xUnit legal reasons (IP Stuff).  So, if you want to get it running you can download the install binaries I built, or do the patch work yourself.

Do any of this at your own risk.  It is not my fault if this causes your machine to melt, or you to lose hectares of code etc, ad-infinitum.

Use the Binaries I Patched and Built

  1. Download my xUnit Installer Binaries for ReSharper 4.1
  2. Extract the zip and run xunit.installer.exe.
    Note:  There are not "official" xUnit binaries.  I modified and built these.

Or...

Patch xUnit Installer for ReSharper 4.1 Support

  1. Install ReSharper 4.1.
  2. Get the latest xUnit source (I used rev 23764).
  3. Apply my xUnit.net ReSharper 4.1 installer patch to xUnitSourceRoot (i.e. the root of where you checked out).
  4. Run xUnitSourceRoot\Main\3rdParty\Get3rdParty.cmd
  5. Make sure that xUnitSourceRoot\Main\3rdParty just filled up with a bunch of ReSharper binaries.
  6. Open xUnitSourceRoot\Main\xunit.sln
  7. Rebuild All.
  8. Run the installer:
    xUnitSourceRoot\Main\xunit.installer\bin\Debug\xunit.installer.exe
  Posted: 05:40:28 Thu 4 Sep 2008  Tags: ReSharper | xUnit | Open Source | Unit Testing
   Permalink Comments [3]