Where VSTO creates the project folder
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)....