Kirk Evans Blog

.NET From a Markup Perspective

Creating and Deploying a ServicedComponent

I have a set of demos coming up to show off using ServicedComponents.  I thought it would be entertaining to capture a couple of the frustrating moments tonight while writing a 5-line demo.

The first moment occurred when finding where in the world regsvcs.exe lives on my machine.  I have the November CTP of WinFX on my machine, so regsvcs.exe apparently doesn’t live with the 2.0 framework anymore, it is moved to the WinFX SDK directory:

C:\Program Files\Microsoft SDKs\Windows\v1.0\Bin

Next, I wanted to show how automatic component registration works.  A quick bit of code, deploy it, run it…  and then I kept getting access denied messages when trying to access a service application.  Huh? 

I read through Understanding Enterprise Services (COM+) in .NET, and didn’t see anything (although it is a fantastic article… must read to understand ES).  A quick MSN search yielded a great 15 Seconds article on deploying a ServicedComponent.  Wait a minute… Yep, I did use the server activation option, so effectively I was trying to deploy a server application using automatic registration and never put the assembly in the GAC.  OK, so automatic COM+ registration needs a library application… good to reiterate for the presentation.  And, here is the attribute to specify this assembly should be a server application:


OK, so I want a simple way to show how to GAC and run regsvcs.  The next bit of frustration arose from trying to get fancy with post build events.  To make a long story boring, make sure you provide the full path to .NET framework utilities like gacutil, and make sure you put TargetPath and other macros with values that likely contain spaces within quotes:

"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" -i "$(TargetPath)"

"C:\Program Files\Microsoft SDKs\Windows\v1.0\Bin\regsvcs.exe" "$(TargetPath)"

After that, the build succeeded and the assembly was put in the GAC correctly for both the VB.NET and C# versions, and the assembly was registered in the COM catalog correctly.

Bingo!  Even better, my little demo worked.  Lessons (re)learned:

  • Service applications need to be put into the GAC prior to registering in the COM catalog. 
  • Automatic registration only works for library applications.
  • Build events need the whole path to the .NET framework utilities.
  • WinFX moves some of the utilities from where they used to live.