We have a three tier application entirely developed in .NET 4.0 (C#). As the enterprise application server we use COM+ 1.5 (I know it’s a little bit legacy…). There are a server part and a client part both developed in C# for .NET 4.0.
The server part exposes services inheriting the ServicedComponent class and returning objects which implement the “Serializable” attribute. The client calls the remote classes via the COM+ exported proxy of the component. We distribute the client app through ClickOnce and we have to install, with Admin privileges, the COM+ generated Proxy onto every client machine. This is the bad point.
So we are trying to evaluate other techniques which allow us to eliminate this proxy installation but it’s not so clear how to do this. We’d like to find a low impact way that allow us to use the same COM+ part and including in some way the Proxy into the client side code.
We have tried to use code like this in the client part but still requires the COM registration.
Type comObjectType = Type.GetTypeFromProgID("SumNameSpace.SumClass", "servercomplus", true);
SumInterface comObject = Activator.CreateInstance(comObjectType) as SumInterface;
We thought that using in the client part the interface instead the class would have to work, but we have the exception:
Runtime.InteropServices.COMException (0x800401F3): Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))
This error should happen if there aren’t the correct information about the Interface in the Windows Registry, but we don’t know…
Any idea?
thanks a lot
There’s no question you need the COM+ proxy installed on all the client machines, and you want to install it with the proxy installation package. The error you’re getting is the result of the missing ProgID entry under the HKEY_CLASSES_ROOT hive in the registry. This registry entry, among others, is provided by the installation package. This isn’t all the the proxy installer provides; I found a pretty good overview here.
It sounds like what you are really looking for is to create a custom application manifest for your ClickOnce deployment. This should allow you to bundle the proxy installer as a bootstrap prerequisite into your ClickOnce deployment. However the install will still require administrative permissions; I don’t see a way around that (see note below). Here is a link to a tool that works with ClickOnce manifests that was created by Stackoverflow user Greg Jackman. I don’t have any experience with this, but based on Greg’s post it looks like it may be helpful to you.
One final note: even if you do find a way to run the installation package as a non-elevated user, you don’t want to do that. Running non-elevated will change the way the package interacts with the registry. Short story, it will fail silently.