For 15 years I have been using the Office object model, within classic VB and then with .Net.
Its never an easy area to write for having to watch for memory leaks, and navigating the complex object model of Word, Excel and Outlook.
Another problem, is that of office versions.
Now that office has been around for so long there are so many different options, and using the interop assemblies you cannot use a more recent version than that on the client machine. You also have to compile the application in 32bit or 64bit to match the version of office on the client’s machines.
For some clients it mean compiling 32bit and 64bit versions of every release. Meant we could not always test it if we had a 32 bit office installed and were targeting 64 bit. If clients retained old versions of, office, we were forced to have multiple versions of office on our development machines to support it.
This open source library solved all the deployment problems. It took a few hours to move a complex project away from Office Interop to NetOffice. Most of the code was unchanged, mostly the import statements had to be changed, and a few lines were the object references had to adjusted to the right namespace. Otherwise it worked seamlessly, and I was able to take project compiled on a machine with only Office 2013 on it, and deploy it on a client machine with only Office 2010 and all the office automation worked flawlessly.
I would be interested to see if this helps keep the memory leaks under control too.
Here is the link:
My only question is, why did Microsoft not do this themselves?