Kirk Evans Blog

.NET From a Markup Perspective

Creating and Deploying a ServicedComponent

Creating and Deploying a ServicedComponent

  • Comments 1

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:

ApplicationActivation(ActivationOption.Server)]

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.
  • > Automatic registration only works for library applications.

    Not entirely true, some clarification is in order. The assembly must be manually configured in the GAC. Once GAC configuration is done, the assembly may be automatically registered in the COM catalog (at least using .NET 2.0).
Page 1 of 1 (1 items)
Leave a Comment
  • Please add 8 and 5 and type the answer here:
  • Post
Translate This Page
Search
Archive
Archives