Using environment variable in VSTO 2007 Deploy Manifest Path

Question

I would like to deploy a document-level customization to each end user's computer. I found an article about this http://msdn.microsoft.com/en-us/library/xbys5fef(VS.80).aspx 

This article refers to updating the embedded application manifest so that it uses an environment variable to point to the assembly. It says that instead of using a specific drive letter and path, use %ProgramFiles% or %UserProfile% to begin the path. However, there is no example with code which use environment variables.

I found few threads where people tried to do this, but their methods didn't help.

I'm asking for help.

I use such part of code for updating manifest path in the document

string targetLocation = "C:\\Program Files\\DEV\\Reporter\\Report.docx";

string assemblyLocation = @"%ProgramFiles%\DEV\Reporter\BSReportTemplate.dll";

Uri deploymentManifestLocation = new Uri(@"%ProgramFiles%\DEV\Reporter\BSReportTemplate.vsto", UriKind.Relative);

 if (ServerDocument.IsCustomized(targetLocation))
 {
      ServerDocument.RemoveCustomization(targetLocation);
 }

 ServerDocument.AddCustomization(
     targetLocation,
     assemblyLocation,
     SolutionID, 
     deploymentManifestLocation,
     false,
     out nonpublicCachedDataMembers);

When i run my code the DirectoryNotFoundException occurred with such error: The system cannot find the path specified. (Exception from HRESULT: 0x80070003).

I checked everything, all files really exist in this directory, but i think %ProgramFiles% variable doesn't want to work.

I don't know what to do, please help.

Thanks in advance.

Answer 1

    string assemblyLocation = @"DEV\Reporter\BSReportTemplate.dll";
    string programFilesPath = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles);
    string targetLocation = System.IO.Path.Combine(programFilesPath, assemblyLocation);

i think the problem is that you put the environment variable into a string, so the path never gets expanded to the full directory path.

instead of using the environment variable with % signs, try using the Environment.GetFolderPath method to retrieve the actual Program Files directory path. then use System.IO.Path.Combine to create your fully qualified path.

m.

Answer 2

The reason why i would like to use environment variable is that for example windows can be installed on different partitions, and their letters will be different, for example on one PC it will be "C:\Program Files\" on another "D:\Program Files\".

For this reason i want to put environment variable inside embedded assembly path, and it will be retrieved when document will be opened. I hope that in such way all should work, but I don't know how to do it correctly.

Answer 3

one problem is that http://msdn.microsoft.com/en-us/library/xbys5fef(VS.80).aspx refers to Office 2003 and the VSTO 2005 SE runtime.  VSTO 3.0solutions for Office 2007 don't use embedded manifest paths.  which version of the VSTO runtime and Visual Studio are you using?

m.

Answer 4

I'm using Visual Studio 2008 and VSTO runtime v9.0 for Office 2007.

And what do you mean, that new version of runtime doesn't support environment variables? 

Answer 5

the link that you are reading has a box in the upper right that says the following:

This page is specific to Microsoft Visual Studio 2005/.NET Framework 2.0

Other versions are also available for the following: Microsoft Visual Studio 2008/.NET Framework 3.5

if you look at the VS2008 version of the link, the topic is marked for apply to Office 2003 only. in the VSTO 2005 SE runtime, customized documents have an embedded application manifest that points to a deployment manifest somewhere else.

in the VSTO 3.0 runtime, the customized document has a link to a deployment manifest.  the link must be a file path that can be relative (OfficeSolution.vsto) or fully qualified (c:\OfficeSolution.vsto).  see Custom Document Properties Overview for more information.

if you run the GetFolderPath method on the end user's computer, that will retrieve and evaluate environment variables for you.  the only difference is that it's not represented as %.

i have some questions about your scenario. ClickOnce installation is a per-user install, and on newer OSes (Vista, Win7), user accounts don't have access to the program files directory.  is the DLL being installed there with an MSI?  if you are deploying a DLL and a document, ClickOnce will automatically put the DLL into the ClickOnce cache, a hidden directory in each user's profile directory.  this way, you don't have to re-attach the assembly to the document after you deploy this Office solution and you can avoid using ServerDocument.  can you store your assembly on a network file share or web site with address does not change drive letters?  the users will have to be networked when they install the VSTO solution, but afterwards, they can be offline.

m.

Answer 6

I didn't understand you when you said about GetFolderPath, where i should run GetFolderPath on end user's computers. Could you explain, please.

I use VSTO 3.0 runtime and as you said, the customized document has a link to a deployment manifest which can be relative, can i use there environment variables?

The DLL is being installed with an MSI, you are right. So you mean that on newer OSes it won't work, if I install them to the program files directory?

Can you tell me please, why ClickOnce will put the DLL into the ClickOnce cache, not to the program files? Is there any articles about this?

Yes, I can store my assembly on a web site, but i didn't know that I will need to download assembly only once, why?

Answer 7

you can use ServerDocument in a console app and call GetFolderPath on the end user computer.

i am not sure if you can use environment variables in the deployment manifest path.

on newer OSes, installing to the Program Files directory requires elevated privileges for the MSI.  if the user is not an administrator, the installer will not work.  ClickOnce always installs to the user's profile directory, so files never have to go into the Program Files directory. for more information about the ClickOnce cache, see ClickOnce Cache Overview.  if you store the assembly on a website, the assembly is installed into the ClickOnce cache.  this enables an offline experience for your customers, and also allows you to update the assembly on the website.  at specified intervals, the application can go to the website and install the latest assembly.

m.

Answer 8

Thanks a lot.
I solved my problem with ClickOnce installation.