views:

281

answers:

2

I'm working on a project whose setup uses the APIs documented in Microsoft Knowledge Base article KB317540 to install and uninstall assemblies into the GAC. The KB article states:

SUMMARY
The native code application programming interfaces (APIs) that allow you to interact with the Global Assembly Cache (GAC) are not documented in the .NET Framework Software Development Kit (SDK) documentation.

MORE INFORMATION
CAUTION: Do not use these APIs in your application to perform assembly binds or to test for the presence of assemblies or other run time, development, or design-time operations. Only administrative tools and setup programs must use these APIs. If you use the GAC, this directly exposes your application to assembly binding fragility or may cause your application to work improperly on future versions of the .NET Framework.

The GAC stores assemblies that are shared across all applications on a computer. The actual storage location and structure of the GAC is not documented and is subject to change in future versions of the .NET Framework and the Microsoft Windows operating system.

The only supported method to access assemblies in the GAC is through the APIs that are documented in this article.

Most applications do not have to use these APIs because the assembly binding is performed automatically by the common language runtime. Only custom setup programs or management tools must use these APIs. Microsoft Windows Installer has native support for installing assemblies to the GAC.

For more information about assemblies and the GAC, see the .NET Framework SDK.

Use the GAC API in the following scenarios: When you install an assembly to the GAC. When you remove an assembly from the GAC. When you export an assembly from the GAC. When you enumerate assemblies that are available in the GAC. NOTE: CoInitialize(Ex) must be called before you use any of the functions and interfaces that are described in this specification.

What are the pros and cons of this technique? Are these APIs safe to use? Anyone out there using them? If so, why?

+1  A: 

It says, "Only administrative tools and setup programs must use these APIs."

There are tools (e.g. command-line tools) to work with the GAC. Why not invoke these executables, instead of using these APIs directly?

ChrisW
Right, yes, I know what it says - the problem there is that my team members think they are "creating a setup program". I think they've misinterpreted the statement. To me, that means that your process name has to be MSIExec if you want to use these APIs. However, Inno Setup (the tool being used) spits out a setup.exe that "sets up the product" - it is a "setup program". I'm sure you can see the ambiguity there.
Tim Long
I think it might be much easier (e.g. 1 line of code) to invoke the command-line tool, instead of using an API like that one.
ChrisW
+1  A: 

Why not just create a Windows Installer package? See Demystifying the .NET Global Assembly Cache. Quoting:

Developers of Windows Installer packages can install assemblies to the GAC using Microsoft Windows Installer 2.0. This is the preferred way for installing such shared assemblies and should be the only way shared assemblies are installed on non development machines.

TrueWill
If it were up to me, that's exactly what I would do, but the others in my team seem to think that Windows Installer is "too difficult" and they want to use Inno Setup. This really smells bad to me, but I'm currently outnumbered :(
Tim Long
@Tim: I found this link that may help: https://msmvps.com/blogs/carlosq/archive/2009/06/09/net-support-in-next-version-of-innosetup-installer-handy-for-com-based-add-ins.aspx
TrueWill