Получение “Объекта является” ошибкой только для чтения когда установка ClientCredentials в WCF
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
6 ответов
Кажется, что можно только получить доступ к этим свойствам довольно рано в instanciation цикле. Если я переопределяю конструктора в прокси-классе (ServerClient), я могу установить эти свойства:
base.ClientCredentials.UserName.UserName = "Sample";
я начинаю ценить людей, которые предлагают не использовать автоматически созданные прокси, обеспеченные VS.
У меня есть похожий код, который передает UserName отлично:
FooServiceClient client = new FooServiceClient("BasicHttpBinding_IFooService");
client.ClientCredentials.UserName.UserName = "user";
client.ClientCredentials.UserName.Password = "password";
Попробуйте создать прокси с именем привязки в app.config.
Я думаю, что Ваша проблема могла бы быть связана с использованием InstanceContext. Я думал, что это было только необходимо для дуплексных каналов передачи от стороны сервера.
я признаю, что я не уверен в этом, но я думаю в этом случае, что Вы говорите клиенту использовать существующий контекст экземпляра, таким образом, он думает, что уже существует рабочий сервис и не позволит изменения.
, Что управляет использованием InstanceContext?
вот решение:
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);
Если вы используете дуплексный клиент, то при его инициализации DuplexChannelFactory в DuplexClientBase, на основе которого создан ваш клиент, инициализируется существующими учетными данными, чтобы он мог открыть канал обратного вызова, поэтому учетные данные будут только считываться.
I второй вопрос Майка, а также вопрос, почему вы используете NetTcpBinding, если вы не собираетесь использовать встроенную в него безопасность на транспортном уровне? Может быть, лучше использовать HTTP-связку? Это позволило бы вам использовать безопасность на основе сертификатов, которая, как мне кажется, может быть изменена после инстанцирования (http://msdn.microsoft.com/en-us/library/ms576164.aspx).
.Выстрел в темноте, но позволяет ли netTcpBinding проверять имя пользователя и пароль? Попробуйте использовать безопасность на уровне приложений (SOAP) с помощью привязки http