Click here to Skip to main content
12,947,539 members (62,426 online)
Rate this:
Please Sign up or sign in to vote.
See more:
I am attempting to deploy my application on user machines. The application uses as a reference the Microsoft Excel 12.0 Object Library. (This is needed. The program uses Excel to output various reports.) When some of the users try to install it, an error is thrown saying that the Microsoft.Office.Interop.Excel v12.0 is not installed in the GAC.

Theses users do NOT have Excel 2007 (or later) installed on their machines, so I suspect this is where the problem lies. Is there a way the install v12.0 of the excel interop in the GAC even though they do not have Excel 2007 or later?

If the answer is no, can I just use and earlier version (like 11.0) in my application.
Posted 3-Jan-13 11:51am
Updated 3-Jan-13 11:52am
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

The prerequisites for using of your product are: re-distributed .NET Framework of required version or later, plus Microsoft Office of required version (could include just the Excel and its prerequisites).

Office Interop does not work without installation of the Office product itself, but if the user installs both .NET and Offices, corresponding Office Interop assemblies become available to .NET; they are placed in GAC.

Of course, it creates the licensing problem: you cannot redistribute your copy of Office. You either need to make some legitimate license agreement with Microsoft, or simply require that your clients have it, as one of the prerequisites to your product.

This is one of the reasons why I'm strongly against Office development. This is not a good investment, maybe only acceptable in narrow user base scope, such as corporate tools, but even that is questionable. As I described above, deployment of such products is still quite possible, but it also creates the vendor lock-in ([^]). Why having all that trouble? There are good alternatives to the Office. It can be as simple as HTML. And it can even be something within .NET. For example, you can leverage WPF FlowDocument. And, these days, a lot more good opportunities.

Espen Harlinn 3-Jan-13 18:45pm
Thank you, Espen.
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

Here is another idea: if you use the product other then Microsoft Office, it does not mean that you cannot use Office file formats.
Presently use formats are based on XML and are standardized under the ECMA-276 and ISO/IEC standards. Please see:[^],[^],[^],[^].

Anyway, open-source code working with legacy Microsoft Office files is also available.

One of such products is the open-source and multi-platform LibreOffice. Please see:[^],[^].

It has SDK which allows you to embed LibreOffice in your applications. What's important, the SDK for .NET is also available. Please see:[^].

Menon Santosh 4-Jan-13 0:38am
Nice information
Thank you, Menon.
KevinBrady57 4-Jan-13 11:02am
Thank you Sergey. I will persue your suggestions.
If so, please also accept this answer formally (green button) — thanks.
(It's perfectly OK to accept more than one.)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

    Print Answers RSS
Top Experts
Last 24hrsThis month
OriginalGriff 5,134
CHill60 3,275
Maciej Los 2,563
Jochen Arndt 1,935
ppolymorphe 1,795

Advertise | Privacy | Mobile
Web01 | 2.8.170518.1 | Last Updated 3 Jan 2013
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100