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

Reply via email to