Hi Grumbler85,
zuerst dank ich dir für deine schnelle Antwort.

Wenn du mehrere Verschiedene Webseiten (sei mal dahergestellt ob das nun ASP.NET oder Silverlight oder von mir aus auch PHP ist) gleichzeitig benutzen willst gibt es verschiedene Varianten, denn wir wissen nicht ob deine ASP.NET mit dem Silverlight dings kommuniziert oder ob das separate Projekte sind und so weiter und so fort.

Falls ich dich hierbei richtig verstehe, dann kann ich dazu sagen, dass dies separate Projekte sind, die aber alle aus einer Hand (unserer Firma) stammen sollen.

Persönlich kenne ich mich mit WIF überhaupt nicht aus. Auch ein Grund warum ich dessen Verwendung scheue. Außerdem entnehme ich deinen Aussagen, dass WIF mit Hilfe des Active Directory "Single Sign On" ermöglicht, oder? AD und Windows Authentifitierung scheiden für unsere Anforderungen leider völlig aus.
Auch Shibboleth2 als Open Source Middleware Lösung, werd ich wohl kaum bei uns im Haus durchsetzen können.

Wenn wir allerdings den Zusatz "unter Verwendung von WCF RIA Services" weglassen; sieht dann jemand eventuell eine Möglichkeit SSO zu realisieren?
Selbst mit How to: Use the ASP.NET Authentication Service to Log In Through Silverlight Applications wird es mir nicht richtig klar. Ganz unten wird auch wieder darauf verwiesen, RIA Services zu verwenden...

Mir würde es auch genügen, wenn meine ASP.NET und Silverlight Anwendung sich über denselben (Standard WCF) Service authentifizieren und meine restlichen WCF RIA Services noch die Möglichekeit hätten, zu prüfen ob der Benutzer authentifiziert ist (bspw. dann irgendwie mit HttpContext.Current.User.IsAuthenticated).

Hat jemand unter diesen Vorraussetzungen vielleicht eine hilfreiche Idee?

Hallo zusammen,
ich suche nun schon seit längerem verzweifelt eine Möglichkeit "Single Sign On" zwischen ASP.NET und Silverlight (4!!) Anwendungen mit WCF RIA Services zu realisieren. Anders ausgedrückt soll es möglich sein, sich in eine ASP.NET Anwendung einzuloggen und dann in einer separaten Silverlight Anwendung immer noch eingeloggt zu sein; wie gesagt unter Verwendung der WCF RIA Services.

Natürlich habe ich zu diesem Thema intensiv gegoogelt und mich durch sämtliche Beiträge "durchgequält". Oft wird auf die Standard-Dokumentation der MSDN oder von Silverlight/RIA Services oder gar einfach nur auf "Authentifizierung mit ASP.NET" Seiten verwiesen. Diese geben eine Lösung nicht her oder ich konnte darin keinen entsprechenden Lösungsweg erkennen.

Hier ein kleiner Auszug meiner Google-Recherchen:

Single Sign on, Claims-Driven Experience and Service Authorization for In-Browser Silverlight applications (aufwendige Lösung die das WIF [Windows Identity Framework] benötigt)

How to: Use the ASP.NET Authentication Service to Log In Through Silverlight Applications (keine Verwendung von WCF RIA Services)

Silverlight Custom Authentication Domain Service with RIA Services (ASP.NET Authentifizierung in Silverlight ganz allgemein, keine zusätzliche ASP Anwendung verwendet)

Microsoft Silverlight Forum (Microsoft Moderator äußert sich skeptisch, keine konkrete Lösungsvorschläge)
....

Sollte jemand einen mir noch verborgenen Link kennen, der das Thema TATSÄCHLICH nachvollziehbar behandelt, wäre ich natürlich genau so dankbar.

Besten Dank im Voraus!

Hey Rainbird.

Du darfst keinen TcpServerChannel verwenden sondern musst einen TcpChannel verwenden. Sonst kann der Server nicht selber wieder Client sein.

