Develop Reference

Getting error "Cannot create Active X component" from Windows service but not console Application

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.

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:
In the start menu type Component services and open it (right click - as admin!)
Go to Component services -> My Computer -> DCOM Config folder
You'll see something like this
Find your COM Application in the tree.
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):
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:
Go to Start > Run. Enter regedit
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}
Right click on it. Select Permissions
Click Advanced
Change the owner to Administrator or your user account
Click OK
Select Full Control for the Administrators group and owner you selected
Go to Start > Run. Search for services.
Find COM+ System Application. Right click on the service, then click Restart
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.

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.

Cannot access excel file

I'm developing a windows service, generating a report. This report has a template. This template is prepared in an excel file. This file is copied to the output folder.
While developing I launched the service like a console application and had no problems accessing this file.
Then I prepared a service installer. The service is installed under Local System account. So this excel template file is marked as content and copied to the installation directory together with the executable as well.
But when the service is launched excel appears to have no access to this file. The service is installed to c:\Program Files (x86)\Our Company\Service Name\. The target OS is Windows Server 2008. While testing I use Windows 7 and run into the same issue.
I use the following code to access excel.
using Excel = Microsoft.Office.Interop.Excel;
//...
Excel.Application xlApp = new Microsoft.Office.Interop.Excel.Application();
//the following line throws an exception
Excel.Workbook xlWorkBook = xlApp.Workbooks.Open(#"path");
I also tried to copy the excel template file to some temporary directory (where the service has the right to write - this is tested) and tryed to open it from there, but to no success (while this variant works good in a console application as well).
The error message sais:
Microsoft Office Excel cannot access the file /path/.
There are several possible reasons:
1. The file name or path does not exist.
2. The file is being used by another program.
3. The workbook you are trying to save has the same name as a currently open workbook.
How can I make the windows service access this excel template file? Or is there another alternative?

To safety run Office applications (Excel and others) under user service with Local system account you must know two important things:
1) In Windows Server 2008/2008 R2 you must manually create two folders:
C:\Windows\system32\config\systemprofile\desktop
C:\Windows\SysWow64\config\systemprofile\desktop (for x64 version only)
Without this folders you cannot correct run office Applications from Local SystemAccount
2) If you service is configured without desktop interaction then in the first time launched office application (Excel for example) freeze on user credentials dialog - you cannot see this window in this mode - to resolve this enable desctop interacting, switch to office window after you service run it and manually enter credeentials.
Other information there(use google translater to read).

There is a detailed MS knowledge base article titled Considerations for server-side Automation of Office. Some key excerpts:
User Identity: Office applications assume a user identity when the applications are run, even when Automation starts the
applications. The applications try to initialize toolbars, menus,
options, printers, and some add-ins based on settings in the user
registry hive for the user who launches the application. Many services
run under accounts that have no user profiles (such as the SYSTEM
account or the IWAM_[servername] accounts). Therefore, Office may not
initialize correctly on startup. In this situation, Office returns an
error on the CreateObject function or the CoCreateInstance function.
Even if the Office application can be started, other functions may not
work correctly if no user profile exists.
Interactivity with the desktop: Office applications assume that they are being run under an interactive desktop. In some
circumstances, applications may need to be made visible for certain
Automation functions to work correctly. If an unexpected error occurs,
or if an unspecified parameter is needed to complete a function,
Office is designed to prompt the user with a modal dialog box that
asks the user what the user wants to do. A modal dialog box on a
non-interactive desktop cannot be dismissed. Therefore, that thread
stops responding (hangs) indefinitely. Although certain coding
practices can help reduce the likelihood of this issue, these
practices cannot prevent the issue entirely. This fact alone makes
running Office Applications from a server-side environment risky and
unsupported.
Obviously, as has been pointed out in the comments, using the SYSTEM account is a mistake. You would need to run the service under an account that has a user profile.
But even when you fix that, the other bullet point will kill you. Office applications do indeed assume they are running under an interactive desktop. My advice is to abandon attempting to automate Office from a service. Use a library like Aspose instead. Or run the process on an interactive desktop.

I just faced the same problem.
I have made a .bat file where I called the .exe file.
finally, I called the .bat file from the task scheduler actions.
It just works fine.

CD Burning within an XBAP

