none
Are special folder tokens allowed in VSTO manifest file pointers? RRS feed

  • Question

  • I have an Excel document-level VSTO 2010 project that I want to deploy locally.  Problem is, I need to support x64 and x86 clients.

    So, can the pointer to the deployment manifest in an embedded app manifest be set up with a special folder token like %ProgramFiles%?  Or, is there another way to allow a single VSTO-enabled workbook to work against installations on 64 bit and 32 bit systems?

    Friday, June 24, 2011 5:51 AM

All replies

  • Hi Robert,

     

    Thanks for your post.

    If I understood you correctly, you want to deploy your document-level solution for both 32-bit and 64-bit. Please correct me if I have any misunderstood.

    Actually, you don’t need do some further actions to fit both 32-bit and 64-bit as an application is targeting at “Any CPU” by default. When the application is compiled as “Any CPU”, it will detect to run as 32-bit or 64-bit automatically. For more:

    http://blogs.msdn.com/b/joshwil/archive/2005/04/08/406567.aspx

     

    What happens if you try to use these exes and dlls together? We have to consider two possible scenarios, running on a 32-bit machine and running on a 64-bit machine...

    1.       On a 32-bit x86 machine:

    anycpu.exe -- runs as a 32-bit process, can load anycpu.dll and x86.dll, will get BadImageFormatException if it tries to load x64.dll

    x86.exe -- runs as a 32-bit process, can load anycpu.dll and x86.dll, will get BadImageFormatException if it tries to load x64.dll

    x64.exe -- will get BadImageFormatException when it tries to run

     

    2.       On a 64-bit x64 machine:

    anycpu.exe -- runs as a 64-bit process, can load anycpu.dll and x64.dll, will get BadImageFormatException if it tries to load x86.dll

    x86.exe -- runs as a 32-bit process, can load anycpu.dll and x86.dll, will get BadImageFormatException if it tries to load x64.dll

    x64.exe -- runs as a 64-bit process, can load anycpu.dll and x64.dll, will get BadImageFormatException if it tries to load x86.dll

     

    I hope this helps.


    Best Regards, Calvin Gao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, June 28, 2011 7:38 AM
    Moderator
  • Thanks for the response Calvin but I think you missed the actual question.  I need a VSTO-enabled Excel document to support local automation deployments in x86 and x64 environments with different Program Files directory names.  I'm not looking for clarification on x86 vs. x64 runtime compatibility.

    Specifically, I want to configure the application manifest embedded in the VSTO-enabled Excel document to look for the deployment manifest using a special folder token.  So, can the pointer in the application manifest be set to something like %ProgramFiles%\Company Name\App Name\App.vsto and work regardless of the location of the .vsto file?  That is, it would work if the .vsto file was deployed to C:\Program Files or C:\Program Files (x86).

    Consequently, I posted a question about this some time ago and I thought I had it working in VSTO 2005 SE but I think I had an issue with the deployment and gave up on the approach.  I'm now using VSTO 4 (2010).  It would be real nice to support local deployments with a single ClickOnce package regardless of the name of the Program Files directory.  That would allow me to avoid a network share or website hosting the ClickOnce package.  I know, I know, not the recommended approach but I'm not making the decisions.

    Tuesday, June 28, 2011 10:05 PM
  • Hi Robert,

     

    Hmm…I still can’t follow your intention well. Here is what I have done about publish a document-level solution via ClickOnce and then install it in client machine:

    1. Create a document-level project, add some codes

    2. Compile the project

    3. Right click the solution -> Publish -> Select a directory -> Finish

    4. Move the three file (SolutionName.vsto, SolutionName.xlsx and setup.exe) & a folder (Application Files) to a client machine

    5. Install the document-level solution in client machine. We have three approaches to install it: by using the setup program, by using .vsto file and by the Office file

    For more, please refer to:

    http://msdn.microsoft.com/en-us/library/bb608592.aspx

     

    Then you can use the Excel file in the client machine anywhere. I don’t understand what you want to do with C:\Program Files or C:\Program Files (x86).

     

    I look forward to hearing of you soon.


    Best Regards, Calvin Gao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, June 29, 2011 11:08 AM
    Moderator
  • It seems worth reviewing how the VSTO runtime finds the customization for a document-level project.  There is an application manifest embedded in the Excel document that contains a pointer to a deployment manifest file (the .vsto file in VSTO 4).  The deployment manifest contains a pointer to the application files.  These pointers are used by the VSTO runtime to locate and load the customization DLL when a user opens a document-level VSTO-enabled workbook.

    In a perfect world all the users of a VSTO application are on x86 systems (or all are on x64 systems) and a VSTO project can be deployed locally without any issues.  For example, the customization will always reside in C:\Program Files\Company Name\App Name.  But the world isn’t perfect and users share documents.

    In the real world several application users are on x86 systems and several users are on x64 systems.  Let’s say I create the ClickOnce package targeting an x86 system (using C:\Program Files\Company Name\App Name as the Installation Folder URL).  It should go without saying that users will share documents.  For example, a user on an x86 system will create a document from this application and save it the intranet.  A user on an x64 system will try to open it but the VSTO runtime on the x64 system will look at the deployment manifest pointer in the document and not be able to find the deployment manifest or customization DLL because on their system the customization SHOULD be installed to C:\Program Files (x86)\Company Name\App Name.  That isn’t the directory that the document points to.  It points to C:\Program Files\Company Name\App Name.

    Wednesday, June 29, 2011 7:05 PM
  • Hi,

    I think it's really hard to customize the deployment manifest location.   The file folder location is actually saved in the custom property _AssemblyLocation inside the Excel document (.xlsx) as a string value.   http://msdn.microsoft.com/en-us/library/zcfbd2sk.aspx

    "When a user opens a document that is part of a Microsoft Office customization, the application uses the deployment manifest that is linked to the document to locate and load the most current version of the customization assembly. The location of the deployment manifest is stored in a custom document property named _AssemblyLocation. The string that identifies this location is inserted into the property when you build the solution."

    If we made the .xlsx file into .zip package, the property is stored in docProps/custom.xml.   I believe the value is there once the document-level VSTO solution is built.

    Or maybe we can deploy the document, the deployment manifest, the application manifest and the assembly files in the same folder? 

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Thursday, June 30, 2011 5:58 AM
    Moderator
  • The pointer is not just in the custom document property - it is also in the application manifest.  And I thought the document property was deprecated or just not used - I certainly could be wrong about that.

    I actually changed the application manifest in previous versions of VSTO but haven't tried it in VSTO 4 (2010).  I was even able to get a %ProgramFiles% token working but something prevented me from using that approach (I don't recall the details).

    All the files are deployed to the same folder but if the document is saved elsewhere and then opened outside of the deployment folder it won't be able to find the customization.

    It sounds like I just need to test this approach with VSTO 2010.

     

    Thursday, June 30, 2011 6:19 PM
  • Hi,

    It sounds interesting.   Could you please try the approach and let me know whether it works.  Currently, I did not figure out such a workaround. 

    Have a nice weekend!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Friday, July 1, 2011 1:38 AM
    Moderator
  • Hi,

    Could you please let us know how is the problem now?

    If you need any further assistance, please feel free to let us know.

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Friday, July 15, 2011 4:45 AM
    Moderator
  • I am doing the same thing with a Word document level 2010 project.  I can't use clickonce because I have many other .dlls as part of a lager application set that the document works with.  I use a MSI project to install all the files into the Program Files dir for each user. 

    The user's have no shared network location so the install has to be on the local machines.  However, as RobertN128 says, the Program Files folder is differently named depending on if its a 32 or 64bit machine.  So if a user on a 64 bit machine, with a path of Program Files (x86)\myco\myapp sends a document to a user on a 32 bit machine with the path of Program Files\myco\myapp the vsto will not find the manifest because the path in the document is pointing to the wrong location. 

    So each user group, 32 or 64 can install the app and run the document just fine and share with other members of the 32 or 64 bit group.  but the two groups can't share the docs because the _AssemblyLocation path in the doc is wrong for the other group.

    So, I need a way to have the _AssemblyLocation path have a special folder token like %ProgramFiles% to get around the (x86) problem in the path.

     

     

    Monday, October 17, 2011 4:32 PM