COM Aufruf aus Webservice

[stonezz]

Hallo Zusammen

Ich habe ein COM Object (Interop.SOK.dll von SESAM), welches ich folgendermassen instanziere:

Type mandantType = Type.GetTypeFromProgID("FibuNT.Mandant");
Mandant mandant = (Mandant)Activator.CreateInstance(mandantType);
int result = mandant.Login((short)aType, aMandantPath, aPassword);

Ich Caste das über Reflection erzeugte Object mit dem Interface Mandant. Wenn ich nun diesen Code innerhalb einer WindowsForm aufrufe, so funktioniert dies.

Wenn ich nun diesen Code über einen Webservice aufrufe, so erhalte ich folgende Fehlermeldung (Webservice läuft bei mir lokal):

System.Web.Services.Protocols.SoapException: Die Anforderung konnte vom Server nicht verarbeitet werden. ---> System.InvalidCastException: Das COM-Objekt des Typs "Interop.FibuSDK.OMandantClass" kann nicht in den Schnittstellentyp "Interop.FibuSDK.Mandant" umgewandelt werden. Dieser Vorgang konnte nicht durchgeführt werden, da der QueryInterface-Aufruf an die COM-Komponente für die Schnittstelle mit der IID "{4E879FE0-A269-11CE-AB56-00608CDFDCF8}" aufgrund des folgenden Fehlers nicht durchgeführt werden konnte: Schnittstelle nicht unterstützt (Ausnahme von HRESULT: 0x80004002 (E_NOINTERFACE)).
bei System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
bei System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
bei System.RuntimeType.ForwardCallToInvokeMember(Strin g memberName, BindingFlags flags, Object target, Int32[] aWrapperTypes, MessageData& msgData)
bei Interop.FibuSDK.OMandantClass.Login(Int16 Typ, Object Pfad, Object Passwort)
bei ch.schwarzer.kmu.be.sesam.impl.DefaultSesamAccessL ayer..ctor(SESAM_DATEI aType, String aMandantPath, String aPassword) in C:\Projects\Schwarzer\Application\KmuDatabase\src\ DefaultSesamAccessLayer.cs:Zeile 42.
bei ch.schwarzer.kmu.be.sesam.impl.DefaultSesamAccessL ayer..ctor(String aMandantPath, String aPassword) in C:\Projects\Schwarzer\Application\KmuDatabase\src\ DefaultSesamAccessLayer.cs:Zeile 25.
bei ch.schwarzer.kmu.bl.service.kontakt.impl.DefaultMa nageKontakt..ctor() in C:\Projects\Schwarzer\Application\KmuBusinessLogic \src\DefaultManageKontakt
.cs:Zeile 36.
bei ch.schwarzer.kmu.bl.service.impl.DefaultServerServ iceLocator.InitializeBusinessLogicServices() in C:\Projects\Schwarzer\Application\KmuBusinessLogic \src\DefaultServerService
Locator.cs:Zeile 63.
bei ch.schwarzer.kmu.bl.service.impl.DefaultServerServ iceLocator..ctor() in C:\Projects\Schwarzer\Application\KmuBusinessLogic \src\DefaultServerService
Locator.cs:Zeile 30.
bei ch.schwarzer.kmu.service.kontakt.ServiceKontakt..c tor() in C:\Projects\Schwarzer\Application\KmuService\Servi ceKontakt.asmx.cs:Zeile 35.

--- Ende der internen Ausnahmestapelüberwachung --- (mscorlib)
------------------------------

