found the .NET group this morning (more suitable), so re-posted it here.
Hi there all,
I've got one for the .NET pro's and old hand COM programmers among you.
I have written a Windows Service (written in VB.NET in VS2003) which periodically scans user nominated directory structures and creates/updates PDF files and associated webpages for Intranet users on a clients network to access drawings (and other docs) via a website.
The Service calls (vanilla) AutoCAD 2006 to open the drawings read-only, form up Index entries from the Attributed Title blocks and create PDF's for linking.
This Service works well when installed and run on the Development Machine - which is an XP SP2 Laptop.
The problem is when the Service is installed on our Server which runs Windows Small Business Server 2003 SP1 (AutoCAD is also installed on the server along with the other necessary components).
The call to create the AutoCAD.Application using:-
fails with a "Cannot create ActiveX component" error.
the Service is designed to run under a dedicated user account (it needs this to access network shares on other servers)
I have trawled the web literally for hours looking for clues, and have found many possible related issues all centered around permissions and DCOM.
The Service has been run under my user account (has full admin rights, and works fine on the Development Machine), the Local system account and the builtin admin account - all produce the exact same error.
I have tried repairing the AutoCAD install thinking that it might have been damaged and uninstalling and re-installing it and it still refuses to budge!
I have also manually added my user account to the various Security permissions in the Component Services/..../AutoCAD Application console, but this also has absolutely no effect.
Arrrrrrrgh! 6 months of after hours slog and I'm this close **fingers held very close together...** but no cigar!
Can any of you COM/.NET gurus shed any light on this issue?
As I've mentioned before, the whole thing runs sweetly on the dev machine, but I don't really want to donate it to my clients!
thanks for your reply. sorry about the lateness of mine, I wrote the original post just before I went away on holiday for the weekend, and things were busy the first day back.
Yes, The Interop COM DLL's are already referenced in my Windows Service as they are used in processing the AutoCAD drawings during the 'publishing' process. I researched your suggestion as it isn't an approach I've seen before. It appears that you suggested a method called 'early binding', which is generally recommended over 'late binding' (which my call to CreateObject is classified as). I hadn't experimented with this before.
So, I tried out your suggestion this evening on the server, and forced a publishing run with Visual Studio attached to the service so I could debug the live code.
Unfortunately the program failed again at the same point, which was the point at which AutoCAD is instantiated and attached to:-
AcadApp = New AcadInterop.AutoCADApplication
(AcadInterop is my variable name from the Imports statement)
the only difference between this failure and the previous one was that the exception message which is now - "Server execution failed"
I used a small free program called RegMon to watch the registry calls during execution of this code, and it clearly shows AutoCAD starting up. Indeed, Taskmanager also shows the acad.exe process fire up, but it fails after a delay of many seconds, and throws up the error above. I am guessing that this would indicate that my process is unable to attach successfully to the AutoCAD process
I also looked the error message up on Google, and it also appears related to my first error - they both point to the AutoCAD installation not properly registering the Interop DLL's, but I haven't had time to compare the registry entries of a healthy machine (one that the service runs OK on) and the server.
Ugly problem. If you have any more ideas, they would be appreciated.
Hmmm....It could be because the service is running in the system context. The system context may not have the appropriate permission to launch a COM component on your server. Also, I believe that Server 2003 locks the machine down as well.
As a test, I am attaching an Excel workbook that you will run on the server to test launching of AutoCAD, both Late Bound and Early Bound. If this doesn't work, you may have to reinstall AutoCAD. If this does work, then you need to look at the Security Settings on the server.
Now I am NOT saying to change your Security settings on the server. But you can turn Auditing (Object Access and Privilege Use) to verify that this is where the failure is happening.
As far as a resolution, you could change your service to a user service (so that it loads when a user logs on to the server) or figure out a way to have the system account launch this with the most strict security settings that will still allow this to work, keeping in mind that you may still be opening up a security hole anyway's. You could also open dcomcnfg (start->run->type "dcomcnfg"->click ok) and look under Component Services->Computers->My Computer->Dcom Config->right click on "AutoCAD Application->Properties, and check the setting there. Keep in mind that changes to either Security or DCOM may prevent your server from running correctly or securely.
I downloaded CougerAC's Excel spreadsheet, and took a look. Good idea for testing whether AutoCAd will even run when called using COM, but I had to create a small Windows app in Visual Studio that did the same thing to get it to work on the server as it doesn't have office installed on it.
Running the test app on the server showed some ineteresting results - The first attemp at starting AutoCAD from the test app using either late or early binding fails, but subsequent attempts succeed.
Running the Windows Service again causes a failure and then running the test app and stareting again also filas. But the weird thing is that a subsequent attempt to start AutoCAd from the test app actually suceeds.
There is something particularly problematic with AutoCAD starting up as a service on the server. The only difference between the Service and the Test app is that one is a Windows Service and the other is a Windows forms application. Both are actually running under the same user account (the Windows Service runs logged in under my account - not the Local system or Netork Service accounts).
I received an e-mail from a user today indicating that the problem may lie with the Communication Center not being well behaved when run under a service - so I wil install the CAD Manager Tools from the CD, and disable it to see if this is tha cause of the problem.
Problem confirmed - it was the Communication Center that was causing the hang.
Upon starting, AutoCAD actually loads, but as part of the starting process, AutoCAD fires up the Communication Center, which is a separate executable.
When running within the context of a Windows Forms program, this appears to be no problem, but when running within the context of a Windows Service the process never returns from the call to start the Communication Center.
The solution - disable the Communication Center using the 'CAD Manager Tool' (can be found on the AutoCAD Install CD under Network Deployment). Use this to disable the Communication Center. Once this is done, AutoCAD starts fine using both early binding and late binding.
Thanks to all who replied, and special thanks to Laurence for coming accross the article that mentioned this issue and letting me know.