I'm using a modified version of Microsoft's UpdateManifest sample project to alter the embedded application manifest during setup. My modified UpdateManifest assembly expects two parameters. One for the document path and one for the assembly path. In the setup project's custom actions settings for UpdateManifest I'm passing this:

/documentPath="[ProgramFilesFolder][Manufacturer]\[ProductName]\Document.xlt" /assemblyPath="%ProgramFiles%\[Manufacturer]\[ProductName]\Assembly.dll"

Problem is, the setup project resolves %ProgramFiles% prior to sending it to the UpdateManifest assembly. The UpdateManifest assembly receives:

"C:\Program Files\Manufacturer\ProductName\Document.xlt"


"C:\Program Files\Manufacturer\ProductName\Assembly.dll"

So both the [ProgramFilesFolder] directive and %ProgramFiles% are resolved by the setup project. Does this mean I have to use my own scheme to pass special characters to UpdateManifest Maybe something like @ProgramFiles@ or is that also resolved by the setup project

Re: Visual Studio Tools for Office Altering embedded application manifest during setup


What the &$#%

Apparently, the setup project or Visual Studio or who knows what was caching the CustomActionData setting for the parameters I was using. I tried changing the value of the /assemblyPath parameter numerous times but it did not change what was being passed to the custom action assembly! I even added a new parameter to the CustomActionData setting and verified it was being passed to the custom action assembly. Finally I closed Visual Studio, deleted all existing UpdateManifest DLLs, restarted Visual Studio, changed the name of the /assemblyPath parameter to /wtfPath and the value being passed was FINALLY changed to what I was actually assigning to it. I've been trying to find the cameras that the MS Visual Studio team must have installed in my office to film my reaction to their hilarious joke but I still haven't found them.

So, the string %ProgramFiles% is NOT resolved by the setup project as I thought initially. There's apparently some bug with the CustomActionData setting.

Now if I could only figure out how to get the automation to run regardless of where the document is launched. That's in another thread (here).