2

Our entire team installed VS 2010(It has both VSTO runtime 2010 and .net framework 4).After installing that some of our developers are getting the below error (but for majority its working fine) while opening the deployed VSTO application from server developed in framework 3.5 and VSRO runtime 3:

***** Exception Text ******* Microsoft.VisualStudio.Tools.Applications.Runtime.CannotCreateCustomizationDomainException: Customization does not have the permissions required to create an application domain. ---> System.Security.SecurityException: Customized functionality in this application will not work because the administrator has listed file://fmrdmwaprd2/CA-INSTALL/Demand/Templates/GeoDSS_Templates_UTT/APAC_RevOpt_OEM_Good_Bad_News/APAC_RevOpt_OEM_Good_Bad_News_UTT.vsto as untrusted. Contact your administrator for further assistance. at Microsoft.VisualStudio.Tools.Office.Runtime.RuntimeUtilities.VerifySolutionUri(Uri uri) at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.CreateCustomizationDomainInternal(String solutionLocation, String manifestName, String documentName, Boolean showUIDuringDeployment, IntPtr hostServiceProvider, IntPtr& executor) The Zone of the assembly that failed was: MyComputer

satyajit
  • 2,540
  • 11
  • 33
  • 44
  • have you tried a full uninstall and then reinstall? – Daniel Casserly May 16 '11 at 05:15
  • 3
    were you able to resolve this issue? If so, please either post the answer you found (if the answer provided did not help) or accept an answer. This way we know that this issue is closed and we don't have to work on it any more. Thanks. – IAmTimCorey Jun 22 '11 at 04:54

2 Answers2

3

It sounds like your computers have "trust issues". Here is a link with more information about the trust levels for different locations / items and how you can change them:

http://msdn.microsoft.com/en-us/library/6exya3kf(v=vs.80).aspx

I also found this SO article that might be close enough to your issue to help you out:

Installing VSTO 4.0 Causes VSTO 3.0 Addin to quit working

Community
  • 1
  • 1
IAmTimCorey
  • 16,412
  • 5
  • 39
  • 75
  • 1
    Yep, check that LONG path. Looks like a UNC share, and generally speaking, office doesn't like to run Addin's from UNC shares, only from the local machine. – DarinH May 16 '11 at 16:15
2

I've run into this issue before and solved it. It's related to the fact that VSTO creates a custom AppDomain at load time for the VSTO AddIn. The action uses Shadow Copy to copy the VSTO .DLL into a temporary location and loads it from there.

Anti-Virus tools like McAfee actively kill this shadow copy operation, hence the AddIn will not load on protected computers, or any with tight security permissions.

To circumvent shadow copy, have your installer place your AddIn .DLL in the Global Assembly Cache. With it in the GAC, the Shadow Copy process is avoided, and the .DLL should load.

Keep in mind - this can cause issue with development, so do not deploy the .DLL into the GAC on your development machine. If you do, you'll not be able to run your changes in Visual Studio (the DLL in the GAC will run instead).

EricL
  • 68
  • 6