issues with referencing C# Excel Interop assemblies for creating reports

  • Thread starter Thread starter Sam
  • Start date Start date
S

Sam

I added my reporting class (that uses C# interop Excel assemblies to createreports) to a large application but the application is failing to compile due to the following errors. The application is targeting .NET Framework 4.The application also references some assemblies that target older versions.. The reporting class is only called directly from the application. What isthe issue here?

Note that I tested my reporting class separately and it works fine.

Error 1 Predefined type 'Microsoft.CSharp.RuntimeBinder.Binder' is not defined or imported
Error 11 One or more types required to compile a dynamic expression cannot be found. Are you missing references to Microsoft.CSharp.dll and System.Core.dll?

Also, I need to deploy this application to multiple servers and I fear someof them may not have the interop assemblies and COM Dlls. Is it possible to ship them along with the application. I noticed the Copy Local property is False and cannot be changed for these assemblies.
 
**Update**: Figured out the issue. The Office Automation libraries make useof dynamic keyword that requires Microsoft.Csharp assembly. I added the reference to it and it compiled fine

Now on to the next question. Is there a way to ship the Excel Automation assemblies with the application so that even if destination box don't have it, the application will be able to run there. Do the assemblies depend on other native dlls and mappings in registry that make it impossible to ship itwith the assembly? Or can I jsut copy over the dependent assemblies to my application local directory and it works fine
 
I am getting this error on server:

Getting this error on my servers -
{System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache)
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipVisibilityChecks, Boolean skipCheckThis, Boolean fillCache)
at System.Activator.CreateInstance(Type type, Boolean nonPublic)
at System.Activator.CreateInstance(Type type)
at Charts.ExcelUtil.BuildExcelReport(..)

So I guess Excel automation components for .NET need to be installed on servers. What is the best way to make this work? Ideally I want to make this work by shipping everything with my application and not requiring manipulating registering dlls on server.
 
I am getting this error on server:
Click to expand...
Getting this error on my servers -
{System.Runtime.InteropServices.COMException (0x80040154): Retrieving the
COM class factory for component with CLSID
{00024500-0000-0000-C000-000000000046}
failed due to the following error: 80040154 Class not registered
(Exception from
HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean
publicOnly, Boolean noCheck, Boolean& canBeCached,
RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean
skipCheckThis, Boolean fillCache)
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly,
Boolean skipVisibilityChecks, Boolean skipCheckThis, Boolean fillCache)
at System.Activator.CreateInstance(Type type, Boolean nonPublic)
at System.Activator.CreateInstance(Type type)
at Charts.ExcelUtil.BuildExcelReport(..)
Click to expand...
So I guess Excel automation components for .NET need to be installed on
servers.
What is the best way to make this work? Ideally I want to make this work
by shipping
everything with my application and not requiring manipulating registering
dlls on server.
Click to expand...

Okay, at this point I HAVE to ask this question: you DO have Excel installed
on the server, right?* Because all this automation stuff merely lets you
programmatically control the already-installed Microsoft Excel software.


*Actually there's a second question here: Are you aware that many, many
people think it's a HORRIBLE idea to install and automate Excel on a server?
 
El sábado, 17 de noviembre de 2012 00:55:04 UTC+1, Peter Duniho escribió:
Microsoft themselves recommend against it. It works most of the time, but

if you get into a situation where Excel or some other Office component

decides it needs a user session to interact with, things can fail.



But some people are just bound and determined to do stuff. :)
Click to expand...

Excel in servers. It is the easiest way to get lots of 'excel.exe' proccesson the wild consuming memory. Thats really a problem in web applications
 
Microsoft themselves recommend against it. It works most of the time, but
if you get into a situation where Excel or some other Office component
decides it needs a user session to interact with, things can fail.

But some people are just bound and determined to do stuff. :)
Click to expand...

Not only that, but from a discussion I was reading in another group (at
least I don't think it was this group), there are potential legal issues.
The KB article is http://support.microsoft.com/kb/257757 and the relevant
section is this:

-----
Besides the technical problems, you must also consider licensing issues.
Current licensing guidelines prevent Office applications from being used on
a server to service client requests, unless those clients themselves have
licensed copies of Office. Using server-side Automation to provide Office
functionality to unlicensed workstations is not covered by the End User
License Agreement (EULA).
-----
 
Not only that, but from a discussion I was reading in another group (at
least I don't think it was this group), there are potential legal issues.
The KB article is http://support.microsoft.com/kb/257757 and the relevant
section is this:

-----
Besides the technical problems, you must also consider licensing issues.
Current licensing guidelines prevent Office applications from being used on
a server to service client requests, unless those clients themselves have
licensed copies of Office. Using server-side Automation to provide Office
functionality to unlicensed workstations is not covered by the End User
License Agreement (EULA).
-----
Click to expand...

Interesting point.

But I would have read "provide Office functionality" as providing
document editing capability via the server not as providing output from
documents created on a licensed work station.

Restrictions on what output can be used for are legally
questionable. Especially for something like OOXML that has
been standardized.

Arne
 
hai guys...
how to Export from DataGridView to Open Office calc in vb.net or C#.net

Any one personal may Help me Frinds

By Murugan.vc
 
Back
Top