Believe it or not. Mir ist es tatsächlich heute auch selbst aufgefallen als ich mir überlegte, dass der Server ja selbst eine Remote-Verbindung zum Sicherheitsdienst aufbaut. Manchmal dauert es halt bissl länger 😁

P.S.: Super Buch! Allerdings teile ich z.B. die Auffassung nicht, daß Remoting bevorzugt im IIS gehostet werden sollte.

Ja, die Anschaffung lohnt sich. Der Teil der die Erweiterung von .NET Remoting, in Zusammenhang mit eigenen Kanalsenken behandelt, empfand ich als sehr hilfreich, da hierfür ja schon deutlich mehr Hintergrundwissen und eigene Implementierung benötigt wird.
Ich hoste meine Services üblicherweise auch nicht im IIS. Persönlich hat mich dabei aber lediglich immer der zusätzliche Deployment-Aufwand abgeschreckt.

Welche Gründe sprechen aus deiner Sicht gegen das Hosting im IIS?

Hey Rainbird.

Wow, jede Menge brauchbarer Info und das auch noch um die Uhrzeit. Ein einfaches DANKE, reicht da schon fast nicht mehr aus: DICKES DANKE =)

Die Sache mit dem CallContext hatte ich schon soweit verstanden, wenn auch nicht in diesem Detailgrad. Advanced .NET Remoting (Ingo Rammer) verwendet den CallContext ebenfalls, um bspw. Logging-Einstellungen zu übertragen.

Ursache Deines Problems im Speziellen: Du hast versucht eine Rollenprüfung durchzuführen, ohne den Benutzer vorher mit Logon anzumelden.

Nein, es muss wohl an etwas anderem liegen. Mein Client ruft Logon auf:

				cApplicationServerManager.LogonFail += new EventHandler<SessionEventArgs>(cApplicationServerManager_LogonFail);

				// Log on to the Remote Application Server
				cApplicationServerManager.Logon("tcp://localhost:9999/MyAppServer/");

				// If we have a valid SessionId to the Remote Business Server
				if (cApplicationServerManager.HasSession)
				{
					// Connect to the Business Service
					IBusinessService businessService = ServiceFactory<IBusinessService>.CreateProxy();

                     IArticle[] articles = businessService.GetArticles();
                     // ...
				}

Der Aufruf landet auch wunderbar im Service. Hier rufe ich dann ApplicationServer.IsInRole() auf. Darin wird die Property "ServerUrl" aufgerufen, die auch noch erfolgreich den URL aus dem CallContext extrahiert. Dann wird (alles auf Serverseite) eine Remote-Verbindung zum SecurityService aufgebaut und SecurityService.IsInRole() aufgerufen. Dieser Aufruf bleibt ohne Exception einfach stehen.
Verwende ich allerdings die Config-Datei zur Konfiguration des Server-Channels, funktioniert es einwandfrei.

Ich finde aber den entscheidenden Unterschied nicht:

Programmatische Konfiguraion meines Server-Channels:

			RemotingConfiguration.ApplicationName = "MyAppServer";
			RemotingConfiguration.CustomErrorsMode = CustomErrorsModes.Off;

			// Eigenen BinaryServerFormatterSinkProvider erstellen
			BinaryServerFormatterSinkProvider provider = new BinaryServerFormatterSinkProvider();
			provider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;			

			// Channel mit vordefinierten Properties erstellen 
			TcpServerChannel tcpChannel = new TcpServerChannel("AppServerChannel", 9999, provider);
			tcpChannel.IsSecured = true;

			// Channel registrieren
			ChannelServices.RegisterChannel(tcpChannel, true);

Wenn ich die Config-Datei verwende geht aber alles. Was fehlt bei der programmatischen Konfiguration? Mir fällt nichts auf.
Gruß

Hi Rainbird!

Danke für deine stets hilf- und lehrreichen Antworten!

Marshal veröffentlicht die bestehende Singleton-Instanz unter dem angegebenen URI. Wenn Du keinen URI bei Marshal angibst, erzeugt Remoting einen zufälligen (den Du dann aber nicht weisst). Also entweder RegisterWellknownServiceType ODER Marshal, aber nicht beides zusammen!