I have an XBAP that needs to be able to burn cd's. When running from inside Visual Studio, everything works okay. However when running from a browser, the IMAPI dll reports that the environment is not supported as soon as it tries to access the drive.
I am assuming this is coming down to permissioning. I have a signed certificate which I have installed and the xbap is set to run as a full trust application (although I'm guessing that it can't be or I wouldn't be having this problem).
Currently this is all running on my local machine, however eventually I want this to be deployed to a web server (all users will already have the certificate installed on their clients).
Does anyone have any ideas as to what I've missed / done wrong?
Update:
I have tried creating a new, test certificate which I've installed in my certificate store and then signed the XBAP against it, but it makes no difference.
Really could do with some ideas if anyone has any?
Further Update:
I have created a console application which is able to burn cd's. Shelling out to this console application allows me to burn the cd from my xbap, but not from inside the xbap itself.
However, this is really not what I want. Ideally I want to have all this contained within the xbap. Failing that, is there a way to include the console application in the xbap's one click deployment?
Thanks

I believe this is not possible to do with XBAP. According to MS documentation on XBAPs,
Examples of permissions not available
in the Internet zone:
FileIOPermission - This permission controls the ability to read and write files on disk. Consequently, applications in the Internet zone cannot read files on the user's hard disk.
RegistryPermission - This permission controls the ability to read/write to the registry. Consequently, applications in the Internet zone cannot access or control state in the user's registry.
SecurityPermission.UnmanagedCode - This permission controls the ability to call native Win32 functions.
When you run your XBAP over the internet, you'll hit issue #3: trying to interop with unmanaged code.
I would recommend deploying your app as a stand-alone app with ClickOnce. That way, you can have full access to the system, but still get easy deployment and upgrades like you do with XBAP.
*edit*
One thing you could try -- and I can't guarantee it will work -- but you could have your users go into IE Internet Options, add your site to the trusted sites list. I'm betting then your CD burning code will work because it will be in the trusted zone, rather than the Internet Zone.

Try going to
HKLM\SOFTWARE\Microsoft.NETFramework\Windows Presentation Foundation\Hosting
in the registry
create a new DWORD named RunUnrestricted with value 1.

C# application is freezing on vista/7, not on xp/2003 server

I wrote a C# application that is running well on my xp development machine.
When my client is running it on different PC, it seems to freeze on both vista and 7 machines.
I would like to know if there is any issue on running dotnet applications on vista/7.
I compiled the application for both framework 2.0 and 3.5 but it didn't help.
The log file neither doesn't help.
Is there any way to know where is the application freezing (of course, the client doesn't have VS for attaching to the application) ?
Thank you in advance for any help.
Pierre.

Generally, .NET application should run the same on any Windows version with .NET framework installed. Most common problem that occur are related to the new User Account Control policy in Vista and 7, which prevents applications from accessing areas requiring elevated privileges (which would otherwise run fine under an Administrator account in XP).
For example, if your application is trying to write configuration settings to the Program Files folder (which is a really bad idea, btw), or is using some hardcoded disk or registry paths instead of environment variables provided in .NET classes, it may fail under Vista.
To quickly check if this is an UAC privilege problem, try to run the application as an administrator (have your client right click the .exe file and select Run as Administrator). If it works, then this suggests that you need to examine your code and update it to make sure you are only accessing allowed areas.
Check this link for more information: Making apps UAC aware.
As redsquare suggested, the best way to test your application in a variety of Windows systems is to run them in several virtual machines (MS Virtual PC or VMWare Player, both of them free for download).

You do not give much information in order for us to help a great deal.
I would start by trying to recreate the issue locally on a virtual machine (vista one available here) and then profiling the app with something like memprofiler.

Ask your client to capture a process dump using Windows Task Manager,
In Task Manager, find the process that hangs.
Right click and capture a memory dump.
Then you can do some analysis on the dump to see why it hangs.
If you are not familiar with dump analysis, find someone who can help or open a support case via http://support.microsoft.com

csharp applications are supposed to run on vista/win7. This is their home:)
Your problem is not the OS. its your application.
Most probably the application is looking for a file, a folder, something on the client side that is not there and its freezing. this is my experience.
Check for project independencies and make sure you have shipped to your clients everything your project needs.
and last, distribute to one client the debug version with debug messages enable and get the feedback from their system.

DCOM Failure of Office Automation

I developed a C# program that pulls data from a SQL Server database and then generates Word documents which include the data. I've set the program up to run as part of an SSIS job on a Windows Server 2003 box. The program runs as user SQLSVC which doesn't have administrative privileges. When I log in as SQLSVC and run the program it executes correctly. However, when the program is run automatically as an SSIS job it freezes at the following line of code
Microsoft.Office.Interop.Word.Application word =
new Microsoft.Office.Interop.Word.Application();
When I kill the process forcibly, the following error message is generated.
Error Message: System.Runtime.InteropServices.COMException (0x80080005):
Retrieving the COM class factory for component
with CLSID {000209FF-0000-0000-C000-000000000046}
failed due to the following error: 80080005.
at IepGlance.Program.CreateNewIepFiles(Dictionary`2
iepDictionary, EasyIepDataContext dbContext)
at IepGlance.Program.Main(String[] args)
As far as I can figure out the problem is with DCOM permissions. I've used dcomcnfg to add all possible DCOM permissions to user SQLSVC, but this hasn't helped. Are there any other possible solutions?

Run program "dcomcnfg -32". ( You cant find the word and excel components if it runs under 64bit)
Go to "Console Root/Component Services/Computer/My Computer/DCOM Config/" Look up Microsoft Word and Excel and choose properties.
Go to Security and select "Customize" under "Configuration Permissions. (If needed you might want to change the other permissions as well, but I didn't need to) Add "IIS_IUSRS" and give it "Full Control".
Now go to "Identity" and select "The interactive user".

Couple of things here.
First, this thread on SO may help.
Second, Microsoft warns that 'complications' may arise when you automate Office through an unattended process. Here's the punchline (bolded in the original):
Microsoft does not currently
recommend, and does not support,
Automation of Microsoft Office
applications from any unattended,
non-interactive client application or
component (including ASP, ASP.NET,
DCOM, and NT Services), because Office
may exhibit unstable behavior and/or
deadlock when Office is run in this
environment.
The linked article discusses workarounds.

It depends whether you are on a 64-bit machine and if you are 32-bit Office or 64-bit office, but in either scenario you need to go into the Admin Tools > Component Services and under DCOM config you need to find 'Microsoft Word 97 - 2003 Document', and then set the 'identity' to the user that is running your app pool. or simply disable the security on it.
If you are running a 64-bit server with 32-bit Office, you may have trouble finding this DCOM setting. You will need to run "MMC -32" from the command prompt to launch 32-bit MMC and then add 'Component Services' from the 'File > Add / Remove Snap-ins' menu.
Hope this helped

One point from my side,
I was scheduling the batch job in one of our server and it was throwing the same error whereas it was running in my local.
I tried all of the above steps but in my case actual scenario was different.
Whenever schedule the batchjob, do not select the option [Run whether user is logged on or not] because this requires the admin access and if you are not, you are in problem.