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
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
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).
Related
I'm migrating a VSTO OUTLOOK add-in from 32-bit to 64-bit. It works well on Office 2007 32-bit. The goal is to make it run on Office 365 64-bit.
I have recompiled the add-in for a 64-bit plateform and updated the installshield project.
When I install the add-in on a new Windows 10 machine using my account (I have admin privilege), it works fine. I can see it in Outlook and I can use it.
However, if I log out and ask someone else to log in on the save machine (this someone else also has admin privilege), the add-in shows up in Outlook but this error is shown when the user uses it:
System.Runtime.InteropServices.COMException (0x80040154): Retrieving
the COM class factory for component with CLSID
{29AB7A12-B531-450E-8F7A-EA94C2F3C05F} failed due to the following
error: 80040154 Class not registered (Exception from HRESULT:
0x80040154 (REGDB_E_CLASSNOTREG)).
Any idea?
Details:
This add-in uses only one external DLL: a 64-bit DLL from Redemption.
The solution has been compiled in Visual Studio 2015. Platform target: x64.
To install it on a computer, I use a MSI that I've created using InstallShield Express on Visual Studio 2015.
In InstallShield, I have specified ALLUSERS-1 (Per-machine installation).
The DLL is registered using the following code:
Dim WshShell
Set WshShell = CreateObject("Wscript.Shell")
WshShell.run "regsvr32 /s ""C:\Program Files (x86)\MyCompany\AddInName\Redemption64.dll"
Set WshShell = nothing
Actual Steps: Just an attempted, pragmatic summary on top: 1: Whilst logged in as the second user, try to launch regedit.exe and export HKCR (maybe HKCU as well), then register the COM dll, export again and diff with a suitable diff tool (if the launching worked at all that is). 2: Download ProcMon.exe and monitor your application / add-in launch to determine what is going on.
3: Use Visual Studio and step-through and checking the Modules view to determine what is going on during launch. 4: Use oleview.exe to see what registration the COM file requires (open embedded typelib). File => View Typelib.... More details below.
Quick Check: Maybe check this first: Outlook Redemption - using RedemptionLoader without regsvr32 the DLL.
Also, did you shut down everything before the second user logged on? Or did you just switch users? Maybe try both, make sure your first login has nothing loaded or locked.
The below "registration debugging" might miss the target. It looks like this could be something more peculiar. Maybe just skim it.
Deployment Mnemonic: Maybe try this deployment mnemonic. A little paragraph with reminders how you can think to try to solve deployment problems: "What is locking, what is blocking, what is missing, etc..."
Registration: Though this looks like a simple missing registration, it could be something more peculiar. I have this application launch check list that you can skim. Not written for add-ins, but might give you some ideas.
regsvr32.exe: Did you try to run regsvr32.exe manually as the second user to check if that works? Though it is possible to register a COM file per-user, I don't know of a way to use regsvr32.exe to do so that is reliable.
ProcMon.exe: Are you familiar with using ProcMon.exe? Her is a rudimentary example. And Hanselman showing how it is done (YouTube). You can use that to try to determine what is failing and when. Needs some practice to use effectively, but it is my "first and last resort".
Visual Studio: I like to use Visual Studio to step through the code and look in different windows (modules for example) to understand how the application works and hence to determine what can be wrong during launching.
oleview.exe: To figure out what a COM-file registers during self-registration there are several ways. Launching oleview.exe with admin rights and then going File => View Typelib... and then locating the COM file you want to check and opening gives you the embedded IDL details.
RegSpy2.exe: Alternatively you can use RegSpy2.exe for COM registration extraction. See sample here.
Capture Compare: Finally a setup capture tool can be used for debugging. It scans the registry (and disk) for before and after changes. In other words you make a baseline, register the dlls and then scan for differences. The reliable tools are expensive (AdminStudio, Advanced Installer Architecht, etc...). The poor man's version of a setup or registration capture is to export HKCR before and after using regedit.exe, and then diffing with a file/text-diff tool.
Self-Registration: Self-registration is not recommended for COM registration as described here: MSI register dll - Self-Registration considered harmful. In Installshield you can simply register a COM file by extracting the COM data at build as illustrated in the image below. You can also enable COM-Interop registration in the same list by setting the flag ".NET COM Interop" to yes:
.
COM Interop: .NET assemblies can be registered for COM use using regasm.exe. That is (almost) the same as the .NET COM Interop setting mentioned above set to "yes". If you want to use a COM file from .NET you need to generate an Interop assembly file and then installing and registering the real COM file (which you do). Both operations must be performed.
Throwing in a couple of links. These (ancient) articles deal with the use of regasm.exe, tlbexp.exe, tlbimp.exe and gacutil.exe. Not needed for you, but leaving in for reference:
Calling COM Components from .NET Clients
Calling a .NET Component from a COM Component
Some Links:
Registering COM EXE with WIX
Registering a CPP dll into COM after installation using Wix Msi installer
Application is not getting opened after installing it with the installer created by "Visual studio installer"
First let me get this stuff out of the way:
This happens with my own addin, as well as another third party VSTO add-in, so I don't think I'm doing anything incorrect
.net 4.0. VSTO runtime 10.0.50701
Windows 8. Also tried Windows 7
I am using the |vstolocal suffix in the HKLM registry for the addin
I have also tried adjusting the 'program files' paths in the registry here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion to point to my new 'F:' location, and that didn't change any behavior
Here are the steps I'm taking:
Create a new volume on a separate disk other than C:. I called mine 'F:'
Add the program files structures F:\program files and F:\program files (x86)
Install your VSTO addin (I'm using Outlook but it will happen with Word too) to "F:\program files (x86)" instead of the 'C:' drive
Launch Outlook.
Result is this dialog:
According to this, I shouldn't be getting this since its an all users install (see the Inclusion List section):
Is this a Microsoft issue? I realize I can add to the Inclusion myself however then I would be subscribing to more of a per-user approach, and that seems like a bad approach. Is this coming up because anything other than the 'real' program files folder cannot really be trusted by VSTO loader?
The dialog window belongs to the ClickOnce installer. But the link goes to the Windows Installer section in MSDN.
It is up to you where to install the add-in, there is no need to use the Program Files folder.
Make sure that you did all the steps described in the Deploying an Office Solution by Using Windows Installer article. It describes all the required steps for creating add-in installers.
I recently went through the same thing, i got this when i just published the vsto from vs2015. I tried using installshield, yielded the same issues, eventually i switched to wix installer, now i don't have any update checks running and its a clean install. These are some customization updates and our client actually had a firewall blocking it so the install failed. Try wix it worked great for me. Hopefully you don't end up with my current issue of not seeing the add-in if i am not running outlook as Administrator, driving me nuts, good luck.
I'm following the excellent tutorial by Malte Ahrens on how to create a OneNote add-in.
Initially I followed it step by step, making a few changes (just renaming the class, and using my own name and GUID in the assembly) info. As I'm using VS2012 and am not yet ready to hand-roll a WiX installer I manually copied over the built dll to the correct place and also created a registry file to make the requisite entries. I confirmed that they were all there, loaded up OneNote but no add-in, going to "mange COM addins" section I saw the following error:
Load Behavior: Not loaded. A runtime error occurred during the loading of the COM Add-in.
I spent some time debugging this but didn't get very far. So this afternoon I decided to start again but copy his code verbatim. I simply downloaded the example project, used the trial of Vdproj to Wix to create the installer and built everything.
I get the exact same error.
Why is this please? What does this mean and most importantly how do I debug the problem?
A few specifics about my environment and where it may differ from the original tutorial.
I am running Office 2013 AND it's 64bit. His tutorial is for 2010. This means when I loaded up the demo solution I had to remove the non-existent reference to the Onenote 14 Interop and add the v15 version.
In terms of registry entries they go to the right place, not the WOW6432 registry nodes. I doubly know this as if I load up OneNote and then refresh the HKCR registry node for the add-in, the LoadBehavior switches to 0x00000002, (disabled).
Other things that may be worth noting.
I have enabled OneNote logging and it's quiet on my issue.
There are 2 other posts on here with a seemingly similar problem (but Office 2010) here and here, neither got a response. The first guy had it loading once, but then had to manualy start it each time, mine never loads (and I've not signed my assembly) the second guy never got a response.
As I say, even knowing how to debug this further would be a great step forwards.
Edit:
I've gone back to debugging my own version, which is almost identical anyway as I'm not sure what the installer is actually doing and I think because it's a demo of the wix converter it's only allowing me to build for x86.
If I add OneNote.exe under "start external program" and run debug on my add-in, I see the following lines appear when I try and tick the add-in under "manage COM add-ins" within OneNote. I'm afraid I'm still pretty green at all this so I'm not sure what it means.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
Also, since reading up more I think me simply copying my dll into the install folder program files\[manufacturer]\[application] (as I don't have an installer) was not enough. I've now executed this against my dll
PS C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319> .\RegAsm.exe
and it came back with
Microsoft .NET Framework Assembly Registration Utility version 4.0.30319.33440
for Microsoft .NET Framework version 4.0.30319.33440
Copyright (C) Microsoft Corporation. All rights reserved.
Types registered successfully
Is there anything else I should be doing to register the dll correctly?
Enable logging for OneNote 2013:
Create a file "EnableOneNote2013APILogging.reg"
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\OneNote\Options\Logging]
"EnableLogging"=dword:00000001
"EnableTextFileLogging"=dword:0000001
"ttidLogObjectModel"=dword:00000001
"ttidLogObjectModelAddins"=dword:00000001
Create a file "DisableOneNote2013APILogging.reg"
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\OneNote\Options\Logging]
"EnableLogging"=dword:00000000
"EnableTextFileLogging"=dword:0000000
"ttidLogObjectModel"=dword:00000000
"ttidLogObjectModelAddins"=dword:00000000
This is based on http://blogs.msdn.com/b/descapa/archive/2006/12/08/debugging-the-onenote-api-enable-logging.aspx but you need to add EnableTextFileLogging ;-).
The logfile is created in %temp%\OneNote.log
For OneNote 2010 change the path in the .reg files to \14.0\ instead of \15.0\
I have an VSTO excel 2007 Add in. For this I have created a Click-once deployment utility. I distributed this various clients who can just double click the .vsto file or set-up.exe and install the add in.
It has worked fine for all clients except one. Clearly it has something to do with the particular client system but as I don't have rights to log in and check my hands are tied.
The exception is shown below. has anyone had a similar situation ? Since the message does not have much info I am a bit stuck.
Name:
From : file////C:/ExcelAddin/Adding.vsto
System.NullReferenceException : Object reference not set to
instance of an Object at
Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager
.GetManifests(TomeSpan timeout)
at
Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager
.InstallAddIn()
My experience with VSTO clickonce install is not extensive but I know that this is not a VSTO / installer issue but issue with machine or security settings.
FYI all client are local admins.
Got it resolved by reinstalling Dot Net framework 3.5 SP1 .
I have an Excel VSTO AddIn that I moved up to Excel 2007/VS2010 last fall. I tried using ClickOnce but the headaches involved with that were just insurmountable and every install became a manual one. I moved to to a MSI setup, but now that is starting cause problems when upgrading. I have a machine now that will not install it properly, and when I try to run the VSTOInstaller.exe manually, I get the following error. I have cleaned EVERYTHING off the system and tried multiple times to get this to work, but no dice. Normally it creates a whole bunch of garbage files in the "Users\Apps\Local..." area, but not I get nothing. I have tried rebuilding with various configurations, all of which result in the same error:
System.Runtime.InteropServices.COMException (0x800736B3): The referenced assembly is not installed on your system. (Exception from HRESULT: 0x800736B3)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.GetManifests(TimeSpan timeout)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.InstallAddIn()
Basically, I hate ClickOnce and I'm totally frustrated right now. How do I create a "normal" setup app for VSTO?
Thanks!
Tip 1:
You might have to install:
Microsoft Office 2010 Primary Interop Assemblies Bootstrapper Package"
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=5d57c998-b630-4f38-afaa-b79747a3da06&displaylang=en
(Probably your machine has only the 2007 version of the bootstrapper currently.)
Tip 2:
Run program "mage.exe" with the -cc (ClearApplicationCache) option
http://msdn.microsoft.com/en-us/library/acz3y3te.aspx
Good luck.
I was finally able to track it down to the ClickOnce cache, which I was very disappointed about because I was hoping that the MSI would have no ClickOnce to deal with. Once that was cleared by manually deleting the folders, I was finally able to get it to install. But ClickOnce is a simply awful install application.
Not a lot to go on here, but are you sure you've got the right .net runtime installed? With 2010, you may have targeted the client or compact framework, or maybe .net 4.0, but the target machine had an older .net on it. There is also a way to log all the DLLs that an exe depends on as the EXE is requesting them, during the load process, but for the life of me, I can't recall what that process is called so I can't post any links to that right off.