Re: issues with referencing C# Excel Interop assemblies for creating reports

[Sam]

**Update**: Figured out the issue. The Office Automation libraries make use of 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 it with the assembly? Or can I jsut copy over the dependent assemblies to my application local directory and it works fine



On Wednesday, November 14, 2012 9:33:44 PM UTC-5, Sam wrote:
> I added my reporting class (that uses C# interop Excel assemblies to create reports) 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 is the 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 some of 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.

[Peter Duniho]

On Wed, 14 Nov 2012 19:20:32 -0800 (PST), Sam wrote:

> **Update**: Figured out the issue. The Office Automation libraries make
> use of dynamic keyword that requires Microsoft.Csharp assembly. I added
> the reference to it and it compiled fine

Funny how error messages often tell you exactly how to fix the problem. :)

> 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 it with the assembly? Or can I jsut copy over the
> dependent assemblies to my application local directory and it works fine

Assuming the assemblies you want to use are licensed for redistribution
with your application, then yes...you should be able to just copy the
assemblies to the same directory in which your program is installed and it
will work fine.

In some cases, it might be desirable to install assemblies in the GAC, but
I think in general that's better for assemblies you own and control the
distribution of, rather than third-party assemblies you depend on (you
never know who else will be messing around with the contents of the GAC :)
).

Pete

[Sam]

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.

[Peter Duniho]

On Thu, 15 Nov 2012 10:34:46 -0800 (PST), Sam wrote:

> 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)). [...]

>
> 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 don't think you can do that. Even if COM supports loading unregistered
COM classes or factories (I don't think it does, but I don't recall for
sure), it's the automation DLLs that would need to take advantage of that
feature.

You can check with appropriate support forums for the automation DLLs
themselves (this isn't the place), where someone can tell you whether the
automation DLLs can work without the COM servers they depend on being
registered. But I'll bet the answer to that is "no".

Pete

[Jeff Johnson]

"Sam" <jain....@gmail.com> wrote in message
news:2988194a-07e3-4047...@googlegroups.com...

> 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.

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?

[Peter Duniho]

On Fri, 16 Nov 2012 16:31:58 -0500, Jeff Johnson wrote:

> *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?

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. :)

[bradbury9]

Excel in servers. It is the easiest way to get lots of 'excel.exe' proccess on the wild consuming memory. Thats really a problem in web applications

[Jeff Johnson]

"Peter Duniho" <NpOeS...@NnOwSlPiAnMk.com> wrote in message
news:mlv14zrrj0i8$.10c3tcr1jiuut.dlg@40tude.net...

>> *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?
>
> 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. :)

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).
-----

[vcmuru...@gmail.com]

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