I have Visual Studio 2010 installed on my Windows XP development machine along with Office 2007 Professional and Office 2010 Professional. I am trying to develop several add-ins for Office 2007; however, I prefer to use Office 2010 on a day-to-day basis.
How do I set Visual Studio 2010 to install the add-in and open Word 2007 when I press debug? Currently, Word 2010 opens, but does not recognize the add-in. Unless I have to, I would like to keep Office 2010 installed.
I don't know the specific answer to your question, but I am running Office 2010 and still working on Office 2007 add-in development.
My solution to this problem has been virtual machines. I don't do any development work on my laptop's primary OS. I don't even have Visual Studio installed there, but I am running Office 2010 and really like it so far.
For development I've got dozens of different VMs with various configurations of OS and Office version and other 3rd party software that I need to integrate with. I'm currently using Windows 7 and the new version of Windows Virtual PC, but I started this practice when I was using Windows XP and Virtual PC 2007.
One benefit of this is that if something goes wrong on one of my VMs, it doesn't bring down my whole machine.
I also don't start from scratch each time I need a new VM. I've got base images with only the OS installed, as well as OS + Office and OS + Office + Visual Studio, but nothing else. That way, whenever I need a new VM, I just make a copy of the base image that's closest to what I need and go from there. The only limitation is that the base images can't be joined to a domain, but that's not a big deal for me.
I would encourage you to try this yourself. It works great.
Related
I am trying to create an Office add-in, mainly for Word, that consists of a simple Task Pane that displays search results from a website. I need it to work in every version of office, as far back as Office 2010. So I have chosen to create it in VSTO, as that seemed to be the most backward compatible approach. My problem is I don't have Word 2010, 2013, 2016, 2019, etc, to test that the add-in works in them, nor do I have any idea of how to build the add-in for backward compatibility in the first place.
I've searched through countless tutorials, Microsoft docs, Stack Overflow answers. I'm stuck. I know it's technically possible because the Grammarly add-in works in Office 2007 thru 2021/365.
Is it even possible for a little dev like me to create an add-in for Word 2010 in 2022?
I am using Visual Studio 2021.
As far as I know Grammarly uses a shimmed COM add-in skeleton (most probably written in C++) which implements the IDTExtensibility2 interface. But VSTO does this for you out of the box by hiding all the complexity COM add-ins could have on board.
Is it even possible for a little dev like me to create an add-in for Word 2010 in 2022?
Yes, of course. It is not necessarily to create C++ COM add-ins, you can easily start creating VSTO add-ins for that. You just need to choose the right .net framework version for that.
The Run solutions in different versions of Microsoft Office article shows Office versions that can be supported by your add-in created with Visual Studio 2022 or earlier and target .net frameworks that can be used for that. Depending on the .net framework chosen you can support different ranges of Office application versions, in short.
The Visual Studio Tools for Office Runtime page lists the VSTO Runtime releases and the corresponding version of Office for which its support lifecycle follows. The Visual Studio 2010 Tools for Office Runtime (VSTO Runtime) ships with various versions of Visual Studio and Microsoft Office and follows the support lifecycle of the parent product. It is recommended that developers install the latest version of the VSTO Runtime with their applications. It will be supported when running with supported versions Office. If the VSTO Runtime needs to be serviced, only the latest version will be updated.
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:
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!
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.
I have developed an application level add-in for Outlook targeting Outlook 2010 and .NET 4 and I want to run it on Outlook 2007, which should not be a problem due to the new "no pia" feature of .NET 4 (see this blog post).
However, after deploying the add-in with my Windows Installer package (the same package works for Outlook 2010), the add-in does not get loaded correctly and its load behavior is set to 2.
The test machine has the following software installed (in the given order):
Microsoft Windows XP with Service Pack 2 (x86)
Microsoft Office 2007 Enterprise
Windows Installer 3.1
Microsoft Windows XP Service Pack 3 (x86)
Microsoft .NET Framework 4.0 (Extended)
Microsoft Visual Studio 2010 Tools for Office Runtime (x86)
The utility assemblies are included in my deployment location and the add-in is registered correctly (shows up in Outlook trust center and deployment manifest is also included). I do not reference any third party libraries.
The strange thing is that the CLR 4 is not even loaded into Outlook, which I can see through the Visual Studio 2010 Remote Debugger. When I create an test add-in on my development machine and throw an exception on add-in startup, the load behavior also gets set to 2 on startup (without debugging), but at least the CLR 4 gets loaded into the Outlook process. Has anyone ideas what (probably missing dependency) could cause the VSTO 2010 Runtime to not load .NET Framework 4? I have also tried reinstalling VSTO which caused no effect.
Best Regards,
Oliver Hanappi
I found the solution on the msdn forums. There is a problem when no clr 2 is installed. A hotfix is required in this case. For more details see http://social.msdn.microsoft.com/Forums/en/vsto/thread/d95cc828-fdb9-4622-bf09-291a25cea81b.