Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Julie wrote to me with a problem about where VSTO creates its DLLs and how they get trusted. Hopefully this will help ;-)
The other day I blogged about how referenced assemblies are copied around, but there's another piece to the puzzle. If you use the New Project wizard to create a VSTO project and elect to create a new document, the wizard places the document in the same folder as the project so you end up with this kind of hierarchy:
// Root project folder
C:My_DocsUserVS_ProjsProject
// VS Project files
ThisDocument.vb
Project.sln
etc.
// The document
Project.doc
// VS output folder
Bin
Project.dll
Project.pdb
// VS build folder
Obj
Debug
Project.dll
Project.pdb
// VSTO output folder
Project_bin
Project.dll
Project.pdb
In this case, VSTO will setup the security policy to trust C:My_DocsUserVS_ProjsProjectProject_binProject.dll and when you run the solution it will run the document C:My_DocsUserVS_ProjsProjectProject.doc which will try and load the assembly through the relative path .Project_bin.
If you choose to use an existing document, something a bit different happens. VSTO still creates the standard VS project hierarchy, but the Project_bin is created relative to the original document's location. You end up with something like this:
// Root project folder
C:My_DocsUserVS_ProjsProject
// VS Project files
ThisDocument.vb
Project.sln
etc.
// Note: no document!
// VS output folder
Bin
Project.dll
Project.pdb
// VS build folder
Obj
Debug
Project.dll
Project.pdb
// Document folder
C:My_DocsUserDesktop
// The document
Project.doc
// VSTO output folder
Project_bin
Project.dll
Project.pdb
In this case, VSTO builds the DLL into the project folder, but then copies it (along with any referenced assemblies) to the document's location as a post-build step. It will also setup the security policy to trust C:My_DocsUserDesktopProject_binProject.dll and when you run the solution it will run the document C:My_DocsUserDesktopProject.doc which will try and load the assembly through the relative path .Project_bin. If you try and set policy to trust the VS project location (C:My_DocsUserVS_ProjsProject*) it won't have any effect since the document / assembly is not loaded from there.
If you want to know where your assembly comes from, it's pretty easy using the CodeBase property of the Assembly object:
' Display the location of the DLL
Private
Sub
ThisWorkbook_Open
()
Handles
ThisWorkbook.Open
MessageBox.Show(Me.GetType.Assembly.CodeBase)
End
Sub
(Of course your code needs to be trusted to display this info...)
Comments
- Anonymous
January 31, 2004
Yes this is exactly what it WAS doing... but now I've discovered that if I go in and set the assembly link to the directory I'm planning on deploying to BEFORE I initially run the template I'm designing (that I based on an existing document), it actually doesn't do that.
So, I have the following directories:
C:MSPDASBaseTemplates (.dot files)
C:MSPDASReferences (dependency .dlls)
C:MSPDASTemplates (VSTO project files)
C:MSPDASTemplateAssemblies (VSTO dll files)
Now when I compile, the VSTO files get put in the template folder directory under c:MSPDASTemplates, BaseTemplates continues to contain only my .dot files and the VSTO DLLs are going into c:MSPDASTemplateAssemblies
I really like this...not quite sure if its supposed to be doing it but I like it nonetheless :) - Anonymous
January 31, 2004
Yes, if you manually over-ride the AssemblyLinkLocation property then VSTO will put the stuff wherever you ask for it (and update policy to trust that location too). - Anonymous
January 31, 2004
The comment has been removed - Anonymous
January 31, 2004
Today is a complete success. Finally finished debugging the core architecture, I was able to finish one of our most complicated templates and begin working on the pile of 30 pilot templates (so far I have 7 of those done)....