Diesen Unterschied kannte ich nicht.
Damit ist meine Frage (3) auch gelöst. Das Problem war somit, dass ich den Typ (per RegisterWellKnownServiceType) UND die Instanz (per Marshal) veröffentlicht hatte. Somit erhielt der Client eine neue Instanz des veröffentlichten Typs. Meine gemarshallte Instanz wurde nicht an den Client geliefert.
Das "Problem" zu meiner Frage (1) konnte ich nun auch lösen:
In der Config-Datei kann man ja den Namen der Applikation angeben. Diesen muss man ja im URI der Application-Server Methode mitgeben, also

ApplicationServer.Logon("tcp://localhost:9999/<ApplicationName>/");

Wenn ich aber Remoting programmatisch konfiguriere, kann ich ja keinen Applikationsnamen angeben. Somit musste ich einfach den Namen aus dem URI entfernen. Sounds easy, but hard to find 😭

1.
Gibt es eine Möglichkeit den Applikationsnamen auch bei der programmatischen Konfiguration einzustellen?
[Edit 19:43 Uhr] Selbstohrfeig 😁

RemotingConfiguration.ApplicationName = "MyAppServer";         // Server
ApplicationServer.Logon("tcp://localhost:9999/"MyAppServer/"); // Client

Es funktioniert jetzt mit der programmatischen Konfiguration alles top, bis auf:
Wenn ich aber auf Server-Seite "ApplicationServer.IsInRole(role)" verwende, kehrt der Aufruf nicht zurück, es wird aber auch keine Exception geworfen.
Verwende ich wieder die Config-Datei, bleibt die Methode "IsInRole()" nicht stehen.

Ich habe es debuggt und festgestellt, dass hier:

        public static bool IsInRole(string roleName)
        { 
            // Wenn momentan eine Sitzung besteht ...
            if (HasSession)
            {
                // Verbindung zum Sicherheitsdienst des Anmeldungs-Applikationsservers herstellen
                ISecurityService securityServiceProxy = (ISecurityService)Activator.GetObject(typeof(ISecurityService), ServerURL + typeof(ISecurityService).FullName);
				
                // Berechtigungsprüfung durchführen
               return securityServiceProxy.IsInRole(roleName);
            }
            // Falsch zurückgeben
            return false;
        }

bei "securityServiceProxy.IsInRole" der Aufruf nicht zurückkehrt. Der Aufruf komm im Debug-Modus garnicht erst im Security Service an. Finde den Grund nur leider nicht. Ist das nicht seltsam, zumahl es von Client-Seite aus funktioniert? Es funktioniert ja seltsamerweise auch auf Server-Seite, sobald ich wieder die Config-Datei verwende.
Haste du vielleicht spontan ne Idee dazu?

Besten Dank im Voraus!

Hallo Rainbird.
Ich habe zur Zeit deinen ApplicationServer testweise im Einsatz.
Zunächst einmal: fett respect dafür! Echt saubere Arbeit.

Ich hätte folgende Fragen, die ich auch nach längeren Überöungen und Experimentieren nicht selbst lösen konnte:

1.
Mich würde interessieren, wie man es schafft den SecurityService programmatisch zu veröffentlichen/bereitszustellen?

Der folgende Versuch (und Varianten davon) sind gescheitert:

			// Channel-Konfiguration
			System.Collections.IDictionary properties = new System.Collections.Hashtable();
			properties["name"] = "AppServerChannel";
			properties["port"] = 9999;
			properties["secure"] = true;

			// Eigenen BinaryServerFormatterSinkProvider erstellen
			BinaryServerFormatterSinkProvider provider = new BinaryServerFormatterSinkProvider();
			provider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;	

			// Channel mit vordefinierten Properties erstellen 
			TcpServerChannel tcpChannel = new TcpServerChannel(properties, provider);

			// Channel registrieren
			ChannelServices.RegisterChannel(tcpChannel, true);

			// Sicherheitsdienst veröffentlichen	
			 RemotingConfiguration.RegisterWellKnownServiceType(typeof(SecurityService),
				 "Rainbird.AppServer.API.ISecurityService", WellKnownObjectMode.Singleton);

			 RemotingServices.Marshal(SecurityService.Instance);

Der Client erhält beim Logon den Fehler mit der Meldung "Der angeforderte Dienst wurde nicht gefunden".
Verwende ich wieder die Konfigurationsdatei funktioniert alles einwandfrei.

2.
Wie registrierst du den SecurityService denn überhaupt?
In der Config-Datei konnte ich keine Einträge diesbezüglich finden.

3.
Mir ist aufgefallen, dass trotz der Einstellung "Singleton" für meinen Geschäfts-Dienst, beim ersten Methodenaufruf der Standard-Konstruktor des Service aufgerufen wird, obwohl ich ihn bereits im Server zuvor instanziert habe.
Wenn ich den Dienst ohne Default-Konstruktor implementiere, erhält der Client beim Methodenaufruf eine Exception mit der Meldung, dass kein parameterloser Konstruktor definiert wurde.
Hierfür finde ich keinerlei Erklärung. Die Instanz des Dienstes veröffentliche folgendermaßen:

		RemotingConfiguration.RegisterWellKnownServiceType(typeof(cBusinessService),
				"ServiceContracts.IBusinessService", WellKnownObjectMode.Singleton);

			cBusinessService service = new cBusinessService();
			RemotingServices.Marshal(service);

Für deine Hilfe wäre ich echt dankbar, sofern deine Zeit es zulässt.

Viele Grüße

Besten Dank JAck30lena!
Das hat mir alles sehr geholfen.

Grüße und schonmal vorab ein schönes WE!

serialisierung betrifft nur den zustand eines objektes... nicht jedoch seine implementierung. das bedeutet das methoden usw nicht übertragen werden können. deine sorge ist also unbegründet.

Stimmt ja! Eigentlich ist das ja auch der Grund warum die Implementierung beiden Seiten bekannt sein muss (Shared Assembly), oder?
Angenommen IPerson verfügt über die Methode IPerson.IsValid() und man überträgt schlicht etwas vom Typ IPerson an den Server. Zur Laufzeit muss ja dann entschieden werden, welche Impl. der Methode aufgerufen werden soll:
Entweder ClientPerson.IsValid() oder ServerPerson.IsValid(). Auch wenn, wie von dir mal erwähnt, es möglich ist den Zieltyp bei der Custom-Serialisierung anzugeben, muss der Client ja wissen welche Implementierungen es gibt (sonst kann er sie ja nicht angeben).

Jetzt brennt mir aber noch eine andere Frage auf der Seele.
Wenn Person eine Adresse hält, die bspw. über die Methode IPerson.AddAddress(IAddress) verfügt, dann muss das PersonInfo-Objekt (Datenhaltungsobjekt) ja auch die Adresse halten können, oder?
Ist das der richtige Ansatz?

halt....
diese klasse kann doch einfach nur ein property in der anderen klasse sein... sozusagen als datencontainer. dann hast du keine kopiererei

Das stimmt soweit schon. Allerdings wären dann hierfür an der bereits bestehenden Klasse "Person" (auf Server-Seite) Änderungen nötig. Sprich ich müßte sie um ein Setter erweitern, der intern alle Validierungen der Geschäftslogik abklappert und je nach Gültigkeit die bereits bestehenden privaten Felder (Name, Vorname und und und) setzt.
Alternativ könnten die internen Felder ersetzt werden durch Verweise auf das Datencontainer-Objekt, was jedoch auch Änderungen an der bestehenden Implementierung erfordert.

Den Kopiervorgang hätte ich bei genauerem Überlegen auch in Kauf nehmen müssen, wenn es möglich gewesen wäre, dass der Client eine eigene, auf dem Server nicht vorhandene Implementierung übertragen hätte können. Da ich der Geschäftslogik von ClientPerson (Impl. des Clients) nicht hätte blind vertrauen können.

Es scheint so als müsste ich irgend einen Tod sterben =), aber ich lasse mich gern auch eines Besseren belehren.

