Assume all traces of Office 2003 will be removed from the computer.
UPDATE:
I understand that I will still be able to use .xls files. I'm asking about automating Excel through the COM interop from outside Excel. When I add a reference to Excel to a VB project, it gives me a different version of the dll for different versions of Excel. If a program was compiled with a reference to Office 2003's dll, will it need to be recompiled for Office 2007? Will the code need to be updated to use the new dll?
You should have no problem with your code breaking. In my past experiences, even though I referenced old versions of the Interop Assemblies, the newer version of Excel has been able to handle the calls.
Now the same can't be said for trying to use a newer version of the Interop Assemblies with an older version of Excel...
It would be very surprising if there were many breaking changes between the versions. As I understand it, Microsoft has a number of customers using Office, and they wouldn't like a large number of breaking changes.
In my opinion, the above is actually a valid way of analyzing many questions of this type: "Could x possibly happen" is aproximately equivalent to "what would happen to Microsoft if they did x". If the answer is "something really bad would happen", then chances are that Microsoft figured that out ahead of time.
Of course, this doesn't work 100%. "Could Microsoft ever remove Web Application Projects from Visual Studio 2005" is a counterexample.
Related
An Access database used by multiple people at my office occasionally flashes several error messages in quick succession and then loses some macro functionality. The first time it happened, I researched the topic and found a solution - there were missing references in Visual Basic that had to be fixed. Upon opening the reference list, 4 that were selected all read 'MISSING: Microsoft X 16.0 Object Library' where X is [Word, Powerpoint, Excel, Outlook]. I deselected these references, scrolled down and selected the 15.0 Object Library references. Things were back to normal, full macro functionality restored.
However, the references keep reverting back to 16.0 Object Library ones that are still missing. Sometimes it will be several weeks before I have to replace the missing references with the older version, sometimes it will happen the next day. It's not a difficult fix at all, but it keeps happening, and most of the other users would not know what to do.
I have to imagine the problem is persisting because the database is shared across multiple computers in the same office, though I believe all PCs have the same version of Microsoft Office installed. Any thoughts?
Despite what you believe, I suspect that someone has a newer version of Office, perhaps Access 2016 or an Office 365 subscription. I experience this problem at my office, but it is expected since I know that some computers have Access 2016 while I am using Office 2013.
Creating a separate front-end database is already a best practice for many reason. It would likely eliminate or reduce such problems with your shared database. The shared back-end database can be stripped of all code modules and macros that might be dependent on a particular version. The front-end can then be copied to each client. As long as the front-end database is distributed (i.e. copied) from a lesser version (i.e. references last set to Office 15.0 for example) to each client, any newer versions of Access will automatically update the references of only its local copy.
Yes this is a very annoying feature of Microsoft's Component Object Model. (Although it was extremely cutting edge when it was revealed to us in the mid 1990s.)
A practical solution is to switch the VBA to use late binding rather than early binding. In doing that you can drop the explicit reference altogether and the problem goes away.
A half way house is to use a late binding loader addin which, depending on the client configuration, loads an addin specific to their environment. That loaded addin can use early binding.
The second option might be more practical in that it would require fewer code changes.
I have created a working Powerpoint add-in (.ppam) that offers several time saving features, and added a custom UI ribbon tab to improve accessibility.
As I look to distribute this add-in to users, I'm looking to improve code security by compiling it into a COM add-in (.dll) via VS Express.
I have looked all over the web for documentation on this, and have found some promising source, such as:
http://www.cpearson.com/excel/creatingcomaddin.aspx
Unfortunately, nearly everything I find appear to be quite outdated and based on Office XP or 2003, when I'm looking at Office 2010. I'm probably doing something wrong here, but I'm having trouble replicating their instructions on my end, running into errors like being unable to add a reference library or the code they suggest is not recognized. I actually am even unsure how to open for example the sample VB project that the Pearson site provides from the link above to imitate. I think all this may be because of the different versions of Office and Visual Studio, but could certainly be wrong.
Could anyone point me in the right direction? My understanding is that it's actually quite simple to convert the code from VBA to VB (just involves adding "Powerpoint.Application." in front of things like "activewindow"). So I just need to figure out how to convert a very simple VBA add-in into a COM add-in in VS Exp 2012 for Office 2010, and then can leverage the process to convert the full add-in.
Apologies if I'm using any of the terms incorrectly.
Background:
I have come up with an idea that will make things easier for the company I work for. They even seem excited about the idea. The idea is to make an addin for Outlook to help with a task. So after doing a bit of research (obviously, not enough). I downloaded a trial copy of VS2010 pro and created a VSTO addin.
After creating the addin, it was time to package it for a small test deployment. That's when I found out that this is a much more difficult thing to do. It seems MS does not ship Office 2010 with the runtime needed to run VSTO, so i'd have to package that as well. In a company environment, this is not something simple to do.
So, I might have to go back to the drawing board.
Meat of the question:
I've never created an addin for office before, I really want more of a "drop in" solution. I'm not sure if VBA is the right solution. It seems more of a "document" level application (or macro?). Does any one know what would be the best type of solution for this?
Outlook API is not native .NET framework. To interact it with, .NET relies on marshaling and interrop assembly thus making it much more prone to errors and unstable.
From what I've seen so far with my outlook API experience, I would stick with VBA and you should consider retrieving a third party library that exposes outlook extended MAPI if you run in to much of trouble.
NetOffice is pretty good - it is a set of managed .NET libraries that handles the COM API with Office and only needs XCopy installation.
The best part is it tracks all runtime callable wrappers ('RCWs') you create when accessing objects through COM and automatically releases them when you dispose the top-level object (the Application in most cases), so you won't get the issue of an orphaned COM 'handle' preventing you from closing Office.
Alternatively, the Office Primary Interop Assemblies should be on any computer that has the relevant version of Office installed (at least for >= Office 2007). But there are cases when it won't so you will have to cover that possibility. VSTO redistributable should already be installed on any computer with Office 2010 or 2013. For Office 2007 you will need to install it. But again, better safe than sorry so you should include it in your installer in both cases.
For details on deployment options look at http://msdn.microsoft.com/en-us/library/bb386179.aspx
As for VBA, I don't have experience for Outlook addins so I leave that to others to explain. Other VBA Office app addins (Excel/Word/Visio/PPT at least - not sure about the others as I haven't used them) can be installed either using registry keys or through XCopying the addin to a trusted location and then telling the user to open Options/Manage addins and tick the tick box.
I highly recommend Add-in Express. They have tools that go beyond what Microsoft provides via Visual Studio.
Their features for Outlook development greatly reduce the amount of effort required to build Outlook add-ins
I recorded a macro in Excel 2007 which used TintAndShade and PatternTintAndShade. Unknown to me, these two functions are not supported in earlier Excel versions but thanks to StackOverflow, I got a workaround.
Or so I thought. There are (apparently) other functions not supported by 2003. I say "apparently" because I do not have access to Excel 2003 but a colleague has told me that the macro does not work. I started asking him to tell me where the macro fails and then solving that (and iterating) but this is a slow process.
Is there an easier way? Is there e.g. a list of new commands in Excel 2007 or a simple compatibility check?
As a coincidence, I came across this which might help: http://blogs.msdn.com/b/eric_carter/archive/2009/03/19/object-model-changes-for-developers-between-excel-2003-and-excel-2007.aspx
There is also a page on MSDN for Excel 2010 which although not directly relevant may also help: http://msdn.microsoft.com/en-us/library/ee836187.aspx
No, not really and I doubt that there is a fully compiled list of object changes.
The best solution would be to develop in 2003, there are very few objects in 2003 that aren't in later versions - filesearch is the only one I can think of off the top of my head. However there are loads of things in '07 that aren't available in earlier versions, particularly notable are the new functions included in '07.
Do you really have no way of developing in '03 can't you install it? There isn't really a foolproof way of ensuring that your workbook will work correctly in earlier versions of Excel unless it was developed in an earlier version (or it's really simple)
An application currently in development has the requirements for using MS Word to perform spell check on certain textareas within the application.
I currently have Office 2007 (which is the Office 12 com objects).
My question is, if I add in the Office 12 objects what will happen on boxes which have Office 2003? This is in regards to both other development boxes as well as the end users.
Am I correct in believing that the end result will be that the spell capabilities will not be available for those users? And if I used an Office 11 object would that mean that the users would be unable to perform the spellchecks if they have Office 07 installed?
We gave up on trying to use a dependency on Word, as both have differing versions installed or no Office installation at all! Instead opting for NetSpell.
I am guessing here, but if it is as you can't use the 2007 PIA (Primary Interop Assembly) with a 2003 installation, you could try accessing the PIA via reflection as I would guess the calls you want won't change between the two, and then it won't matter - you'll use whichever is installed. If you are installing the PIA as well, you can then either get the user to tell you which they have, or be a little more clever and just try 2007 and if it fails, try 2003.
Like I said, I'm guessing here but it might be worth a try.
EDIT: I found this link about Office PIA's. This refers to Excel but actually covers Office in general. I don't envy the task you have. Looks like you'll need to detect the PIA (which may or may not be installed) and act accordingly. Sounds like a job for reflection to me.
Newer versions of Office will maintain most if not all compatibility with older versions of COM objects. Meaning if you want to program against Office 2003 and 2007 you will need to use Office 11 COM objects as a dependency as they were the newest available when 2003 was released. As long as you verify that the methods you need exist both versions of COM objects you should have no problems as long as you use the older COM objects.
Unfortunately, although I have used this solution for my own work, I have not tested it with Spell Check. In the end make sure that you test your code with all version of Office that you wish to integrate with.
My gut reaction to this question, is to simply suggest you go another route. Try using a 3rd party spell-check control. They are relatively inexpensive (and you may find some free controls). At least that way you can control the version of the control included with your app and be able to rely on it's functionality. Quite frankly, I'm surprised this library isn't built into Windows already. Sure it's complicated with all of the languages Windows supports, but these days it's similar to copy/paste in terms of user expectations.
You can actually package both the office11 and office12 interops needed to work in BOTH versions. It takes some minor work but I managed to do it. I do a check in the registry to see which interop to call and then executes the spell checking with the correct version. It even goes so far as to check if you have Word installed and throws an error alert that you can't spell check without having Word. We're tied to using Word due to the medical dictionary that's tied into Office we're required to use.
Do a search on interop or Com wrappers and I think you'll find you can use both fairly easily.