We have a Microsoft word add-in that is working fine on the majority of pc's.
On a particular windows 7 pc, it has the visual studio 2010 tools for office installed correctly.
But when a user creates a new template word document, they get teh following error:
The customization assembly could not be found or could not be loaded.
You can still edit and save the document. Contact your administrator
or the author of this document for further assistance.
We have tried unloading all dependencies but still does not make any difference.
This is an issue effecting a small amount of windows 7 pc's with office 2016 installed. It seems to be pc related rather than the application.
Usually, the reason behind such an error is that the permissions for loading the VSTO solution are missing. One thing that often gets "missed" when deploying VSTO solutions is that the document must be in a "trusted location". You might want to check that this is the case by looking in the Word "Trust Center" (in the Options). You also need to be sure you've installed the correct version of the VSTO run-time for the version of Windows and Office. Read more about that in the Troubleshooting Run Time Errors in Office Solutions article.
Also it may indicate that you didn't include all required dependencies to your add-in's installer (any platform-specific assemblies). Something is missing on the target machines, so I'd suggest looking for any difference between machines. You can add the .NET Framework, the Visual Studio Tools for Office runtime, and the Office primary interop assemblies to your Setup package as prerequisites that are deployed with your Office solution. For information about how to install the primary interop assemblies, see Configuring a Computer to Develop Office Solutions and How to: Install Office Primary Interop Assemblies.
The required steps for deploying Office solutions are described in the following articles:
Deploying an Office Solution by Using ClickOnce
Deploying an Office Solution by Using Windows Installer
You can use the event viewer in Windows to see error messages that are captured by the Visual Studio Tools for Office runtime when you install or uninstall Office solutions. You can use these messages from the event logger to resolve installation and deployment problems. For more information, see Event Logging for Office Solutions.
See Troubleshooting Office Solution Deployment for more information.
Related
I have created a WIX Install MSI file for my Office Outlook Plugin. Everything runs fine however when i uninstall it through add/remove programs everything is removed except for the Plugin in Outlook. It runs but gives errors because the other components are now missing. How can I get it to remove it without going to Outlook and removing the plugin manually?
I have added the "RemoveFolder" tag in the XML which has no effect.
I'm guessing that you are doing some kind of active setup trick to do HKEY_CURRENT_USER registry propogation. I'd suggest not doing this and instead register the extension in HKEY_LOCAL_MACHINE. This way when the uninstall runs it can access all of the components that need to be removed. There are gotchas in terms of different patch versions of different versions of office and how they behave in terms of supporting per-machine registration of AddIns. Details can be found in blog articles that I've written over the years titled VSTO lessons learned.
I have an existing .Net application that does some Word Interop work. On one machine where I have Word 2010 installed, I am able to reference the Word PIA (Microsoft.Office.Interop.Word) with no problem, compile, run - everything is great. Now, I'm trying to test against Word 2013 to ensure that my application is compatible with it. So on another machine with only Office 2013 installed (no other instances of Office), I try to build the same exact source code, but get compilation errors because VS2010 can't find the Word PIA. I tried updating the reference of the PIA, but it does not show up in the list of available assemblies.
I checked my installation of Office - every component available is installed, including .Net Programmability Support for Word. I looked at the GAC in Windows Explorer, and the assembly appears to be there. I tried restarting multiple times.
My application targets the .Net Framework 3.5 (but I also tried changing that to 4.0). I'm working in VS2010 Professional, and I have Office Professional Plus 2013 installed on the box. What could I be missing??
Thanks.
I have created an office addin for Word 2010 targeting .net 4 and this should apparently work in office 2007.
I have created the installer per this article with the exception that I include a dll in the dependencies rather than in the bootstrapper for the prerequisites.
The installer installs the vsto and the registry keys in
HKCU\Software\Microsoft\Office\Excel\Addins\ProjectName
The pc also has .Net 4 and the Office 2007 Primary interop assemblies.
The addin doesn't appear in Word 2007, any ideas where I could be going wrong?
UPDATE:
You have to sign your addin, this was pretty obvious! Office now recognises the addin but its gets a runtime error that I can't debug. Tried to debug with these steps with no luck!
Had to build for correct CPU version of office, in my case 32bit, Any CPU didn't work!
My add-in targets Outlook 2007 and was built using C# with Visual Studio 2010. I have run into problems deploying this to different target machines by means of the SETUP.exe and "manifest" built by the Publish Wizard of Visual Studio.
My latest attempt to get this deployed to a target PC (i.e. one typical of other users where this will be deployed and lacking my development environment) gives strange problems:
the add-in installs OK (i.e. Setup had no complaints; program appears properly in Control Panel)
visiting Tools -> Trust Center -> Add-ins shows that my just-installed add-in is Inactive
clicking Go.. for the Manage COM Add-ins dialog & checking the box for mine then the Add.. button fails
a window looking like a browse dialog box titled "Add Add-in" comes up with "No items match your search" in the right-hand pane; at the bottom of this window is an empty textbox labeled "File name:" and a choice of "Executable Files" or "All files" for a file type. The add-in remains "inactive".
It is not clear to me what this dialog needs at this point to make it "active" (Load at Startup was part of the choices here).
NOTE:
The 2 projects in this solution were compiled for a "target framework" of .Net 3.5 resulting in references to DLLs such as Microsoft.Office.Tools.Outlook.V9.0 and his companions (I guess that is "VSTO 3.0 ??).
This solution launches Outlook properly on the development PC and the add-in is loaded successfully and runs as expected (against Outlook 2007 and/or Outlook 2010); so this seems related to deployement only.
Could there be a bug in the stuff built by the Setup wizard that comes with Visual Studio 2010? I read somewhere that the "manifest" can be "corrupt".
EDIT-UPDATE 3/31/2011:
I think I found the answer. I believe by using the "Publish Wizard" in VStudio which produces a SETUP.EXE, I was trying what is called "ClickOnce" deployment. Secondly, this addin for Outlook is NOT a "document level" addin but instead a "machine level" addin. Given these discoveries of better terminology, I found this at http://msdn.microsoft.com/en-us/vsto/ff937654.aspx:
"You can use ClickOnce to create and install self-updating applications with minimal user interaction. This has an automated mechanism for easily distributing updates to your application. However, ClickOnce is not capable of deploying components that require administrative privilege such as machine level add-ins. For solutions that require administrative privilege you can use Windows Installer to deploy a Visual Studio Tools for Office customization."
So, I will try to make a Windows Installer. Any confirmation would be appreciated.
I am confident the ClickOnce style of deployment will NOT work for my machine level add-in for Outlook 2007. Therefore, I am answering my own question by stating only that this requires a Windows installer (and setup) that can built with the properly chosen Visual Studio template.
The sad news is that in my testing of said installer .msi and associated setup.exe for the pre-requisites the install to my target machine went well but when I test the operation of the addin itself inside Outlook I get a terrible APPCRASH event in Outlook.exe:
Problem signature:
Problem Event Name: APPCRASH
Application Name: OUTLOOK.EXE
Application Version: 12.0.6550.5003
Application Timestamp: 4d10fbc4
Fault Module Name: kernel32.dll
Fault Module Version: 6.0.6001.18215
Fault Module Timestamp: 49953395
Exception Code: e0434352
Exception Offset: 000442eb
OS Version: 6.0.6001.2.1.0.256.1
Locale ID: 1033
Additional information about the problem:
LCID: 1033
Brand: Office12Crash
skulcid: 1033
So the answer is that ClickOnce is not appropriate. The .msi appears to properly install the add-in but at runtime it blows sky high. Remember the addin works properly at runtime when launched via Visual Studio. Why does deployment have to be so damned difficult?
Hello I have been fighting some complexities with understanding deployment of Primary Interop Assemblies (PIA) for MS Office. I have Visual Studio Com Add-IN built in VS 2008 on pure com technology (not VSTO see bottom of this for more on that), which references 2003 Primary Interop Assemblies but the add-in may be used on 2003, 2007 or now 2010 Office machines. Because I never know if the customer will be using 2003, 2007, or 2010, I cannot simply deploy one PIA version as a prerequisite (unless I make 3 installers which I do not want to do). Now, my understanding is that when you follow the steps here to add 2003 and 2007 PIA to the prerequisite lists that show up in a Visual Studio (2008) setup package, the prerequisites are smart enough to determine which office version is running on the client you are targeting. So if you were to select 2003 primary interop assemblies and 2007 primary iterop assemblies as both being prerequisites then when this installs on a machine that has 2003 it should be intelligent enough to only try to add the 2003 PIA if those are missing on this machine and if this is a 2007 Office machine then it will only install 2007 PIA (and not try to install 2003 PIA).
Question 1 is this a correct understanding (that the prerequisite packages are this intelligent to only install what it needs based on the version of Office?)
Question 2 is there a way to get the 2010 PIA to show in the list of prerequisites in VS 2008 like 2003 and 2007 do? I do not want to upgrade this project to VS 2010 b/c it is considered a legacy app now with many customers from all around the world using it.
Question 3 Even though the actual assembly references 2003 primary interops, I do not presently deploy those interops with the add-in to the install location. Instead, I am assuming that if I can get the correct PIA installed then I don't need this present in the installation path, since the PIA would be in the GAC. However, one possible approach may be to just include the 2003 assemblies that are referenced (in my case excel and word) in the install path and not worry about the PIA. I suspect this would work on 2003 machines but perhaps not on 2007 and 2010 machines b/c on the latter, even if the 2003 interops that are referenced are found at run time in the install path of the assembly, I think if there is not a Policy.11.0.Microsoft.Office.Interop.Excel/Word(etc) in the GAC, then 2007 and 2010 will likely not know what to do with the 11.0 (2003) interops (as I think the Policy.11.0.Microsoft.Office.Interop files redirect requests for the 2003 interops to 2007 or 2010). Any thoughts on this?
Question 4: There is a well known bug with Framework 2.0 apps Office Add-Ins and Office 2003 where the add-in won't load. This was addressed by KB907417 aka KB908002. Dopes anyone know if this KB necessary if you develop on the 3.0 or 3.5 framework (and make 3.0 or 3.5 a prerequisite) since this problem was specific to framework 2.0? Or does the KB still need to be deployed b/c it's office 2003 that is the problem and not the version of the framework?
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility. If the PIAs can be done with one installer but the KB above is the obstacle (as perhaps the answer will come back that even on the 3.0 or 3.5 framework 2003 customers will need the KB) then maybe the path to one installer is to just make the KB a prerequisite across the board and install it on 2007 or 2010 machines, though they technically do not need them. Any thoughts on that option would be appreciated as well. Finally, I am aware that writing a manged Com Add-IN for excel or word is now generally done with VSTO instead of pure managed framework code, but this is not an option presently to change the legacy app to this direction. Also it is reported that the 4.0 framework now can be used to deploy add-ins without making any PIA a prerequisite but again, this is not a viable option right now.
Does the code use any Office 2007+ methods or classes? If not, are you sure you cannot use the 2003 PIAs in all cases? The later apps should be backward-compatible (supporting the same API) so the only reason you'd need an updated PIA is if you needed to access some feature added by 2007 or later, I think.
You may want to take a look at Add-in Express, which promises a one-for-all-versions installer, and is pretty easy to use.
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility
You cannot. You must create custom installer packager (setup bootstrapper).
Many years ago I used dotNetInstaller with HTML GUI builder, today WiX toolset would be better solution, I think.
Check how PIA .msi installers are constructed with Orca or .msi and .exe installers flow checking windows installer logs.
Based on registry checks, file checks, installed product checks, windows versions, office versions you can create conditions whether component should be installed or not.
Oh and I advise making plugin installers without prerequisites and installing them conditionally with your custom installer bootstrapper.