Also ich werde wohl die Variante verwenden, bei der ich reine Datenhaltungsobjekte in der Shared Assembly mit ausliefere, die dann zwischen Client und Server übertragen werden. Diese Variante hat zwar den Nachteil dass sie einen zusätzlichen Kopiervorgang (Datenhaltungsobjekt -> tatsächliches Business Objekt) beim Empfang der Daten beansprucht, aber den werde ich wohl in Kauf nehmen können.

Vielen Dank nochmals an dieser Stelle an JAck30lena und unconnected.
Ich betrachte den Thread hiermit als "gelöst".

Grüße

Grüß dich JAck30lena!

nur weil du ein interface benutzt, heißt das cniht, das du keinen konkreten typen in der hand hälst.

🤔 Hab ich etwas anderes behauptet? Ich meinte nur, dass eine Umkonvertierung von DataSet und Co in konkrete Typen keinen Sinn macht. =)

als lösung für dich wäre dann eher ein reines datenhaltungsobjekt, das die zu übermittelnden daten enthält und auf client seite, einen wrapper um dieses objekt

Ja, sowas könnte ich mir auch vorstellen.
Und dann vor dem zurück übertragen vom Client an den Server wieder entpacken (unwrappen), oder?

oder du serialisierst mit dem custom-serialising mechanismus... allerdings weiß ich jetzt gerade nciht inwiefern dieser stark typgebunden ist....

