Fehler "Objekt ist schreibgeschützt" beim Festlegen von ClientCredentials in WCF

Question

Ich habe ein Proxy-Objekt, das von Visual Studio (Clientseite) namens ServerClient generiert wird. Ich versuche ClientCredentials.UserName.UserName/Passwort zu setzen, bevor eine neue Verbindung mit diesem Code eröffnen:

InstanceContext context = new InstanceContext(this); 

m_client = new ServerClient(context); 
m_client.ClientCredentials.UserName.UserName = "Sample"; 

Sobald der Code Treffer der Usernamen Linie mit einem Ausfall „Objekt ist schreibgeschützt“ Fehler . Ich weiß, dass das passieren kann, wenn die Verbindung bereits offen oder fehlerhaft ist, aber an diesem Punkt habe ich context.Open() noch nicht aufgerufen.

Ich habe die Bindungen konfiguriert (die netTcpBinding verwendet), um Message als Sicherheitsmodus zu verwenden, und MessageClientCredentialType ist auf UserName festgelegt.

Irgendwelche Ideen?

Answer 1

Es scheint, dass Sie auf diese Eigenschaften nur sehr früh im Instanziierungszyklus zugreifen können. Wenn ich den Konstruktor in der Proxy-Klasse (Serverclient) außer Kraft setzen, ich bin in der Lage, diese Eigenschaften zu setzen:

base.ClientCredentials.UserName.UserName = "Sample"; 

Ich fange an, die Leute zu schätzen, die empfehlen, nicht die automatisch erstellt Proxies von VS. bereitgestellt

Answer 2

Ich denke, dass Ihr Problem mit der Verwendung von InstanceContext in Verbindung stehen könnte. Ich dachte, das wäre nur für Duplex-Kommunikationskanäle von der Serverseite benötigt.

Ich gebe zu, ich bin mir nicht sicher, aber ich denke, in diesem Fall sagen Sie dem Client, einen vorhandenen Instanzkontext zu verwenden, damit er denkt, dass bereits ein Dienst läuft und keine Änderungen zulässt.

Was treibt die Verwendung von InstanceContext an?

Answer 3

Ich habe ähnlichen Code, die UserName Fines vorbei:

FooServiceClient client = new FooServiceClient("BasicHttpBinding_IFooService"); 
    client.ClientCredentials.UserName.UserName = "user"; 
    client.ClientCredentials.UserName.Password = "password"; 

Versuchen Sie, die Proxy-Erstellung mit dem Namen in app.config verbindlich.

Answer 4

hier die colution ist:

using SysSvcmod = System.ServiceModel.Description; 

SysSvcmod.ClientCredentials clientCredentials = new SysSvcmod.ClientCredentials(); 
clientCredentials.UserName.UserName = "user_name"; 
clientCredentials.UserName.Password = "pass_word"; 

m_client.ChannelFactory.Endpoint.Behaviors.RemoveAt(1); 
m_client.ChannelFactory.Endpoint.Behaviors.Add(clientCredentials); 

Answer 5

Wenn ein Duplex-Client verwenden, wenn Sie ihm das Duplex im DuplexClientBase instanziiert, dass Ihr Kunde von abgeleitet wird mit dem bestehenden Anmeldeinformationen initialisiert wird, so dass es den Callback-Kanal öffnen kann, Aus diesem Grund würden die Anmeldeinformationen nur gelesen werden.

Ich zweite Mike Frage und auch fragen, warum verwenden Sie NetTcpBinding, wenn Sie nicht die inhärente Transport-Level-Sicherheit verwenden? Vielleicht wäre eine HTTP-basierte Bindung besser geeignet? Das würde Ihnen erlauben, zertifikatsbasierte Sicherheit zu verwenden, von der ich glaube, dass sie nach Instanziierung geändert werden kann (http://msdn.microsoft.com/en-us/library/ms576164.aspx).

Answer 6

Eine Aufnahme im Dunkeln, aber ermöglicht netTcpBinding die Validierung von Benutzernamen und Passwort? Versuchen Sie die Verwendung von Application Layer (SOAP) -Sicherheit mit einem HTTP-Bindung

Answer 7

Ich habe festgestellt, dass nach dem Erstellen einer Instanz der Proxy-Klasse für den Dienst, ich den Benutzernamen und das Passwort einmal ohne Fehler setzen und einen erfolgreichen Aufruf an meinen Webservice. Wenn ich dann versuche, den Benutzernamen und das Passwort für die existierende Instanz erneut zu setzen (was natürlich unnötig ist), bekomme ich den Fehler "Object is Read-Only", den Sie erwähnt haben. Das Festlegen der Werte einmal pro Instanzlebensdauer funktionierte für mich.

Answer 8

Die korrekte Syntax ist:

// das ClientCredentials Verhalten entfernen. client.ChannelFactory.Endpoint.Behaviors.Remove <ClientCredentials>();

// Fügen Sie eine benutzerdefinierte Client-Anmeldeinstanz zur Auflistung der Verhalten hinzu. client.ChannelFactory.Endpoint.Behaviors.Add (neues MyClientCredentials());

http://msdn.microsoft.com/en-us/library/ms730868.aspx

Es ist für mich gearbeitet.

Answer 9

Ich hatte das gleiche Problem, mein Code begann zu arbeiten, als ich meinen Code änderte, d. H. Die Client-Credentials direkt nach der Initialisierung des Client-Objekts Werte zuweisen.

hier ist die Lösung,

ProductClient Manager = new ProductClient();  
Manager.ClientCredentials.UserName.UserName = txtUserName.Text; 
Manager.ClientCredentials.UserName.Password = txtPassword.Text;