I have used Excel and Powerpoint Interop Dlls in my web application, they run fine on local machine. However when I deploy it on IIS the application breaks giving following error
Retrieving the COM class factory for component with CLSID {00020820-0000-0000-C000-000000000046} failed due to the follo
wing error: 80040154.
Make sure of following things when dealing with applications using MS Office Interop Dlls delpoyed on server
Your application pool needs to run under a user account who has full permission to Interop Dlls
It would also be essential to intsall MS Office on your server
Related
I'm developing a WCF app that needs to communicate with a custom Windows service through shared memory. My development environment is Windows 7 Professional with IIS7, IIS7 Express and Visual Studio 2010.
When I run the app outside of VS2010 under full IIS7, it works great. But when I run the app from VS2010 using either IIS7 Express or the Development Web Server (Cassini), the app is unable to communicate with the Windows service. Using Process Explorer I've found that the shared memory in the Windows service has been assigned the names:
Section \BaseNamedObjects\NSBUS.q
Section \BaseNamedObjects\NSBUS.b
Section \BaseNamedObjects\NSBUS.a
while the WCF app is trying to access shared memory via the names:
Section \Sessions\1\BaseNamedObjects\NSBUS.q
Section \Sessions\1\BaseNamedObjects\NSBUS.b
Section \Sessions\1\BaseNamedObjects\NSBUS.a
The code to create/access the shared memory blocks is the same for both app and service (it's encapsulated in a DLL used by both). One difference that might be a factor: the service is set to run on the Local System account while I'm running the WCF app as my logon ID (which is a member of the Administrators group). I'm also guessing that maybe VS2010 is somehow injecting itself into the runtime/debugging environment in some way that forces the app to reference session-specific shared memory rather than true system global memory.
Any suggestions on how I might be able to configure my environment so that the WCF app will use the same section names that are being used by the service? (BTW, the service creates the shared memory at boot time.)
Maybe the worst type of error message that one can see. Does not mean anything, may be related to everything...
I try to create a web service (WS) on IIS 7.5 (I have initially tried WCF services but same story)
The WS uses a COM DLL which is successfully registered and the COM security permissions are given.
When I run the WS using Visual Studio Development Server everything is fine, I get the results as requested. But when I try to deploy the WS to IIS, I end up with
System.Runtime.InteropServices.COMException: Catastrophic failure
My computer has Windows Server 2008 R2 Standard, x64.
I have to emphasize: I develop (using Visual Studio 2010 Ultimate), test (using Visual Studio Development Server) and deploy (using IIS 7.5) on the same computer.
I was thinking that the problem might be related to 32-64 bit incompatibilities, as my COM is supporting 32 bits. Therefore, I changed the application pool settings to enable 32 bit applications, changed the platform target to x86 in Visual Studio, redeployed the WS, none of these helped.
My question is:
How can a WS successfully run on VS Development Server but fail on IIS? What else shall I change in IIS settings?
It really helps to consult the producer of the COM DLL. They have given a clear installation procedure for the DLL, that I have somehow omitted.
Moral of the story: Although your web service or web site operates successfully under Visual Studio Development Server, this does not necessarily mean that you have configured all settings for the COM DLL correctly.
You can start checking the following issues:
Register the COM DLL
Check configuration settings using dcomcnfg
If your DLL does not appear in dcomcnfg lists, then probably you did not register it correctly. Some registry editor entries are probably missing.
Check your IIS application pool settings
You may need to impersonate in web.config
Check the event viewer. It might include some important clues
In my case, I was playing with all of these items, but never in the correct sequence. Finally the help from the producer has arrived which was showing the correct path.
I have an error with my mvc3 application.
In my application I have a reference to a vb6 DLL which is a dll of another program.
When I debug my application with VisualStudio server developpement all is ok but I tried to deploy it in IIS7.5
I changed in the properties of my application the server and I chose local IIS webServer. (I didn't change the properties of IIS since the installation).
And when I try to debug my application I have an error when instanciating my dll :
Retrieving the COM class factory for component with CLSID .... Class not registered
This dll was registered with regsvr32.
The same application was deploy on a server with windows server 2003 and IIS6 and it works correctly.
If anybody have an idea ?
Thanks
If the COM component is 32bit you will have to enable 32 bit applications in IIS:
We've created a windows service to detect the insertion of a particular usb device.
That service is then supposed to launch an application we have written.
We initially made a setup project for our application and a separate one for the windows service.
Now, we are trying to get the service and the application installed in the same setup project.
We tried putting the output of our service into the setup project but without any luck.
We have the a projectinstaller class in the service, so why can't we simply add the project output of the Windows service (including the installer class) to our application's setup project?
There is MSDN article explains it, Create the installers for your service. Microsoft support also have an article, How to create a setup project for a Windows Service application in Visual C#
My primary language is Delphi. In Delphi, when a program is created as Service Application,
installing the program as a Windows Service can be done by running my_service_app_name.exe /INSTALL. I guess, the execution mechanism should be roughly same with service applications created by other compilers.
Thus, adding a windows service to an existing application installer can be done by just running the service application as mentioned, but you should refer to the documentation in case you are not using Delphi.
I have an application that allows me to scan images on my development PC which works successfully. It uses the Microsoft Windows Image Acquisition COM ActiveX dll. I am running VS2008 on Windows 7 64 bit.
I am having problems trying to deploy the Interop dll using ClickOnce. This component is referenced through the VS project in the normal way (and copy local = true). When I install the application on a Windows XP machine, I get an error saying that the library is missing (i.e. it wasn't installed / registered correctly). Having looked in the System32 directory, the dll is not there, so it has to be deployed via my app.
After looking on the web and trying various solutions, I then tried Microsoft's 'Registration-Free COM' method here: http://msdn.microsoft.com/en-us/library/ms165432%28VS.80%29.aspx
However, changing the Isolated property to True then caused 2 compilation errors due to duplicate entries in the registry. Having sorted out these entries out manually, I then deployed my app again with the supposedly isolated COM component, but when I try to scan a document I now get this message:
'The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll'
I feel like I'm going round in circles with this one. Can someone please enlighten me on how to deploy the WIA interop via ClickOnce for all versions of Windows from XP onwards?
Your help will be greatly appreciated.
Thanks
Don't copy system DLLs from your Win7 machine to the XP machine, that can't work. It would have been easier if you named the file, I would guess at wiaaut.dll, the WIA Automation provider. It probably just isn't installed on the XP machine.
Ask the client to install this download on the machine. You don't need reg-free COM, these are system components.