3

I have a Windows service written in c# which keeps listening to one Event Hub in Azure. As soon as a message is received, the service processes the message and does some execution and calculation.

As part of the execution, it launches a application called AutoCal (company's own window's application), which is COM component similar to that of Excel.

Earlier I had a web api which does the same calculation/execution. Upon every request it opens AutoCal and does some processing. I have added the AutoCal DLL as reference in the project.

The code to open AutoCal is something similar:

(AutoCal.Application)Interaction.CreateObject("AutoCal.Application.NewInstance").

When I tested this locally, it has perfectly as expected. But once I hosted this on the server, it has thrown an error saying "Cannot create ActiveX component". To rectify this, I have given permission to open COM components to Application Pool of IIS. This has resolved my issue.

Now that I have a windows service which also open the AutoCal, from where do I give CO component permissions. I have searched for it, but everywhere the solution is for ASP.net only.

How can I rectify this issue for Windows service?

PS: When I have written same code in console application, it is working fine.

halfer
  • 19,824
  • 17
  • 99
  • 186
CrazyCoder
  • 2,194
  • 10
  • 44
  • 91
  • You need to get a decent runtime exception to properly diagnose the underlying problem. You can't get that from CreateObject(), it is a VB6 compatibility method that intentionally hides error info. [Look here](https://stackoverflow.com/questions/13719579/equivalent-code-of-createobject-in-c-sharp). – Hans Passant Jan 15 '20 at 09:25
  • ASP.NET is also (in general) running as a Windows Service, so the solutions you found may very well apply to your context. It's often a security problem. Also make sure your component is registered in the proper registry (32bit vs 64bit) – Simon Mourier Jan 19 '20 at 08:41
  • @SimonMourier , Thanks so much for the reply. How to make sure that the component is registered in the registry? – CrazyCoder Jan 19 '20 at 08:58
  • You have to check what's the bitness of your Windows Service first (32 vs 64). Then check the component is registered in that registry: https://stackoverflow.com/questions/869783/windows-64-bit-registry-v-s-32-bit-registry. Alternatively you can also use sysinternals "Process Monitor" tool, and trace registry calls (filter on your .exe only). – Simon Mourier Jan 19 '20 at 09:42
  • @SimonMourier , I do not have a dll file. I have a setup file for AutoCal application. After installtion, I can see a .ocx file. I have registered the ocx file using this command ---> First cd windows\SysWOW64 --> regsvr32 "Path of .ocx file" . I got success message after doing this. Even then I'm getting the same exception. – CrazyCoder Jan 19 '20 at 11:40
  • Try running you service with an admin account identity. It it works, then it's a security issue. – Simon Mourier Jan 19 '20 at 12:12
  • @SimonMourier , I'm running the service as admin account. Still I get the same error. – CrazyCoder Jan 19 '20 at 13:20

2 Answers2

3

Without having exact error logs (can you try looking for related errors in the EventViewer?) it's hard to tell what the problem is.

But I would try the following:

  1. In the start menu type Component services and open it (right click - as admin!)
  2. Go to Component services -> My Computer -> DCOM Config folder

You'll see something like this

DCOM Config

  1. Find your COM Application in the tree.
  2. Right click it, open properties, go to Security Tab

It will look like this (never mind the title of the tab in the picture, in your case it should be something like AutoCal):

COM object properties

If it's grayed out, like in my case, you can use the following procedure to change the settings on your system, and make this tab configurable:

  1. Go to Start > Run. Enter regedit
  2. Go to the key that is associated with the DCOM component you want to manage: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
  3. Right click on it. Select Permissions
  4. Click Advanced
  5. Change the owner to Administrator or your user account
  6. Click OK
  7. Select Full Control for the Administrators group and owner you selected
  8. Go to Start > Run. Search for services. Find COM+ System Application. Right click on the service, then click Restart

Registry tempering

Once you have the Security tab enabled, you can change the permissions for your COM object. For example - you can allow the user, under which your service runs, to access or activate this COM object.

I hope this helps you, but again, without any additional error info - it's a long shot.

Aryéh Radlé
  • 1,310
  • 14
  • 31
0

You will want to run it under NETWORK SERVICE, but that's not the problem.

What you're experiencing is all summarised under KB257757.

Considerations for server-side Automation of Office

Your best bet is rewrite it in .Net. If its basic and you're NOT using XML, it might be worth giving that format a go. Back in the day we had to make sure everyone (all our customers) were on MS Office 2003 (turned out IBM were the only ones on 2002 and there's a plugin for 2002 to read 2003).

I know this is not good and I'm sorry to be the bearer of bad news.

Microsoft's stance:

Most server-side Automation tasks involve document creation or editing. Office 2007 supports new Open XML file formats that let developers create, edit, read, and transform file content on the server side. These file formats use the System.IO.Package.IO namespace in the Microsoft .NET 3.x Framework to edit Office files without using the Office client applications themselves. This is the recommended and supported method for handling changes to Office files from a service.

Jeremy Thompson
  • 61,933
  • 36
  • 195
  • 321