I'm developing an office-js addin for corporate client which insists on using legacy versions of Excel (1708 or 1808).
But when I install excel from office 365, I get version 1906.
In the old days, with software, there were installers you could find in a directory that had version stamps on them, and you could create a VM, and just install the version you wanted. But the fancier installers appear to download stuff automatically and always (at least default to) the latest versions.
How do I install a legacy version of Excel on a VM for testing?
There's no special process for getting an earlier version when you are testing add-ins. It should be the same process as an end user would use. Please try the steps at this article: Revert to an earlier version of Office. I think you can find the build numbers that you will need either from your customer or from this page: Update history of Office 365.
Related
I'm developing an application written in Visual Basic 6.0 that supports exporting listViews to Microsoft Excel documents. Everything works perfectly fine if a user has an older version of Microsoft Office installed.
Now I want to add support for users who only have Microsoft/Office 365 on their systems. I've googled my way into depression in the past couple of days because I don't know much (or anything really) about dll/ocx files or registries. I'm not even sure if something like this can even be done because VB6 is really old, as noted here.
I've tried using this approach, but it didn't help me.
Right now, I'm getting a 429 runtime error
ActiveX Component can't create object
on line
Set objExcel = CreateObject("Excel.Application")
I only have Microsoft 365 trial version (no older ones) installed on the system and have these two things checked in my references:
I've also tried searching for Excel.Application in the registry, as suggested here, but I can't find the path to the corresponding ActiveX file (which probably means it is not registered if I understand this correctly).
What can I do? Any help would be greatly appreciated.
Never mind, I found the answer myself. The problem was that I had older Office versions installed when I installed new 365 package and for some odd reason the .dll files for 365 version weren't registered. When I deleted those older versions all the working .dll files were gone with them.
I did a repair of the 365 installation and it's working perfectly now.
I'm working on a spreadsheet that I created on a different machine with an install of office 2016 version 1701. I'm running 2016 professional version 1707.
Many of the new functions won't work, for example Concat.
I've tried updating my install but it appears to have the most recent updates.
Any ideas why I wouldn't have access to the most recently released functions?
Those new functions are only available in subscription versions of Excel (i.e. you need an Office 365 subscription), and are not the 2016 versions. So if you want something equivalent, you've got to use a UDF. Here's a link to a Concat UDF I wrote some time back. You can also no doubt find equivalent UDFs for the other new features that aren't in your non-subscription version via Google.
We have written a .NET add-in for MS Excel 2010. it is working fine, and we are using the MS deployment package to create an MSI which installs the add-in just fine.
Problem is that sometimes we need to install two versions of the add-in. Perhaps one is todays version, and one is the next version being tested.
What all would I need to update and where to allow the installation of the add-in mroe than once, on the same machine?
To begin with, tried changing the GUIDAttribute, of both the versions of the Add-in project:
<GuidAttribute("75AC751D-AB16-4E37-8940-XXXXXXXXX"), ProgIdAttribute("MyAddin.connect")>
With that change, i think i would need to change the productcode,packagecode and upgradecode in the setup.
Is my understanding correct that if I need to install add-on of my two environments (UAT, Prod) on the same machine, then my productcode, packagecode and upgradecode need to be all unique.
In case later, the user get a new version of the prod add-in, then that add-in should have the same upgradecode, and packagecode, but different productcode only (specific
Can i keep the same ProgIDAttribute for both UAT and Prod in this scenario?
Correct, you should change all 5 of them (and this is enough).
The ProgIDAttribute and GuidAttribute are used to register the addin for the Excel (as name of a key in registery; therefore they both must be changed)
The PackageCode, UpgradeCode, and ProductCode will allow you to install two packages on the same computer. You cannot keep package code (because ALL packages at all should have different package codes). You can't keep product code, because if you do then the second package will reject to install saying you have another version of the same product installed.
So, in the addin project:
ProgID
Guid (i.e. ClassID)
In the installer project
ProductCode
PackageCode
UpgradeCode
If user gets a new build, to allow upgrade, you should change ProductVersion, ProductCode, and PackageCode, but keep UpgradeCode in the installer project (old installation is identified by the UpgradeCode).
I have a MSI installer that installs an Excel plugin. I'd like to know if Excel is installed and not install the plugin if its missing. MsiEnumProducts gives a list of installed products except Microsoft Office. WTF? Is there a better way to do this?
I'd like my MSI installer UI to display or not a checkbox to install Excel component if we have Excel.
Puzzled,
Gerry
Excel is a feature within one of many Office products. Just because Office is installed doesn't mean that Excel is installed. It also doesn't mean the version of Excel that you need is installed.
I would instead check certain registry key/values based on your exact needs.
It seems if you try to reference the Office COM objects (as you would do in other development environments), Visual Studio gets it wrong - and it just won't work.
So you must use the converted type library that Microsoft hand-converted and makes available for download, and download, and download.
Now it seems that in order for my application to run it needs the Office Interop code, which is contained in an assembly.
Now i don't want to force my customers to install the Office 2007 Primary Interop Assemblies, Office 2003 Primary Interop Assemblies or the Office XP Primary Interop Assemblies. i want an xcopy deployment.
If i manage to get a hold of Microsoft's copy of the interop assemblies, can i just copy them to by Bin/Debug and Bin/Release folders?
If i include the Office 2007 interop assemblies, will it work if the customer has Office 95 installed, or do i have to include all versions of the Office Interop dll's Microsoft has ever published?
This is a common question with a rather complicated answer. Mary Lee of MSFT is a great resource for information about this:
http://blogs.msdn.com/vsto/archive/tags/Deployment/default.aspx
Using ClickOnce to deploy is the closest you are going to get to an XCopy install of any application built on VSTO.
Also, check this post:
http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/1666d2b0-a4d0-41e8-ad86-5eab3542de1e/
Finally, Misha has a great blog:
http://blogs.msdn.com/mshneer/archive/2006/01/05/deployment-articles.aspx
The PIAs are specific to the version of Office you are targeting, so the 2003 PIAs are necessary for targeting 2003 and the 2007 PIAs are necessary for 2007. Automating Office 95 via managed code is something I have not done before, but I can imagine you are directly referencing the type libraries so a RCW is generated for you and has nothing to do with PIAs.
HTH
Colby Africa (MSFT)
From my own experience:
If you wanted to target Office 2003 and above, then you'd use the Office 2003 PIAs - and limit yourself to the Office 2003 API. The code would run on Office 2003 or later. You could still call Office 2007 functions using reflection, but that's not pleasant.
I imagine it's much the same story if your baseline version is Office 2000 - though I've not tried it, and I believe the earliest version for which Microsoft themselves provide PIAs is Office 2002 (XP).
You can create your own Interop assemblies for 2000, and I've no reason to believe that you can't do it for '95, though you're the first person I've ever seen ask for '95 support! It goes without saying that if you create your own Interop assemblies you'll need to deploy them with your application.
In any case, you want to use the highest Office version you can get away with as your baseline, so that you can support as many features as you can without resorting to reflection. You should develop your code on a machine which has only that version of Office installed.
In my case, I develop for Office 2003 and know that my users also have 2003. So, I ask them to ensure that they have the ".NET Programmability Support" feature enabled (which you can do via Office 2003 Setup via Add/Remove Programs if you choose the Change option). That option basically installs the PIAs to the GAC. For those users that can't do this, my setup program detects the lack of the PIAs and installs them prior to installing my application (as it does for the .NET framework).
XCOPY deployment? Yes, I'd like that too - but forget it. For one thing, if your add-in is going to work in 'high' security mode, then you're going to need a code-signed COM 'shim' to sit between your code and Office, and that needs to be registered. I believe VSTO provides its own shim, if you choose to go down that path (I didn't, since I needed to be able to 'drive' Office from scratch rather than relying on the user to start the application).
Deployment - and dealing with the installation & security issues - is one of the hardest parts of Office Add-in development with .NET, and it's a real kicker that it comes right at the end when you thought you were done.
My strong advice is to save yourself days and weeks of hassle, and look at Add-in Express. I've only recently come across this myself, and have been kicking myself ever since because it could have saved me so much time. It has several benefits that I think would be useful to you:
It allows you to create a single add-in targetting Office 2000 to Office 2007 (sorry, not '95), regardless of what version you happen to have on your development PC.
It creates an installer for you (which even works on Vista!), which in itself is worth the price.
It comes with its own COM shim, and is integrated to the extent that you don't need to worry about it.
It will allow you to have a single add-in that has a menu/toolbar interface in Office versions up to 2003, but a ribbon interface in 2007.
Note that I have no affiliation with Add-in Express (other than as a recent customer), but equally I've not yet converted my projects over to using it. The initial tests that I have done lead me to believe it's pretty good - and definitely the way to go for small to medium projects.
If i manage to get a hold of Microsoft's copy of the interop assemblies, can i just copy them to by Bin/Debug and Bin/Release folders?
It worked for me. When I compiled the program I had it reference the interop (PIA) dlls in the bin and then deployed it that way to the customer.
If i include the Office 2007 interop assemblies, will it work if the customer has Office 95 installed?
No, you mst have the interop dlls for the version of Word you are targeting. I suppose it might be possible to write your code so that it chcks the version of word running on that machine and at runtime chooses the correct interop, but you need to include them all.