Problemas de endpoint e basicHttpBinding do Visual Studio

Question

Eu tenho um aplicativo WPF no VS 2008 com algumas referências de serviços web.Por vários motivos (tamanho máximo da mensagem, métodos de autenticação), preciso definir manualmente uma série de configurações no app.config do cliente WPF para as ligações de serviço.

Infelizmente, isso significa que quando eu atualizo as referências de serviço no projeto, acabamos com uma bagunça – múltiplas ligações e endpoints.O Visual Studio cria novas associações e pontos de extremidade com um sufixo numérico (ou seja, "Service1" como uma duplicata de "Service"), resultando em uma configuração inválida, pois pode haver apenas uma única associação por referência de serviço em um projeto.

Isso é fácil de duplicar - basta criar um serviço web ASP.Net simples "Hello World" e um aplicativo WPF em uma solução, alterar maxBufferSize e maxReceivedMessageSize na ligação app.config e atualizar a referência de serviço.

No momento, estamos resolvendo isso simplesmente desfazendo o checkout no app.config depois de atualizar as referências, mas não posso deixar de pensar que deve haver uma maneira melhor!

Além disso, as configurações que precisamos alterar manualmente são:

<security mode="TransportCredentialOnly">
    <transport clientCredentialType="Ntlm" />
</security>

e:

<binding maxBufferSize="655360" maxReceivedMessageSize="655360" />

Usamos uma classe de fábrica de serviços, portanto, se essas configurações puderem ser definidas programaticamente, isso funcionaria, embora as propriedades não pareçam estar expostas.

Answer 1

Crie um arquivo .Bat que use svcutil, para geração de proxy, que tenha as configurações adequadas para o seu projeto.É bastante fácil.Clicando no batfile, para gerar novos proxyfiles sempre que a interface for alterada é fácil.

O lote pode então ser usado posteriormente em compilações automatizadas.Então você só precisa configurar o app.config (ou web.config) uma vez.Geralmente separamos as diferentes configurações para diferentes ambientes, como dev, test prod.

Exemplo (cuidado com quebras de linha):

REM generate meta data
call "SVCUTIL.EXE" /t:metadata "MyProject.dll" /reference:"MyReference.dll"

REM making sure the file is writable
attrib -r "MyServiceProxy.cs"

REM create new proxy file
call "SVCUTIL.EXE" /t:code *.wsdl *.xsd /serializable /serializer:Auto /collectionType:System.Collections.Generic.List`1  /out:"MyServiceProxy.cs" /namespace:*,MY.Name.Space /reference:"MyReference.dll" 

:)

//C

Answer 2

Em vez de alterar o endpoint gerado, você pode adicionar um segundo endpoint e uma definição de ligação com a configuração necessária e, em seu código, basta colocar o nome do novo endpoint no construtor do cliente de serviço.

Answer 3

De alguma forma, prefiro usar svcutil.exe diretamente do que usar o recurso "Adicionar referência de serviço" do Visual Studio: P Isso é o que estamos fazendo em nossos projetos WCF.

Answer 4

Entendo seu ponto de vista, svcutil é definitivamente a maneira mais avançada de adicionar e atualizar referências de serviço.É apenas um pouco mais de trabalho manual quando "clique com o botão direito, atualizar referência" está tão perto de funcionar em uma única etapa.

Acho que poderíamos criar alguns arquivos em lote ou algo assim apenas para gerar o código de referência.Mesmo assim, verificar e atualizar manualmente o código de serviço com svcutil provavelmente será mais trabalhoso do que apenas desfazer o check-out na configuração.

Obrigado pelo conselho em qualquer caso.

Answer 5

O que fazemos é verificar (no controle de origem) os arquivos app.config e *.cs que são gerados automaticamente pelo utilitário svcutil.exe e, em seguida, executar um arquivo em lote que executa svcutil.exe para recuperar os metadados do serviço.Quando terminar, recompilamos o código, verificamos se ele funciona e, em seguida, verificamos novamente os arquivos app.config e *.cs atualizados.É muito mais confiável do que usar o frequentemente problemático "Adicionar referência de serviço" com o Visual Studio.