Unit test with Microsoft.Office.Interop dll fails on build server

3
votes

I've written a unit test. The code under test references Microsoft.Office.Interop.Excel.dll.

The test runs fine on my machine but fails on the build server. It fails on the line where the Excel application is instantiated:

var application = new Application { Visible = Visible };

The error is:

System.Runtime.InteropServices.COMException: 
Retrieving the COM class factory for component with CLSID 
{00024500-0000-0000-C000-000000000046} failed due to the following error:
80040154 Class not registered

Does this mean I have to install the Redistributable Primary Interop Assemblies on my build server? And if so, do I also need to install Excel on the build server?

Edit: Microsoft.Office.Interop.Excel.dll is included in my solution and it is referenced from there.

3
c#excelcomms-office
If your test needs the assembly to be present, then clearly it needs to be on the machine where the test is running. Or are you asking something else? You may be able to get away with registering the single DLL on that machine, and not have to install Excel. Check that DLL's dependencies with the dependency walker. – Peter K.
I'm fairly sure you are going to have to install Office on your build server for this to work. – vcsjones
@Peter thanks, I have edited my answer to clarify. I already tried registering the dll but I got "DllRegisterServer entry point was not found. This file can nto be registered" just like this guy: serverfault.com/questions/59431/… – Matt Frear
You must install Office on that machine. Do not try to register anything, you didn't write a COM server, just a COM client. – Hans Passant

3 Answers

1
votes

You'll need to install Office and the Primary Interop Assemblies for that version, or Visual Studio to get this to work. You might run into COM issues with running in a CI environment, and if you can restructure your tests to avoid using Office Interop, I'd highly recommend it.

3
votes

If you add Microsoft.Office.Interop.Excel.dll to the solution in a library folder and reference the assembly there the build machine should get the required assembly when you promote. Otherwise, you're referencing an assembly that comes with the installation of Excel. Also, if you try to distribute your application without putting it in the solution anyone who tries to run your application that doesn't have Excel installed will get run time errors.

Or course, you're other option if you do not want to redistribute the assembly is to put a try/catch around the code that calls the Excel assembly and then display a message to the user saying an installation of Excel is required.

Finally, each version of Excel (2010, 2007, etc) has different version numbers. Meaning, if you're using the 2010 assembly and someone has 2007 Excel installed they will get run time errors. The answer I ended up using for that was reflection to pick which assembly is used in their environment.

3
votes

Yes, it looks like you need to install the PIA:

The primary interop assemblies for Microsoft Office products are also available in a redistributable Microsoft Windows Installer package:

The package for Microsoft Office 2003 is available for download from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=50479).

The package for the 2007 Microsoft Office system is available for download from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=72637).

And, for completeness, the Office 2010 package is here: (http://www.microsoft.com/download/en/details.aspx?id=3508)