Recently I upgrade my Office to Office 2013(64bit) on Win8.1(64bit). But the add-in dll files can not be registered by "regsvr32.exe {dll path}", in the same way I can create Excel Add-in by using delploytool for Office 2010(64bit).
Anybody know how to make Excel 2013 (64bit) work with the Excel Add-in generated by DEPLOYTOOL?
Cheers,
Cross
It is recommended to use Office 32bit even if you are using Windows 64bit, because of compatibility issues with add-ins. Office 32bit is fully supported with Windows 64bit
If the dlls are 32 bit then, I'm afraid, you're out of luck: a 32 bit dll cannot be loaded into a 64 bit process. That's an operating system level constraint.
Your only option is to downgrade your Microsoft Office to 32 bit. Then you get your 32 bit dlls back. But to register them, you need to use the regsvr32 executable in C:\Windows\SysWOW64\ (the normal place for the 32 bit compatibility programs). Then you can add references in the normal way.
Related
Problem
I can't get 64-bit Word to load (or acknowledge the existence of in any way) an otherwise working Word VSTO add-in.
Discussion
I have a working Word VSTO add-in that I developed using Visual Studio 2017 on a 64-bit Windows 7 machine running Microsoft Office 32 bit. I use a WIX installer to deploy the add-in. I successfully deployed the add-in to a Windows 7 64 bit "master" gold disk that runs 32-bit Office, i.e., the add-in is available to any user who brings up a virtual desktop from the master gold disk. See Nova Sys Eng S.O. answer here for details.
Now, my organization is replacing Win 7 64-bit VDIs running 32-bit Office with Win 10 64-bit VDIs running 64-bit Office. In preparation for this, I created a 64-bit Win 10 development machine, installed Office 64-bit, Visual Studio 2019, the WIX Votive2019 extension, and the WIX toolset. On this development machine, I built a release version of the add-in and installed the MSI on this development machine. When I bring up Word on this development machine, it works fine.
Next, I carried the MSI built on the development machine to the 64-bit Win 10 master gold disk machine (again, running Office 64-bit) and successfully installed the add-in (i.e., the WIX installer finished without error). I also installed the VS 2010 Tools for Office Runtime (10.0.60828 released 2018) on the 64-bit Win 10 master gold disk machine. Just like on the 64-bit Win 7 master gold disk (Office 32-bit), the add-in was installed on the 64-bit Win 10 master gold disk machine in
C:\Program Files (x86)\FooAddIn
and the registry settings are
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\Word\AddIns\FooAddIn]
"FriendlyName"="Foo Add-In"
"Description"="Foo Word Add-In"
"Manifest"="C:\\Program Files (x86)\\FooAddIn\\FooAddIn.vsto|vstolocal"
"LoadBehavior"=dword:00000003
When I bring up Word on the 64-bit Win 10 master gold disk machine, the add-in does not load because, apprently, Word is unaware of its existence, i.e,. when I look at Word Options -> Add-Ins, the add-in is not present at all. When I select COM Add-ins -> GO, the COM ADD-ins dialog also does not show the add-in.
One more item:
On the development machine, the Build Config Manager look like the following, i.e., the Platform for the WIX installer program (FooAddInSetup) is set to x86, and there are no other options available.
Why won't Word acknowledge the existence of my add-in?
Is the fact that the add-in is installed in Program Files (x86) an issue?
Is the fact that the Platform for the WIX setup program is x86 an an issue?
I stumbled across Addins for Office programs may be registered under the \Wow6432Node. The part that helped me is this:
Even though I built the add-in on a 64-bit machine that has 64-bit office, the WIX installer set things up such that when I ran the MSI on the Win 10 64-bit gold disk machine (that has 64-bit Office), it added the reg settings to the HKLM\Software\Wow6432node as though the machine has 32 bit office.
I manually created the same reg key settings under HKLM\Software\Microsoft, and the add-in loaded just fine.
So, I have to figure out what I need to do to the WIX config settings to make it right for a machine that has 64-bit office on it.
BTW, the Microsoft page Registry entries for VSTO Add-ins seems to have it backward:
having trouble with getting my new Windows 7 laptop with 64 bit Office 2013, to integrate with Quickbooks 2013 from MSAccess 2013, using QBFC 11. Previous version that worked was Windows XP 32 bit, Access 2010 and QB 2013, with same QBFC11.
Using the new install, integration code fails immediately with "error 429 Active X component can't create object" when i try to create a session requestmsgset. I have searched a bunch to find non-specific answers which don't seem to apply or give me clues, does anyone have any idea how to fix this for Quickbooks?
thanks!
When installing Office 365 (the sister product to Office 2013), you are given the option to install 32-bit or 64-bit. But it recommends you use 32-bit, saying that most software is still operating with only 32-bit hooks and that a 64-bit version of Office will not work properly. I don't know that this is your difficulty, but that's what I would look at first.
I am looking for the safest way to detect what components of Microsoft Office, if any, are installed on a given workstation. I realize this could be seen as a question for Serverfault as well, but since I'll be using this in a script and many people here are more familiar with the inner workings of Office, I thought this would be the best place to ask.
I've looked at the uninstall key, but it shows components that do not actually exist on the system. I believe this has to do with the way Office can install a component on first access. I'm not fond of looking for executables as the path can theoretically change.
I ended up testing for specific registry keys, taking into account the differences between 32 and 64-bit Windows installs. I'm paying attention to the following registry locations/values:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\—The base Office12 key on a 64-bit Windows install
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\—The base Office12 location on a 32-bit Windows install
Office base path\Outlook\InstallRoot\Path—Key signifying Outlook installation path
Office base path\Registration\{90120000-0012-0000-0000-0000000FF1CE}—Key for Office 12 Standard GUID
Office base path\Registration\{90120000-0011-0000-0000-0000000FF1CE}—Key for Office 12 Professional Plus GUID
With these locations I've been able to:
Detect whether Office is installed.
Detect the version of Office that is installed.
Detect whether Outlook is installed.
I have not attempted to get any more granular than this.
If you really think you cannot rely on paths to exe's or dll's, I would diff the registry (many tools for this exist) of before and after snapshots of installing the various components. In my experience however, I find it necessary to test existence of dll's and other files for detecting installed components for Office (I had to test for VBA dlls to detect presence of visual basic module installed, for example). The paths of files can only change so much. You just need to be cognizant of 32-bit and 64-bit patching, and winxp and win7 pathing.
We have a scenario where we require a plugin to do some custom steps in CRM 2011.
The client PC's are running 32 bit Outlook, due to the requierment for some silverlight applications extending crm, and Silverlight not supporting 64 bit.
Hence the plugins are failing when offline, presumably due to Outlook 32 bit not being able to launch 64bit plugin. The O/S's are all x64.
I have tried to deploy a 32 bit sampleplugin.dll to the CRM Server, but cannot register it, as I get a BadImageFormatException.
I just want to know if this is possible or not at all ?
I am guessing it's not possible, but just want some confirmation.
Thank,
Steve
You have to develop your plugin without a specific target architecture, this means you have to target Any CPU.
Dynamics CRM 2011 is 64 Bit on the server side. The plugin will be therefore executed in 64 Bit processes. That is the reason why you are getting the BadImageFormatException
You could not be sure, if you have 32 Bit or 64 Bit on the client side
In Visual Studio, are you explicitly targeting x64 when you build the plugins in VS? If so you might try All CPUs instead.
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.