Why can I not change the update location of VSTO v3 Add-in or Document once it is installed?
Locked
- Why can I not change the update location of VSTO v3 Add-in or Document once it is installed?
Please remember to mark the replies as answers if they help and unmark them if they provide no help.- Edited byJi.ZhouMSFT, ModeratorWednesday, February 11, 2009 12:54 PM
- Edited byJi.ZhouMSFT, ModeratorSaturday, February 14, 2009 1:30 AM
Answers
The Path to the deployment manifest is used as part of the Identity for an Add-in. During the First installation of an Add-in or Document, the Full Path is set and stored by the VSTO Runtime for that client machine. Once you have installed an Add-in changing the path in the registration will cause the Add-in to throw an Error. Once you have installed a customized Document, the code-behind will only check the original location and changes to the path stored in the document will be ignored (this is to allow copying a local version of a customized document that you installed from a remote location). In order to change the location that an Add-in or Document checks for update, you must uninstall the “old” version on the installed clients and then install from the new location.
The low-level explanation is that ClickOnce uses the solution path as part of its identity when storing solutions into the ClickOnce cache. You will get similar behavior in a CO-deployed Windows Application as well unless you use the deploymentProviderURL (DPURL). Setting the DPURL can allow WinForms applications to change where updates are pulled from so that Server A (from which a solution was original installed) can be decommissioned and updates can be retrieved from Server B. VSTO does not support DPURL. At the time we were considering it during the development of VS 2008, the amount of development work-months required was more than the time we had remaining (DPURL has implications on migration of data from old solution to new solution, for instance). After much discussion, we decided to have the ClickOnce team throw an exception of a DPURL is set for VSTO solutions. At the start of development for Visual Studio 2010, we considered this feature again, but again this feature did not make our list of highest priority deployment features. We are implementing a lot of new deployment features for Visual Studio 2010.
For more FAQ about Visual Studio Tools for Office, please see Visual Studio Tools for Office FAQ
Please remember to mark the replies as answers if they help and unmark them if they provide no help.- Marked As Answer byJi.ZhouMSFT, ModeratorWednesday, February 11, 2009 12:55 PM
All Replies
The Path to the deployment manifest is used as part of the Identity for an Add-in. During the First installation of an Add-in or Document, the Full Path is set and stored by the VSTO Runtime for that client machine. Once you have installed an Add-in changing the path in the registration will cause the Add-in to throw an Error. Once you have installed a customized Document, the code-behind will only check the original location and changes to the path stored in the document will be ignored (this is to allow copying a local version of a customized document that you installed from a remote location). In order to change the location that an Add-in or Document checks for update, you must uninstall the “old” version on the installed clients and then install from the new location.
The low-level explanation is that ClickOnce uses the solution path as part of its identity when storing solutions into the ClickOnce cache. You will get similar behavior in a CO-deployed Windows Application as well unless you use the deploymentProviderURL (DPURL). Setting the DPURL can allow WinForms applications to change where updates are pulled from so that Server A (from which a solution was original installed) can be decommissioned and updates can be retrieved from Server B. VSTO does not support DPURL. At the time we were considering it during the development of VS 2008, the amount of development work-months required was more than the time we had remaining (DPURL has implications on migration of data from old solution to new solution, for instance). After much discussion, we decided to have the ClickOnce team throw an exception of a DPURL is set for VSTO solutions. At the start of development for Visual Studio 2010, we considered this feature again, but again this feature did not make our list of highest priority deployment features. We are implementing a lot of new deployment features for Visual Studio 2010.
For more FAQ about Visual Studio Tools for Office, please see Visual Studio Tools for Office FAQ
Please remember to mark the replies as answers if they help and unmark them if they provide no help.- Marked As Answer byJi.ZhouMSFT, ModeratorWednesday, February 11, 2009 12:55 PM
