NuGet Packages with COM/Absolute File References

Jul 15, 2011 at 7:31 PM

Hey everyone,

I've put out a NuGet package called WindowsAzure.RoleTools. It lets you manipulate the IIS instance for the Role on startup. In order to do that, it requires the use of Microsoft.Web.Administration.dll, which is on the Role by default. Here is the problem. There is a version of this assembly in the GAC. BUT because Microsoft.Web.Administration also leverages COM, and it's a trusted system assembly, you MUST use it from c:\windows\system32\inetsrv\Microsoft.Web.Administration.dll. You cannot under any circumstances use it anywhere else, and it's not bin-deployable.

Herein lies the rub. Even if you put the absolute path to the file in a <frameworkReference> tag in NuGet, it will load the assembly from the GAC, which will throw a COM exception that for some reason won't get trapped by wrapping the call in a Try/Catch. Therefore it crashes the Role.

I tried writing an install.ps1 script to manipulate the project to add the proper HintPath to the reference, but that didn't work either. The only way to avoid the problem is to make the user manually add a ReferencePath to the project after they have installed the package.

There are two possible solutions to the problem. A) If an absolute path is specified in the <frameworkReference> tag, honor it. There are many other situations that may need to reference other assemblies that ship with Windows, so this is not an isolated function. It may mean that you guys need to manipulate the HintPath internally. OR B) add a hintPath attribute to the Framework reference to let you specify where it should load from.

If you guys could work this into 1.5, it would be a huge help. Thanks!

Jul 15, 2011 at 8:10 PM

Why can't your install.ps1 just reference the assembly from the inetsrv directory using:


Jul 15, 2011 at 8:25 PM

Thanks, I had a hard time figurig out what the syntax should be for that. I will probably blog it at some point, and you guys should probably add it to the documentation. But I still think that it should be intrinsic to the NUSPEC file somehow. I think people are going to try to make it work the way I described first... so if that's what they are going to do, why not just make it work THAT way?

Jul 15, 2011 at 8:34 PM
Edited Jul 15, 2011 at 8:37 PM

Actually, I just tested that, and it did not work. It is still pulling the reference from the GAC, even with the <frameworkAssembly> entry removed. You must explicitly set the HintPath.

Jul 15, 2011 at 10:00 PM
Edited Jul 15, 2011 at 10:07 PM

Works for me. Not sure what you tried. What are the exact steps you tried?

Jul 16, 2011 at 1:55 AM

This is the install.ps1 file:

param($installPath, $toolsPath, $package, $project)

if ($host.Version.Major -eq 1 -and $host.Version.Minor -lt 1)
	"NOTICE: This package only works with NuGet 1.1 or above. Please update your NuGet install at 
	Sorry, but you're now in a weird state. Please 'uninstall-package WindowsAzure.RoleTools' now."

And this is the location the reference ends up pointing to in my project, no matter what I try: C:\Windows\assembly\GAC_MSIL\Microsoft.Web.Administration\\Microsoft.Web.Administration.dll

Jul 16, 2011 at 2:07 AM

OK, so I think I narrowed this down. That command does not work for VB applications. If you open Visual Studio 2010, create a new Azure application, add a NON-MVC VB Web Role to the project, and then type "install-package windowsazure.roletools", you'll see that the reference is pointing to the GAC. If you do the same thing, but with a brand new, NON-MVC C# web role, it works fine. Thus far, I had been doing all my testing against a VB role, hence why nothing worked. This is definitely a bug.