Das würde für das Serialisieren vermutlich funktionieren. Beim Deseralisieren auf Serverseite würde ich aber vermutlich ja wieder Probleme bekommen, da der Typ dort ja nicht bekannt ist (da nicht in der Shared Assembly enthalten).

Griasla und danke

Hallo unconnected.
Erstmal danke für deine frühe Antwort!

Beim .Net Remoting serialisierst du den konkreten Typ, und der kommt auch auf der anderen Seite als dieser Typ an. Wenn er dann versucht den Typ zu deserialisieren, fliegts dir um die Ohren.

Wie gesagt, technisch ist das für mich nachvollziehbar. Im Klartext heisst das dann also, dass der Entwickler auf Client-Seite keine eigene Implementation einer IPerson erstellen/nutzen kann, sondern nur die Implementationen die ich ihm in der Shared Assembly mitliefere?

2 Fragen..

1. ich sehe du nutzt VS 2005, also kommen webServices oder WCF nicht in für dich in frage?
2. Warum magst du keine implementation eines Flachen Datenobjects weitergeben?

Zu 1:
Nach weiterem Überlegen meine ich, beim Verwenden von SOAP oder WCF vermutlich auf dieselbe Problematik zu stoßen, oder? WCF kann ich nicht verwenden, da unser Firmenprodukt auf .NET 2.0 ausgerichtet ist. Wir wollen die Nachinstallation höherer Frameworks bei den Kunden vermeiden.

Zu 2:
Mit flachen Datenobjekten meinst du vermutlich DataSet und DataTable. Das Für und Wider zu diesem Thema wurde ja in diesem Forum schon ausgiebig diskutiert. Z.B.: hier oder hier. Persönlich bevorzuge ich eher die "harten" Datenobjekte. Außerdem verwendet unsere Architektur Vererbung, untersch. Interface-Implementierungen, und weitere Objektorientierte Ansätze in Bezug auf diese Datenobjekte. Eine zusätzliche spätere Umkonvertierung von DataSets und Co in konkrete Objekte macht auch aus Performance-Sicht keinen Sinn für uns.

Viele Grüße

Hey Community!
Ich habe eine Verständnisfrage zu .NET Remoting.
Ich habe einen Remote-Server der das Speichern von Personen über ein Manager-Objekt anbietet. Der Manager aktzeptiert in seiner Methode StorePerson(IPerson person) Typen vom Interface IPerson. Dieses Interface ist einer Shared Assembly (dll) definiert, welche vom Server und vom Client referenziert wird. Da ich keine Implementierung ausliefern möchte, überlasse ich die Implentierung von IPerson dem Client. Beim Aufruf der Remote-Methode StorePerson(..) erhalte ich eine SerializationException mit der Meldung, dass die Assembly ClientTest (Name des Client Testprojekts) nicht gefunden werden kann. Wenn ich die Implementierung von IPerson (Klasse NaturalPerson) in die Shared Assembly packe, funktioniert alles einwandfrei.

