git_bsmd/bsmd.dbh
2021-11-10 09:29:31 +01:00
..
Properties moving directories around 2021-11-10 09:29:31 +01:00
Web References/DBHWebReference moving directories around 2021-11-10 09:29:31 +01:00
app.config moving directories around 2021-11-10 09:29:31 +01:00
bsmd.dbh.csproj moving directories around 2021-11-10 09:29:31 +01:00
log4net.config moving directories around 2021-11-10 09:29:31 +01:00
NSWResponse.cs moving directories around 2021-11-10 09:29:31 +01:00
packages.config moving directories around 2021-11-10 09:29:31 +01:00
readme.txt moving directories around 2021-11-10 09:29:31 +01:00
Request.cs moving directories around 2021-11-10 09:29:31 +01:00
Response.cs moving directories around 2021-11-10 09:29:31 +01:00

Um etwas mehr Kontrolle über die Erzeugung von Klassen aus .xsd Dateien zu haben verwende ich nicht
das mitgelieferte xsd.exe sondern ein VS Plugin  http://xsd2code.codeplex.com/
Es wird über Kontext-Menü auf der XSD Datei gestartet. Deshalb ist diese auch hier im Projekt enthalten.

Damit man einen Web-Service erhält, der nicht die private Felder sondern die Properties der
generierten Klasse verwendet, muss man 
[OperationContract] und [XmlSerializerFormatAttribute()]
auf der Interface-Methode verwenden. 

Neu:
Der Namespace darf nicht im endgültigen SOAP Call enthalten sein. Dazu habe ich in den
generierten Service-Klassen den Namespace auf "" gesetzt.wsdl.exe war nicht notwendig!

so:
[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://www.openuri.org/submit", RequestNamespace="", ResponseElementName="submitResponse", ResponseNamespace="", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]