In my experience, when a COM works from one type of app but not another, you are missing your Proxy. I can only assume that the way its being called from the service is out-of-process. This means that you can query for IUnknown and get it, but any interface you define will fail.
I've never used LabViews, but I'm sure there is a way to build your proxy from there. In C++ it was mycomponentnamePS.mk that you had to make from the command line or a post-build process. Make sure the resulting DLL is registered. -----Original Message----- From: Philippe Desaulniers [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 8:02 PM To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] Class not registered problem for NT Service Hello, This is rather convoluted. Any help would be greatly appreciated. I have an assembly that exports two calls to COM, ONE OF WHICH USES System.Windows.Forms TO DISPLAY A DIALOG (this may be important). I use the assembly in an application (written in LabVIEW, this may not be important, but it limits the global solution space for my problem :( ). The application only uses the second call, which DOES NOT invoke System.Windows.Forms. If I run the application normally, everything is fine. But I need to run my application as a service. Since the application is in LabVIEW, which does not quite support running as a service natively yet, I use SrvAny.exe to run my application as a service. In that case, I get a "class not registered" error when trying to start the service, at the point where the application opens a reference on my assembly. EXCEPT ON ONE MACHINE WHERE EVERYTHING WORKS PERFECTLY WELL. So, I figured that it was only a slight matter of configuration. I did comparisons of two machines, one where it doesn't work, and the one where it does. - "Default User" .NET security configuration seem identical on both machines. - Machine and Enterprise .NET Framework security configuration seem identical on both machines. - Registry entries concerning my assembly are identical on both machines. - SrvAny configuration to run the app as a service is identical. - Tracing the file accesses using filemon clearly shows that both are able to find the assembly. Where they differ is that the one that is successful seems to access gdi32.dll quite a lot more (opening a cache for fonts among other things), right around where the other one bails. I do understand that the entire design is awkward, that is not the point. I'm kind of stuck with it, and sadly do not have enough time available to rework it. I am just hoping someone may have a clear idea of what the configuration problem is, since I can't help but believe I may only be one configuration parameter away from solving the issue for the time being... Thanks a lot, phil