Aus technischer Sicht mag ich das noch verstehen, da der Server wissen muss wie er die übergebenen Typen deserialisieren soll.
Allerdings verstehe ich nicht, wie ich so einen Service realisieren kann der ohne die Auslieferung von Implementierung (bspw. Klasse NaturalPerson) auskommt.
Bin ich wirklich gezwungen alle Typen die übertragen werden sollen in die Shared Assembly zu packen?

Zum besseren Verständnis hier noch der (vereinfachte Code):

Das Service-Objekt:

public class PersonManager : MarshalByRefObject
{
	public void StorePerson(IPerson person)
	{
		// Storing...
	}
}

Das Interface IPerson in der Shared Assembly:

namespace BusinessTypes
{
    public interface IPerson
    {
        string FirstName { get; }
        string LastName { get; }
    }
}

Die Implementierung von IPerson auf Client-Seite:

[Serializable]
public class NaturalPerson : IPerson
{
    private string _firstName, _lastName;

    public NaturalPerson(string firstName, string lastName)
    {
        _firstName = firstName;
        _lastName = lastName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }

    public string LastName
    {
        get { return _lastName; }
    }
}

Der Methoden-Aufruf auf Client-Seite:

 
// Connect to the remote service
PersonManager manager = (PersonManager) RemoteTools.GetRemoteService(......);

// Store the person on the service side
manager.StorePerson(new NaturalPerson("John", "Smith")); // throws SerializationException

Hey Rainbird!
Danke für deinen Nachtrag zu meinen Fragen.

Allerdings ist das serialisierte XML von DataSets und DataTables nicht für Interoperabilität entworfen worden. In Verbindung mit anderen Plattformen (z.B. Java) kann sich das als holprige Stolperfalle erweisen.

Ja ich gebe zu, dass meine Frage hier schon fast etwas rhetorisch gemeint war, um die von mir bevorzugte Variante der sog. "harten" Geschäftsobjekte zu unterstützen. Trotz allem: danke!

Silverlight unterstützt keine DataSets/DataTables.

Das war mir nicht bekannt. Gut zu wissen, da wir ggf. den Einsatz von Silverlight für unser Firmenprodukt einplanen möchten. Somit war deine Antwort auf meine "rhetorische" Frage doch nicht völlig umsonst 😁

Es gibt aber Szenarien (Suche, Listen, Berichte), bei denen die Spalten nicht fest definiert sind, sondern z.B. vom Benutzer zur Laufzeit festgelegt werden können. Dann nützen konkrete Objekte nichts, da ja zur Entwurfszeit noch nichts konkretes feststeht.

Interessante Anmerkung. Allerdings würde ich das Design meiner Geschäftsobjekte nur ungern an den Bedürfnissen der Präsentationsschicht ausrichten, sofern du das überhaupt damit andeuten wolltest (was ich nicht glaube).

Aber ich schließe mich Herbivores Wunsch an und vertiefe diese Punkte nicht weiter an dieser Stelle, um einer weiter ausufernden Diskussion hier vorzubeugen.

Nichts desto trotz, danke und respect!

Danke Herbivore!
Werd mir das anschauen.

Gruß

Hallo zusammen!
Ich habe diesen Thread mit äußerstem Interesse durchgelesen, auch wenn er zeitlich bereits etwas zurückliegt.
Mir ist aufgefallen, dass die meisten hier Geschäftsobjekte in der Representation eines DataTable oder DataSet bevorzugen, die von einem Manager-Objekt bezüglich ihrer Geschäftslogik verwaltet werden.
Meine Auffassung weicht etwas von diesem Verfahren ab, insoweit dass ich konkrete Geschäftsobjekte gibt. Besipiel: Klasse "Lieferant" statt "LieferantenManager", oder "Artikel" statt "ArtikelManager".
Hier würde mich ganz allgemein mal eure Meinung dazu interessieren.

