we have a mixed environment. Some workstations have Microsoft Office 2010 installed while others have Microsoft Office 2007 installed. A lot of our in-house developed applications are referring to the Outlook 12.0 object library and the Excel 12.0 object library. In Office 2010 these are referring to the 14.0 object libraries. Is there a way when users launch an Access application that it checks which version of Office they have installed and when it detects either Office 2007 or Office 2010 so that it can programatically set the correct references to the Object Libraries?? Many thanks for any help and/or suggestions.
Set the references to use the earliest version of the reference and Ms Access will automatically upgrade the reference for later versions of Access if needed.
For example, if none of your workstations use anything less than Access 2007, you should set the reference to Excel 12.0. Any workstation using Access 2010 or 2013 will update the reference automatically for their local copy
I've had similar conflict issues between office 2010,2013 and 2016.
I think the whole point of initiating this thread is that "should" <> "does"...
Meaning that programing to the earlier version does not "always" work when the user PC is not running the exact same version of MS Office that was used during development.
I think maybe need to somehow add both object references to the compiled version and then the app can pick.
In other words, I think the development PC needs to be running both versions of Outlook.
You could also alternatively develop the app on a PC running the earlier version and then save off a copy to be compiled in a newer version of office on a different PC. You'd be basically generating versions specifically for each version of Office.
Related
I am looking for the way to implement MS Word plug-in for Mac and Windows. The plug-in should work with all versions of Microsoft Office (Microsoft Office 2003, Microsoft Office 2007, Microsoft Office 2010, Microsoft Office 2013, Microsoft Office 2016) and should work on Windows XP - Windows 10. It should work on MS Word on Mac also (at least on the latest versions).
It seems to be impossible to create one app for all of this OS and versions.
Description of the plug-in: The plug-in should help user to find the definition of any word (the definition will be in the beginning of this file or in the other file on the user's local disk). For example, user place mouse over word "math", a plug-in shows pop-up with definition "Mathematics (from Greek μάθημα máthēma, “knowledge, study, learning”) is the study of topics such as quantity (numbers), structure, space and change".
I am thinking about some variants of implementation.
First variant. I can make plug-in with help of WinForms and Microsoft.Office.Interopt for all Windows OS and versions of MS Office. I can create add-ins for Word on Mac with help of JavaScript. (Add-ins on JavaScript don't work on Microsoft Office versions < 2013).
Second variant. I can create plug-in with help of VBA for both platform and for all versions.
Are these variants possible? What the best way to create plug-in for Windows and Mac?
First variant. I can make plug-in with help of WinForms and Microsoft.Office ...
This, sound to me, way you should go if you would like to support older Office products (2010 and older). You would create VBA or COM/VSTO version for older versions on Windows. For older versions of Mac (ex:Entourage) you should consider AppleScript scripting extendability. Office Add-in (JS API) for newer versions on Windows and Mac together.
Second variant. I can create plug-in with help of VBA for both platform and for all versions.
No such thing as VBA add-on for Mac. You may efficiently use AppleScript for scripting certain actions in older Office for Mac.
This is all about your requirements. At the end you will make your decision. I would go with Office JS API as the start and later on see if you have strong demand of your app for older versions of Office.
Yes it is possible, but refine your requirement.
Go for Apps for Office (Windows + Mac) and not Com Add-ins (Only in Windows).
I have a Visual c++ application that uses imports on the office COM components to manipulate office documents.The app relies on the installed office version on the users' machine.The example below is a section of a type library header that I have generated for excel from my installed office version(2010):
// Created by Microsoft (R) C/C++ Compiler Version 10.00.40219.01 (e8ba858a).
//
// d:\play_ground\pimawordtopdf\release\excel.tlh
//
// C++ source equivalent of Win32 type library C:\\Program Files (x86)\\Microsoft Office\\Office14\\EXCEL.EXE
// compiler-generated file created 11/26/14 at 09:02:55 - DO NOT EDIT!
//
// Cross-referenced type libraries:
//
//
#pragma once
This is working great on my other test machine with office 2007 installed but some things fail to work properly on a machine with office 2013 . My question is: are type libraries for microsoft office backward compatible so that those generated with 2010 work for 2007 .If this is true I would have to generate 2013 type libraries and compile my app with them so it works on 2013 ,2010 and 2007 .
Thank you for your time.
Yes, type libraries are backward compatible until you use only types available in all Office versions, not new members from the latest versions. You will get an exception if you try to call a member which is missed in the old Office version. That's why I'd suggest using the oldest type library, for example, for Office 2007 if it is the min supported version. If required, at runtime you can check the Office version, and if the code is run against the newest version, you may call new members.
but some things fail to work properly on a machine with office 2013
Could you please be more specific? Did you try to debug the code? Do you get any exceptions?
Finally, you may find the Office Automation Using Visual C++ article helpful.
They should, but they don't. It's Microsoft we're talk about, so they can do whatever the heck they want.
They did break that COM interface and it's no longer backward compatible.
For example, if you're using Shapes.AddMediaObject, then you're in trouble because it's deprecated Shapes.AddMediaObject2.
reference: https://msdn.microsoft.com/en-us/library/office/ff744080.aspx
I am writing an application in VB.NET that will send emails using outlook. My problem is that I need the Office 2010 PIA to do this. The following are the steps I have already tried (I am using Visual Studio Express 2012):
Restarted the machine
Downloaded Office 2010 PIARedist and installed it
Restarted Visual Studio
Restarted the machine again
Uninstalled Office and the PIA and re-installed Office, making sure that the PIA was selected in the installation options (it was already selected by default, so presumably I installed it the first time I installed Office as well).
Restarted the machine again
Downloaded Office 2010 PIARedist and installed it again
Restarted VS
After each of these steps, the PIA is still not available in "Add Reference" in VS, nor do the files exist on my computer at all (a search for "Microsoft.Office.Interop.Outlook.dll" confirms this). I am running Windows 7 on my MacBook Pro. Does anyone know what my problem is here? This seems like a ridiculous amount of headache for such a simple feature.
PS The only reason I need the PIA is to be able to add CC recipients on the email. That's it. If anyone knows how to do that without the PIA, please let me know because I'd much rather just do that and be done with it.
PSS Both times when I installed the PIA itself, the installation ended silently (no indication of success or failure).
In case anyone stumbles on this question, I finally figured out how to add the interop. For some reason, it won't show up in the "Add References" window (maybe it's because I have VS2012 (11.0) and I'm using Office 2010...?) Anyway, I had to manually browse to it to add it. It was located in C:\Windows\assembly (all of the Office 2010 interops were in there). Also interesting was that a search of the entire C drive for 'Microsoft.Office.Interop.Outlook' or shortened versions of that string turned up absolutely no results, even though they are on the drive. One last note: although 'Microsoft Office 14.0 Object Library' shows up in the "Add References" window, adding that reference did not allow access to the interop.
On my development PC, I uninstalled Office 2007 and installed Office 2010.
I have a VS 2010 Solution that has several Excel 2007 templates (projects).
When I open the Solution, VS wants to "upgrade" the project (to Office 2010). I cancelled out of that and in the VS options, I turned off "Upgrade to latest version of Office".
Now, the solution opens fine, but the Excel 2007 template projects will not load or open. All the clients that run this appication have Office 2007 intalled, so I need to be able to continue to develop this application and target Office 2007.
Can anyone tell me how to do that? (I downloaded and installed the Office 2007 PIA...)
Thanks!
As a rule I always suggest running the version of office on your development machine that you are targeting, otherwise you loose F5 support and things often don't work as they should.
Another point is that if you do upgrade to Office 2010, the add-in will still work on 2007, as long as you do not access any of the 2010 API's. So technically if you upgrade the project to 2010, then remove the reference to Microsoft.Office.Interop.Excel v14 and add v12, that will restrict you to office 2007 API's, and you shouldn't have a problem.
Just give it a go, upgrade the project, then try install it into Office 2007, it should work fine. If not, just undo/revert your local changes.
I think your problem is VSTO, VSTO 3.5 was office 2007, vsto 4 comes with VS2010 and is Office 2010.
You might check on what versions of VSTO are currently installed and make sure you've got the right ones.
I am struggling to apply an existing 32bit COM addin to 64bit Microsoft Word 2010.
To make the addin visible to Word, I have used the dllsurrogate-method, as it described here.
The problem is that now addin caused some strange exception when tries to add its toolbar and menu to office's. I cannot figure out, what it is, it seems, that the command bar reference became not valid in unpredicable moments.
Can anyone explain this?
Note, that everething is fine when I use the same addin under 32bit Microsoft Word 2010 and more old versions of Ms Office.
32-bit add-ins are not supported on 64-bit. Microsoft recommends to use the 32-bit version of Office unless you run into the memory limitations of a 32-bit process which is only likely to happen if you need to deal with extremely large spreadsheets:
The recommendations for which edition of Office 2010 to install are as follows:
If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on previous versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2010 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems.
If some users in your organization are Excel expert users who work with Excel spreadsheets that are larger than 2 gigabytes (GB), they can install the 64-bit edition of Office 2010. In addition, if you have in-house solution developers, we recommend that those developers have access to the 64-bit edition of Office 2010 so that they can test and update your in-house solutions on the 64-bit edition of Office 2010.
If you need to go with the 64-bit version because of the memory limitations you have the following options:
If you have the source code, you can generate a 64-bit version yourself,
You can contact the vendor for an updated version,
You can search for an alternative solution.