Fragen zu EnterpriseServices

[Daniel Voelkel]

Hallo,

nachdem ein Projekt nun verteilt werden soll, stoße ich auf verschiedene Schwierigkeiten bzgl. den EnterpriseServices. Zum einen läuft ein Clientprogramm nur, wenn die .dll vom Server mit vor Ort liegt. Ich vermute, dass das aufgrund der Verweise so ist. Bei verteilten Anwendungen macht sowas jedoch keinen Sinn. Wie kann ich erreichen, dass ich lediglich die Client-Exe verteilen muss.

Weiterhin scheint es mir aufgrund verscheidener Fehlermeldungen (ungültige Typumwandlung beim Instanziieren des Serverobjektes), als ob es für den Client wichtig ist, dass die Version des Servers, welcher als Verweis benutzt wurde, die selbe ist die beim Instanziieren vorgefunden wird.
Das würde imho auch wenig Sinn machen, wenn z.B. eine Serverfunktion erweitert würde, müßte man ja alle Clients ebenfalls updaten. Also vermute ich auch hier, dass ich noch einen Fehler mache.

Hier mein Quellcode in C#, mit welchem ich das Serverobjekt aufrufe:
<PRE>
Guid guid = new Guid( "...");
Type t = Type.GetTypeFromCLSID (guid, "ServerIP",false );
MyObject inv = (MyObject) Activator.CreateInstance(t);
</PRE>

Ich bin für jeden Hinweis dankbar,
Grüße, Daniel

[Daniel Voelkel]

Hallo ich

Die Sache mit den Versionen habe ich inzwischen selbst aufklären können. Da zur Identifizierung des Server seine GUID vollkommen ausreicht, habe ich durch Weglassen von <BR>
<I>[assembly: AssemblyVersion("1.0.*")]</I><BR>
erreichen können, dass die Versionsnummer des Server nicht mit jeder Kompilierung erhöht wird

[Daniel Voelkel]

Die Sache mit den Versionen habe ich inzwischen selbst aufklären können. Da zur Identifizierung des Server seine GUID vollkommen ausreicht, habe ich durch Weglassen von <BR>
[assembly: AssemblyVersion("1.0.*")] <BR>
erreichen können, dass die Versionsnummer des Server nicht mit jeder Kompilierung erhöht wird

[Andreas Kosch]

Hallo,

&gt;Zum einen läuft ein Clientprogramm nur, wenn die .dll vom Server mit vor Ort liegt.

Bei einem Win32-Client muss auf dem Rechner nur die binäre TLB registriert werden, damit dieser auf den .NET Enterprise Service zurückgreifen kann.

Bei einem .NET-Client werden die kompletten Metadaten der öffentlichen Schnittstellen des .NET Enterprise Service-Objekts benötigt, damit die CLR zur Laufzeit den TransparentProxy/RealProxy zusammenbauen kann, der für das Marshaling zum .NET Enterprise Services zuständig ist.

P.S. In der Entstehungsgeschicht des .NET Frameworks wurden die .NET Enterprise Services erst relativ spät hinzugefügt - so dass es im Framework nun gleich zwei Verbindungsweg auf externe COM-Objekte gibt. Im Fall eines .NET Enterprise Services muss der Client zur Laufzeit sowohl auf die VTABLE (Methoden-Tabelle) als auch auf die ITABLE (Interface-Tabelle) zugreifen können, um den Aufruf korrekt der dazugehörenden Interface-Methode zuordnen zu können. Aus diesem Grund werden die Metadaten auch auf der Client-Seite benötigt. Die Sache hat aber auch etwas Gutes - durch diese "Tricks" sind .NET Enterprise Services in Verbindung mit DCOM unerreicht schnell (weil an COM Interop vorbei).

Wenn auf dem Server (Windows 2000 Server) in der COM+ Anwendung ein <b>Anwendungsproxy</b> (MSI-Setup) generiert wird, baut Windows automatisch alle benötigten Teile zusammen. Durch eine Testinstallation auf einem frischen Client-Rechner kann man dann nachsehen, was alles benötigt wird :-

[Daniel Voelkel]

Hallo Herr Kosch,

vielen Dank für die Erläuterungen. <BR>
Das sich im Installationspaket einige .dlls mehr tummeln als erwartet, hatte ich schon bemerkt. Warum die alle dort erscheinen war mir nicht klar.<BR>
Den dadurch entstehenden Geschwindigkeitsvorteil kann ich nachvollziehen. Der befürchtete Mehraufwand bei der Installtion von Updates auf mehreren Clients scheint über das MSI-Installtionsverfahren relativiert zu werden. Fehlende dlls werden einfach aus dem (aktualisierten) Setup-Paket nachinstalliert.<BR>
Ich werde in dieser Richtung weiterprobieren.<BR>

Vielen Dank für die Antwort, <BR>
Daniel Voelke