Bei meinem Ansatz, sehe ich dass Problem, dass ich die (hier vorgeschlagene) Lösung für den "DataAccess" nicht ohne weiteres in der DAL nutzen könnte. Meine DAL müsste, bspw. beim Speichern eines Lieferanten, diesen zuerst in ein DataTable reinpacken, bevor er an die "DataAccess"-Schicht übergeben werden könnte. Dieser zusätzliche Vorgang würde sicherlich die Performance der Anwendung verschlechtern.
Einen Vorteil in meinem Ansatz sehe ich darin, dass mir bei einer konkreten Klasse "Lieferant" dessen Methoden, Eigenschaften usw. bekannt sind. So könnte ich bspw. den Namen eines Lieferanten über Lieferant.Name setzen, während ich bei einem DataTable ja stets den genauen Namen der Spalte im Kopf haben muss, um den Lieferantennamen über LieferantTable["Name"] setzen zu können.

Wie sieht es denn eigentlich bei der Übertragung von Geschäftsobjekten über einen Webservice aus? Lassen sich DataTable oder DataSet über jeden Webservice übertragen. Über .Net Remoting dürfte es möglich sein. Aber wie steht es da bspw. mit SOAP? Selbst wenn .Net die Serialiserung dieser Typen unterstützt, so hat der Client doch das Problem diese auf seiner Seite wieder zu deserialisieren und sich zusätzlich mit allen Spaltennamen herumschalgen zu müssen. Wäre es hier nicht besser konkrete Typen übertragen zu können. Also "Lieferant", "Artikel"...?

Danke an JAck30lena und Lynix!

Der Fehler kam aus einer anderen Ecke.
Ich werde es nur kurz anreissen um den Beitrag nicht so stehen zu lassen.

Wir haben einige statische Methoden um den Client- bzw. Serverchannel zu erstellen. Hier hatte ich auch Vorkehrungen getroffen, um über diese Methoden auch CAO's (Client-Acivated-Objects) zu ermöglichen, also Server-Objekte die erst über den Aufruf eines Clients aktiviert werden.
Um dies zu ermöglichen müssen die Channels folgendermaßen konfiguriert werden:

	
IDictionary channelSettings = new Hashtable();
		
channelSettings["machineName"] = SystemInformation.ComputerName + "." + Domain.GetCurrentDomain().Name;   // Wird für CAO's benötigt

IChannel channel = new TcpChannel(channelSettings, null, providerChain);

Für Computer innerhalb von Domänen musste der volle Domänenname angegeben werden. Und genau hier lag das Problem. Ist der Benutzer nicht an der Domäne angemeldet, wirft "GetCurrentDomain()" eine Exception mit der oben genannten Fehlermeldung.

Trotzdem Gruß und Dank an euch!
Bis bald!

Hallo zusammen!
Habe eine Frage bezüglich .NET-Remoting über VPN.

Wir sind Hersteller eines Warenwirtschaftssystems und eines Kassensystems.
Unser Kassensystem (Client) kommuniziert für bestimmte Abfragen mit dem Warenwirtschaftssystem (Server) über .NET-Remoting.
Soweit zur Vorgeschichte.

Im lokalen Netzwerk funktioniert die Kommunikation fehlerfrei.
Der Versuch den Client (eines außer-Haus-Rechners) mit dem Server (In-House-Rechner) zu verbinden schlägt fehl. Der Client ist über VPN mit dem Netzwerk unseres Hauses verbunden. Ein Ping auf die IP-Adresse des Server funktioniert ebenfalls.
Folgende Fehlermeldung wird auf Client-Seite zurückgeliefert:

"Der aktuelle Sicherheitskontext ist keiner Active Directory-Domäne oder - Gesamtstruktur zugeordnet"

Der Server ist NICHT in IIS gehostet.

Kann jemand damit was anfangen?
Mehr Informationen benötigt?

Gruß und danke!