Where VSTO creates the project folder

Where VSTO creates the project folder

  • Comments 4

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_Docs\User\VS_Projs\Project\

 

  // 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_Docs\User\VS_Projs\Project\Project_bin\Project.dll and when you run the solution it will run the document C:\My_Docs\User\VS_Projs\Project\Project.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_Docs\User\VS_Projs\Project\

 

  // 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_Docs\User\Desktop\

 

  // 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_Docs\User\Desktop\Project_bin\Project.dll and when you run the solution it will run the document C:\My_Docs\User\Desktop\Project.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_Docs\User\VS_Projs\Project\*) 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...)

  • 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:\MSPDAS\BaseTemplates (.dot files)
    C:\MSPDAS\References (dependency .dlls)
    C:\MSPDAS\Templates (VSTO project files)
    C:\MSPDAS\TemplateAssemblies (VSTO dll files)

    Now when I compile, the VSTO files get put in the template folder directory under c:\MSPDAS\Templates, BaseTemplates continues to contain only my .dot files and the VSTO DLLs are going into c:\MSPDAS\TemplateAssemblies

    I really like this...not quite sure if its supposed to be doing it but I like it nonetheless :)
  • 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).
  • Oh yeah, I think that VSTO 2 will change this behaviour a bit and will always copy the document into the project directory and then execute a read-only copy from the _bin directory... due to the new "designer hosted in VS" model things had to be changed around a bit.
  • 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)....
Page 1 of 1 (4 items)