Using referenced assemblies in VSTO

  • Article

OK, a quick one to finish up. When you add a reference to a "private" (non-GACed) assembly to a VSTO project, you'll need to grant it trust if it needs more than basic Execution permission. But where to grant trust?

Some background information for folks who aren't aware of how assemblies are loaded in .NET:

Unlike the COM world where you can register an ActiveX object from anywhere on the system and use it from anywhere else in the system, in .NET you can only use assemblies from two places:

· The directory in which the application lives (or some subdirectory under it)

· The Global Assembly Cache (GAC)

When you add a reference in Visual Studio, if your assembly is not in the GAC then the Copy Local property will be set to True, and a copy of the assembly will be copied to your project's output directory so that it can be discovered at run-time. Let's do a quick experiment:

1) Start VS

2) Create a VB .NET Control Library

3) Build the project

4) Add a VB .NET Word project to the solution

5) Add a reference to the control library to the VSTO project

6) Build the solution

Now do a search for the control DLL. In my simple example, the control was called MyCoolLibrary.dll, and here's the output:

[C:Temp]dir /s /m MyCoolLibrary.dll

 

Volume in drive C is unlabeled Serial number is EC20:326A

 

Directory of C:TempMyCoolLibrarybinMyCoolLibrary.dll

 

28/01/2004 12:11a 6,144 MyCoolLibrary.dll

 

Directory of C:TempMyCoolLibraryobjDebugMyCoolLibrary.dll

 

28/01/2004 12:11a 6,144 MyCoolLibrary.dll

 

Directory of C:TempWordDocUsingMyCoolLibrarybinMyCoolLibrary.dll

 

28/01/2004 12:11a 6,144 MyCoolLibrary.dll

 

Directory of C:TempWordDocUsingMyCoolLibraryWordDocUsingMyCoolLibrary_binMyCoolLibrary.dll

 

28/01/2004 12:11a 6,144 MyCoolLibrary.dll

(Note that the /m switch is one of many cool features you can get by using 4NT instead of CMD as your command prompt).

What? Why are there four copies of the assembly?!? Well, the first two are built by the original control project. The MyCoolLibraryobjDebug directory is where the code gets built into, and the MyCoolLibrarybin directory is where it gets copied to for actual use. Then when you add the reference to the Word project, VS helpfully copies the assembly to the WordDocUsingMyCoolLibrarybin directory so that the solution will "work", but then for reasons described in this blog entry we then copy it (along with the actual project's assembly) to the WordDocUsingMyCoolLibrary WordDocUsingMyCoolLibrary_bin directory for final use / deployment.

So you have four copies, and if the library needs anything more than Execution then you need to grant the appropriate permissions (most likely FullTrust if you call into the Office OM) to the copy in the WordDocUsingMyCoolLibrary WordDocUsingMyCoolLibrary_bin directory; adding trust to any of the other locations won't help. The VSTO help has information on how to do this in this topic. Obviously if you deploy your solution to some other location you will need to set up security appropriately, whether that be via the URL to the assembly or something stronger like a signature.

Oh and avoid using the Microsoft .NET Framework 1.1 Wizards to set policy, at least while you are developing; use the Configuration tool (or caspol) instead. The wizard will create a policy rule based on the hash of the assembly, but it will become out of date as soon as you modify and re-build the assembly.

Oh and if you have installed Whidbey, you need to modify the Whidbey policy (not the Everett policy) to get your solution to work, and make sure you attach with the Whidbey debugger rather than hitting F5 to trying and debug from within Everett.