Program Location:
Server stack trace:
bei System.ServiceModel.Channels.ServiceChannel.Handle Reply(ProxyOperationRuntime operation, ProxyRpc& rpc)
bei System.ServiceModel.Channels.ServiceChannel.EndCal l(String action, Object[] outs, IAsyncResult result)
bei System.ServiceModel.Channels.ServiceChannelProxy.I nvokeEndService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
bei System.ServiceModel.Channels.ServiceChannelProxy.I nvoke(IMessage message)
Exception rethrown at [0]:
bei System.Runtime.Remoting.Proxies.RealProxy.HandleRe turnMessage(IMessage reqMsg, IMessage retMsg)
bei System.Runtime.Remoting.Proxies.RealProxy.PrivateI nvoke(MessageData& msgData, Int32 type)
bei ch.schwarzer.kmu.cl.ServiceKontakt.ServiceKontaktS oap.EndGetAllKontaktVo(IAsyncResult result)
bei ch.schwarzer.kmu.cl.ServiceKontakt.ServiceKontaktS oapClient.EndGetAllKontaktVo(IAsyncResult result) in C:\Projects\Schwarzer\Application\KmuClient\Servic e References\ServiceKontakt\Reference.cs:Zeile 1693.
bei ch.schwarzer.kmu.cl.service.contact.proxy.impl.Def aultManageKontaktProxy.EndDetermineAllKontakte(IAs yncResult anResult) in C:\Projects\Schwarzer\Application\KmuClient\src\co ntact\DefaultManageKontak
tProxy.cs:Zeile 87.

Ich habe gelesen, dass gewisse COM Objekte im STA Thread angesprochen werden müssen. Ich habe deshalb die Instanzierung und Aufruf in einen neuen Thread verlagert und dem Thread den ApartmentState STA zugewiesen. Hat leider nichts gebracht.

Weshalb funktioniert der Methodenaufruf auf das COM Object über einen Webservice nicht mehr?

Danke & Grüsse
Pascal

[Ralf Jansen]

Crossposting

Gewöhne dir das bitte ab (warum guckst du hier).

Zum eigentlichen Problem. Unter welchem Account läuft der Webservice? Ich würde das erst mal so konfigurieren das der unter dem gleichen Account läuft wie deine reine Winforms Anwendung. Wenn das geht würde ich mir dir Rechte des Accounts den du für den Webservice vorgesehen hattest ansehen und die Art der Registrierung der COM Komponente.

[stonezz]

sorry, für das Crossposting. wird nicht mehr vorkommen...bin eben der Verzweiflung nahe, da ich schon seit längerem an diesem Problem kämpfe.

Bez. des Account. Dies habe ich auch schon versucht. Webservice läuft unter dem gleichen Account, funktioniert aber auch nicht.

COM Registrierung: ist im global assembly cache registriert. Ich dachte, wenn ich mit der Windowsforms Anwendung das COM Objekt erfolgreich ansprechen kann, so ist das Objekt richtig registriert. Sehe ich dies falsch?

Ich habe noch unabhängig vom Webservice einen Unit Test geschrieben, welcher ohne Webservice meine Klasse X aufruft, welche dann das COM Objekt aufruft (der Webservice delegiert die Calls nur an die Klasse X). Mit diesem Test erhalte ich denselben Fehler, wie mit dem Call über den Webservice.

[Ralf Jansen]

Kann dies nicht mit dem Main STA zu tun haben?

Eigentlich eher unwahrscheinlich. MTA wäre eher das Problem. Wenn es daran liegen würde hättest du aber auch eine entsprechende Fehlermeldung bekommen sollen. Probleme bekommt man diesbezüglich eigentlich nur wenn man reine STA ActiveX Komponenten wie zum Beispiel das Webbrowser Control in einem Backgroundthread die üblicherweise im MTA Kontext laufen versucht zu benutzen.

Deinen fehlschlagenden Unittest hast du den explizit im Multithreaded Appartment ausgeführt? Dann hat dein COM Objekt möglicherweise wirklich die Einschränkung nur im singlethreaded Appartment zu laufen. Was sagt die Doku zu deiner Komponente?

Bez. COM Registrierung: ist im global assembly cache registriert

COM hat nichts mit dem GAC zu tun. Hat aber auch wohl nichts mit deinem Problem zu tun wenn deine Komponente im Standardfall (aus einem STA Thread) funktioniert.

[stonezz]

danke für die Antwort.
das Verhalten ist schon so, wie wenn das COM Objekt eine STA ActiveX Komponente ist (Unit Test läuft explizit im MTA).
Leider habe ich keine Doku vom Anbieter, habe diesen nun aber angeschrieben und warte auf Antwort; werde Feedback geben, sobald ich mehr weiss (werde dann auch die anderen Foreneinträge anpassen )
Grüsse
Pascal