Ошибка получения объекта только для чтения при настройке ClientCredentials в WCF

Я заметил, что после создания экземпляра прокси-класса для службы я могу один раз установить имя пользователя и пароль без ошибок и выполнить успешный вызов своего веб-сервиса. Когда я затем пытаюсь снова установить имя пользователя и пароль для существующего экземпляра (конечно, ненужного), я получаю упомянутую вами ошибку «Объект только для чтения». Установка значений один раз за время жизни экземпляра сработала для меня.

Похоже, что вы можете получить доступ к этим свойствам довольно рано в цикле инстанцирования. Если я переопределяю конструктор в прокси-классе (ServerClient), я могу установить эти свойства:

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

Я начинаю ценить людей, которые предлагают не использовать автоматически созданные прокси, предоставляемые VS.

вот решение:

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);

У меня есть аналогичный код, который проходит UserName нормально:

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

Попробуйте создать прокси с именем привязки в app.config.

Я столкнулся с той же проблемой, мой код начал работать, когда я изменил свой код, то есть присвоил значения учетным данным клиента сразу после инициализации объекта клиента.

вот решение,

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

Правильный синтаксис:

// Remove the ClientCredentials behavior.
client.ChannelFactory.Endpoint.Behaviors.Remove<ClientCredentials>();

// Add a custom client credentials instance to the behaviors collection.
client.ChannelFactory.Endpoint.Behaviors.Add(new MyClientCredentials());

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

Это сработало для меня.

Этого не произойдет, если ссылка на службу добавлена ​​через -> Добавить ссылку на службу -> Дополнительно-> Добавить веб-ссылку-> Url/wsdl (файл на локальном диске).

Я столкнулся с этой проблемой, когда пытался создать общий метод для создания клиентов для разных конечных точек.

Вот как я этого добился.

    public static T CreateClient<T>(string url) where T : class
    {
        EndpointAddress endPoint = new EndpointAddress(url);
        CustomBinding binding = CreateCustomBinding();

        T client = (T)Activator.CreateInstance(typeof(T), new object[] { binding, endPoint });
        SetClientCredentials(client);

        return client;
    }

    public static void SetClientCredentials(dynamic obj)
    {
        obj.ChannelFactory.Endpoint.Behaviors.Remove<ClientCredentials>();
        obj.ChannelFactory.Endpoint.Behaviors.Add(new CustomCredentials());

        obj.ClientCredentials.UserName.UserName = "UserId";
        obj.ClientCredentials.UserName.Password = "Password";
    }

Я думаю, что ваша проблема может быть связана с использованием InstanceContext. Я думал, что это нужно только для дуплексных каналов связи со стороны сервера.

Я признаю, что не уверен в этом, но я думаю, что в этом случае вы говорите клиенту использовать существующий контекст экземпляра, поэтому он думает, что уже запущена служба, и не допустит изменений.

Что движет использованием InstanceContext?

При использовании дуплексного клиента, когда вы создаете его экземпляр, DuplexChannelFactory в DuplexClientBase, производным от которого является ваш клиент, инициализируется существующими учетными данными, чтобы он мог открыть канал обратного вызова, поэтому учетные данные будут доступны только для чтения.

Я поддерживаю вопрос Майка, а также спрашиваю, почему вы используете NetTcpBinding, если вы не собираетесь использовать присущую ему безопасность на транспортном уровне? Возможно, лучше подойдет привязка на основе HTTP? Это позволит вам использовать безопасность на основе сертификатов, которую, я считаю, можно изменить после создания экземпляра (http://msdn.microsoft.com/en-us/library/ms576164.aspx).

Выстрел в темноте, но разрешает ли netTcpBinding проверку имени пользователя и пароля? Попробуйте использовать безопасность прикладного уровня (SOAP) с помощью привязки http

или вы можете просто проверить учетные данные

    if (client.ClientCredentials.ClientCertificate.Certificate == null || string.IsNullOrEmpty(client.ClientCredentials.ClientCertificate.Certificate.Thumbprint))
    {
        client.ClientCredentials.ClientCertificate.SetCertificate(
            StoreLocation.LocalMachine,
            StoreName.My,
            X509FindType.FindByThumbprint, ConfigurationManager.AppSettings.Get("CertificateThumbprint"));
    }