|
Michael Kaden
Guest
|
Hello
In setting up an ADX AddIn we can choose the minimum supported Office Version from Office 2000 to Office 2016. If we have no idea which Office Version our potential users have, what would be the criteria for the selection, or in other words, what are the disadvantages if we generally use office 2000 or xp?
I did not find anything in the Developer's Guide
regards
Michael |
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
Michael,
Images supplied with https://www.add-in-express.com/creating-addins-blog/2010/03/16/interop-assemblies-late-binding/ demonstrate the fact that an interop is sort of a table that maps the names of the object model's member to the location in the binary code. They also demonstrate a possible problem that occurs if your add-in uses a map pointing to a location which doesn't exist: if your add-in uses a newer interop version to access an older object model, a crash will occur if your add-in calls a member missing in the object model of the host application that loads your add-in.
That is, if you use Office 2007 interops, it would be wise to set the minOfficeVersionSupported attribute (see adxloader.dll.manifest) to 12 thus preventing your add-in from being loaded by Office 2000, 2002 and 2003. If however you need to let your add-in be loaded by Office 2000 and above, you need to delete the minOfficeVersionSupported attribute (or set it to 9) and compile your project with Office 2000 interops; we call them version-neutral.
Finally, you should deploy the interops used in your project to let your add-in use these interops, not the interops installed on the user's machine: Office versions are *not* 100% backward compatible.
Andrei Smolin
Add-in Express Team Leader |
|
|
Michael Kaden
Guest
|
Thank you Andrei,
I have read the link in your above post. As we have many iterative processes, I am afraid, that late binding could slow us down. I would rather go for a newer Version.
I assume that in publishing a selected version (f.e. 2000 or 2010) the equivalent interops etc. are loaded automatically, So if a user with Office 2010 installed is loading our Version 2000 AddIn, it will use Interop.Excel.dll (2000) and not Microsoft.Office.Interop.Excel.dll (2010). The AddIn Project will always bind to its project interops and DLL's and ignore any other version installed on the users computer unless we use late binding. Did I understand that correctly?
Therefore, for a Version 2000 Project, as long as we use only methods defined in the Versions Interop, dll's etc. of 2000 we are ok. Did I also understand that correct?
Is this also true if we run the project on the VS platform, i.e. just with build & register and without publishing?
Will an Error be raised if we attempt to call a method which is not in the 2000 Version but in the Version which is present in our local office and/or VS Version?
Finally can we change a project from, for example, Version 2000 to Version 2010 later on, just by setting minOfficeVersionSupported to 12 without building the project from scratch? Would it, for example, change the Imports statements and populate the publisher accordingly automatically?
Sorry if the questions sound silly, but in the past I just developed based on my Office Version (2010) and ignored earlier Versions, however, I get the impression that there are still a lot of earlier Versions in use.
Thank you for your support
Michael |
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
Hello Michael,
Michael Kaden writes:
I assume that in publishing a selected version (f.e. 2000 or 2010) the equivalent interops etc. are loaded automatically,
To not depend on interops installed on the user's machine, deploy the interops used in your project: these interops will be used automatically.
Michael Kaden writes:
Therefore, for a Version 2000 Project, as long as we use only methods defined in the Versions Interop, dll's etc. of 2000 we are ok. Did I also understand that correct?
Usually, an interop of any version is okay if your add-in uses classes and members defined on a version 2000 interop.
Michael Kaden writes:
Is this also true if we run the project on the VS platform, i.e. just with build & register and without publishing?
I suppose I don't follow.
Michael Kaden writes:
Will an Error be raised if we attempt to call a method which is not in the 2000 Version but in the Version which is present in our local office and/or VS Version?
You won't be able to build an early-binding call to a member missing in the interop referenced. As to the run time, we strongly suggest deploying the interops referenced by your project.
Michael Kaden writes:
Finally can we change a project from, for example, Version 2000 to Version 2010 later on, just by setting minOfficeVersionSupported to 12 without building the project from scratch? Would it, for example, change the Imports statements and populate the publisher accordingly automatically?
No. You will need to replace interop references, set the minOfficeVersionSupported attribute (see adxloader.dll.manifest) to 12, rebuild your add-in project, and update your setup project to deploy 1) the new interops, 2) updated adxloader.dll.manifest, and 3) new assembly version.
Michael Kaden writes:
Sorry if the questions sound silly
Don't ever hesitate to ask your questions.
Andrei Smolin
Add-in Express Team Leader |
|
Forums
Topics
Search
Help
Login
Register