An important web services security requirement is nonrepudiation. This requirement prevents a party from denying it sent or received a message. The way to implement this is using Xml Digital Signatures. For example, if I sent a message which is signed with my private key, I cannot later deny that I sent it.
A common mistake is to think that every web service that require an X.509 certificate ensures nonrepudiation. This goes without say for web services that only require server certificate - in these services clients are either anonymous or username/password identified, which is considered weak cryptographically material.
However, also when a client X.509 is involved, nonrepudiation is not always guaranteed. For example, let's examine a Wcf service which uses WsHttpBinding with TransportWithMessageCredential and clientCredentialType="Certificate":
This is how the client request looks like:
The message body is not signed! This practically means anyone who has this message (for example the server) can extract the signed parts and resend them with a bogus body.
When your unit test is not implemented yet you want to make sure everybody knows about it. One bad way is to throw an exception in the test first line:
The reason is that when you see in the report this failure you can never tell if the error comes from the unit test or the application under test...
The good solution is to use a build in feature of your unit test framework. For example, the Ignore attribute in NUnit. If for some reason you have to throw an exception (so the test will be red) at least throw some better error class like "new UnitTestNotImplementedException()".
Our unit tests are expected to pass every time. When they fail we are expected to fix the regression. But in some cases it is ok for a test to temporarily not pass. For example, if the test is a small regression in a minor feature and we are currently employed with other critical missions. But while the test is failing we should at least make sure it will not cause any noise like spamming out the team.
When we use NUnit, the solution is the Ignore attribute:
A common programming task is to extract some meaningful name from a url. One example is saving the contents of a url to a file name on disk - we need to have the name for the file. Bellow there is a c# method that I have written that extracts this name + the results it produces on a few urls.
What is it? BindingBox is an online application that converts WCF bindings to a customBinding configuration.
Why we need it? WCF bindings capture a general use case and allow us to customize it. For example, basicHttpBinding is good for interoperability with older soap stacks while WSHttpBinding fits WS-* based communication. However, there are cases where we can not use the out of the box bindings. For example:
We want to further customize the binding behind what it exposes. For example, we might want WSHttpBinding not to send a timestamp (for interoperability reasons) but this is not a built in option.
We have a special use case which is not captured by any of the out-of-the-box bindings. For example, we want to use binary encoding over http.
In such cases we need to convert our binding into a custom binding. This is not a trivial process. In particular, some security settings can be very frustrating to translate.
For this reason I have written the WCF BindingBox. This is an online application which automatically converts any binding to a customBinding.
How to use it - Tutorial
Step 1 - Get your current binding
Just open your web.config or app.config file and navigate to the "<bindings>" element. Then copy its content to the clipboard. Be sure to copy the wrapping "<bindings>" element as well:
Step 2 - Convert your binding
Just navigate to the BindingBox and paste your binding from step 1. Then click on the "Convert to CustomBinding" button and copy to the clipboard your new binding. It may look like this:
Step 3 - Use the custom binding
Basically, you now just need to use the BindingBox result as your binding configuration.
In practice you would do it in one of the following ways:
In your .config file manually configure your endpoint to use a custom binding and set its configuration.
Use the WCF configuration editor to configure your endpoint to use a CustomBinding. then in your .config override the default customBinding configuraiton with the BindingBox result.
j_saremi has posted a message in the WCF forum noticing that WCF source code can now be downloaded from Microsoft. The source can be viewed using the reflector since ever - no news here - but now it can actually be used to debug!
If you have followed the previouspartsofthisseries you already know it tries to diminish the mystery of WCF errors.
When X.509 certificates are used you might get this error:
The second part of the error implies that you may need to set permissions on the private key. I'll deal with that in a separate post.
The first part of the error means that the certificate was created with a private key that is not capable of key exchange. This can happen when you use makecert.exe to create a test certificate without specifying the correct flags. The correct way to use makecert is:
We are using the log4net logging framework in a new project. In one initialization point of the application we init it:
And in many other locations we use it:
In one of my classes the messages I've logged did not appear in the log file (or in any of the other appenders). When I explicitly re-initialized log4net in the same class the messages were written successfully. A short investigation found the reason: This class is called from a different AppDomain than the other classes. log4net's LogManager class is static, which limits its scope to the calling AppDomain.
Conclusion: log4net needs to be initialized once per AppDomain.
Recently I have checked the possibility to bring Microsoft's Web Services Enhancements (WSE) 3.0 in the installation of a product I author. I already know that Microsoft products cannot be dispatched as is and I need a special redistributable version. Luckily, WSE3 has a Redistributable Runtime MSI.
So I run this msi and the first stage in the installation wizard is the end user license agreement (EULA). Now I'm not a legalist but the beginning looks promising:
"Microsoft...and you" sounds good, and "you may install" is what I wanted to hear anyway. But the second item is suspicious:
Now wait one second. If I may not transfer the software to any third party, then how can I redistribute this Redistributable Runtime MSI? Or is this EULA just an agreement between Microsoft and the third party, in which case where is the agreement between Microsoft and me? Am I not worth at least one or two vague terms?
Anyway I passed this to our legal department. I better go work on some legacy code, which comparing to this looks more readable than ever...
Prabath gave a great presentation on SOA & web services security in the WSO2 summer school. It is particularily interesting for everyone who wants to understand what stands behind security related WS-* standards such as WS-Security and WS-Trust.
This one is for the bloggers among my readers but actually everyone can find it useful.
You might have noticed recently how downloadable items in my blog appear. For example here is my unit tests presentation:
My file storage service is microsoft's Skydrive. Basically you can upload there any file you want and share it with everyone. This is a free service.
Generally I'm happy with it but here are some points to improve:
There is no direct link for download - users need to enter the "windows live" portal and download from there. I guess there is a traffic reason for this. But there may be alternatives, like having the link embedded in the consuming site with some logo/link to msn. Update:Tim Acheson has created an API to get the direct link.
The download link in the live spaces portal is not explicit enough. Yes, the file is just one click away, but the image does not look clickable enough and the "download" link is pale:
No statistics such as "how many users downloaded this file". Very important, in particular to bloggers.
The embedded files do not appear in feed readers (since they use IFrame):
site:
reader:
If you will surf to
before you'll notice it you'll be in
which makes it hard to add skydrive to the browser favorites.
I know some Microsoft employees read my blog so hopefully these issues will be resolved in a future release ;-)
However it is interesting to see how it is still relevant even a few years later when new frameworks are around.
The two common paradigms for building a web service are code-first and contract-first. The former means you start writing your c#/java/whatever service code and generate the contract (wsdl) from it. The latter means you first create the wsdl (either manually or using some tool) and then create the service code from it.
So with code-first you write this:
And this is auto generated for you:
While in contract-first you write the wsdl (possibly using a tool) and the code is generated.
Pros for code-first:
Developers are already familiar with code so development is faster. Being veteran developers, architects are also code-savvy.
More online resources
You'll need to use it anyway
Pros for contract first:
Better interoperability
Defers implementaiton details
You'll need to use it anyway
Code first is the de-facto "default setting" in almost all frameworks - most tutorials and documentation use it. So contract-first is much more interesting from a "let's write an interesting post" POV.
In the next series of posts I'll write on the contract-first approach using several frameworks.
My opinion on the matter is that it does not really matter. Contract-first is important from the interoperability perspective, but most frameworks do not support all wsdl/schema artifacts. So ignoring the code you'll find yourself working with a perfectly interoperable wsdl that no framework can consume. For example xsd:union is not supported in .Net and xsd:choice isn't in Axis2 1.3. Contract without an implementation is useless.
On the other hand, code-first also requires you to look in the generated wsdl and verify it is interoperable. A service that can't be consumed is also useless.
So code-first or contract-first? Whatever, you'll need to do both anyway.
When working with a WCF client proxy we need to close it after usage. Failing to do so would of course affect our client performance. However it would also affect our server performance and in some cases might block new client from connecting to it. One example is when using sessions (which is the default wcf behavior): Since the open sessions number is limited a non-closed client might block a new client.
However the simple way of closing a client:
is naive. The close may fail, for example due to the client not being able to release the session because of a server problem. For this reason we need to catch any possible exception.
I've just published a post on how to use WSE3 with Visual Studio 2008. I forgot to mention that the same technique can be used to have WSE2 and VS 2005 (or even VS 2008) working together.
Microsoft has provided WSE3 a Visual Studio 2005 add-in with nice UI support. Look how nice it is:
The less nice part is that there is no such support for Visual Studio 2008 as Microsoft is encouraging us to use WCF instead. Which is a good idea generally, but not alway feasible: The reality is that a lot of the WSE3 & VS 2005 projects were migrated to VS2008 and lack this fundemental support. Also a lot of new projects need compatability with WSE3 which is not always possible with WCF.
So how WSE3 can work with VS2008?
The truth is that the WSE run time is agnostic to the IDE version. IOW projects built with VS 2008 can use WSE3 in run time in the same way as VS 2005 projects. This means we are left with the tiny mission of actually developing these projects. Well, not so tiny but also not too hard. We have two options for our needs:
Option 1 - Trainer Wheels
We need to remember that configuring WSE infrastructure is mostly a one-time mission - we do not frequently alter it during development. So we can create a VS2005 project with WSE3 and migrate it to VS2008 as is using the VS migration wizard. Usually we would never need to look at the WSE configuration until late stages. Then we can open our VS2005 project, change what we want from UI, and notice that such changes only affect this section of our web.config/app.config:
So we can copy&paste this part to our new project. In case we use a .policy file we can copy all of its contents to the new project. If this looks lame it's only because VS 2005 is strictly a trainer wheel here, we do not actually need it. For this we have:
Option 2 - Just 2008, Please
We can directly use WSE3 with VS2008 in the following way:
1. In our project, add assembly reference to "Microsoft.Web.Services3.dll" (it's in the GAC and also in %Program Files%\Microsoft WSE\v3.0)
2. If we are creating the client side we would like to use "add web reference". This is not available but luckily we have the option to use %Program Files%\Microsoft WSE\v3.0\Tools\WseWsdl3.exe:
This will create our proxy .cs file which we can add to our project. The file looks like this:
So in our code we can create a new instance of this class and call the service:
For the service side we can just create a new normal web service project, nothing special.
3. We can now use the WseConfigEditor3.exe tool that comes with the WSE3 SDK to edit our app.config/web.config and even add a policy file. Then in our client code we can tell the proxy to use this policy:
This is the same we would do with VS 2005 so no news here.
If we are on the server side we need to check both "Enable this project for Web Services Enhancements" and "Enable Microsoft Web Services Enhancements Soap Protocol Factory" in the configuration editor:
or something along these lines, and have no idea what this quota is good for, we face the temptation to put there a ridiculously large number (like 6.10* 8^23) so we would never have to it again. We should hold ourselves from doing this and put a rational number based on our needs. See the story bellow.
Ayende published an interesting post on a case where he needed to send a large number of objects between a WCF client and server. For this he had to alter some server-side default:
When he "update service reference" on his client he found out that this setting is not propagated to the clients which forces him to manually change this setting in each and every client (as stated in MSDN).
Arnon follows this up in his post and claims the following:
This setting needs to be automatically propagated to clients
There are other settings which are not propagated and needs to be, for example message size limits
The default setting should be higher (although not infinite)
I absolutely agree with the first claim. This setting is in effect both when sending and receiving data. Since in each call one party sends and another receives this setting has to be correlated between the parties. The way to dispatch this setting to clients would probably by extending the wsdl's WS-Policy with this new setting (which would be msn proprietary for that matter).
I only partially agree with Arnon's second statement. The MaxReceivedMessageSize setting (if it's the one he refers to) only affects the receiving side. There is no limit on the size of outgoing messages. Here it makes sense to have a different value for the client and the server since they probably have different capabilities in terms of hardware and they also need to handle different data.
Going back to the opening paragraph, I want to make clear the rational behind all of these settings (and me and Arnon are probably in agreement on this). These settings are not meant to directly improve the performance of the service but rather they aim to block DOS attacks. So if the limit on this setting is too high an attacker can send an XML bomb which will consume large server resources. These settings are much more important for the server then for the client, but as long as clients allow to customize them the client values do not always have to be correlated with the server ones.
Visual Studio 2008 comes with project templates for a WCF web site and a WCF service library. But what about self hosting?
I've create a simple self hosting template which you can use when starting new projects. This is useful for real projects as well as for quick POC/prototyping projects. For the latter it brings the following advantages over the out of the box templates:
It encapsulates the service as an executable so it can be easily deployed without messing with IIS (xcopy is enough)
It enables to use transports which are not supported in web sites (e.g. netTcp).
So without any further preparations let's see how to use ClearUsernameBinding.
Step 1: Download latest release
Download it here or go to google codegithub.
Then extract the zip to some folder, let's say C:\program files\ (the ClearUsernameBinding subfolder will be created when extracting the zip).
Step 2 (optional) - Run the sample project
It can be useful to run the sample application.
Run the server:
And now the client:
And if everything went smoothly you have just seen ClearUsernameBinding in first action!
Step 3 (optional) - Investigate the sample project source code
The best way to learn a new (and very simple in this case) technology is by looking at existing projects. Just open with VS 2008 the solution file:
And look at the source of the projects TestClient and TestService. These two projects are just normal WCF projects configured to use ClearUsernameBinding. In other words, making a WCF client/service use ClearUsernameBinding is just a matter of changing web.config and does not require coding. We will see in the next steps how to do it from scratch.
I'll probably have a separate post on the binding implementation itself. It is pretty straight forward and the handling of security is as I learned from Nicholas Allen's blog.
Step 4 - Creating your own service
For this step just create any normal WCF web site or a self hosted service.
Step 5 - Configure the service to use ClearUsernameBinding
Add your project a dll reference to
Then open web.config and register the ClearUsernameBinding under the system.ServiceModel section:
Finally configure your endpoint to use ClearUsernameBinging and its configuration:
Step 6 (optional) - Configure the message version
If you need to use a specific message version configure it in the "messageVersion" attribute in the above configuration. Valid values are: Soap11WSAddressing10, Soap12WSAddressing10, Soap11WSAddressingAugust2004, Soap12WSAddressingAugust2004, Soap11, Soap12, None, Default.
Example:
Step 7 - Configure the username authentication
This one needs to be done in any username/password authenticated service and not just one that uses ClearUsernameBinding. By default your server will authenticate the users against your active directory domain. If you want to do your own custom authentication you need to create a new class library project with a class that implements System.IdentityModel.Selectors.UserNamePasswordValidator
The class can look like this:
Don't forget to add dll reference to System.IdentityModel and System.IdentityModel.Selectors or the project will not compile. Then add this project as a project reference to your service project/website and configure the latter to use this custom authenticator:
Step 8 - Run the service
Yes, the service is now ready to be activated, so run it when you are ready (run it directly from VS, just press F5).
Step 9 -Build a client
A service is worth nothing if there are no clients to consume it.
Create a new console application.
Right click the "References" node in the solution explorer and choose "Add service reference". Specify the WSDL of the server. If you are running the server from the given sample then the wsdl is in http://localhost:8087/SampleService/?WSDL. If you used your own server just run it and get the wsdl.
Now add some client code that uses the proxy to call the service. Don't forget to specify your username/password. For example:
Step 10 - Configure the client
Configuring the client is as simple as configuring the service.
Here is the full client app.config:
Step 11 - Done, Done, Done!
That's all. You can now run your client and see how WCF can be used to access a service with a cleartext username/password. Use a tool like fiddler to verify that indeed a clear username is sent (I've shorten some low-level stuff from bellow message):
Conclusion
Sending username/password on the clear is not available out of the box with WCF (for reasons mentioned above). If such a scenario is required then ClearUsernameBinding needs to be used.
The following interoperability issue can happen with a .Net 3.5 clients and older web services from various platforms (including Java. and .Net)
Everyone knows that Visual Studio 2008 has a build-in support for WCF which is the latest generation of Microsoft soap stack. By default, when writing web service clients in VS 2008 a WCF-flavored proxy is generated. However WCF only supports a subset of XML schema and WSDL patterns. For example it does not support RPC/Encoded WSDLs and XML attributes. Many older WSDLs use RPC/Encoded. With such WSDLs WCF is supposed to gracefully downgrade itself to .Net 2.0 which does support these WSDLs. I have noticed that in some cases this does not happen correctly. The result can be web service methods returning null instead of values.
The solution for such cases is to manually instruct VS 2008 to use its backward compatible proxy. All you need to do is:
So, you want to write an Axis2 web service and have .Net WCF clients too? Or maybe you already have a .Net 2.0 endpoint and want it to be consumed by WSIT? Yes, that’s possible, but there is some important stuff you should know about. Whether you are a .Net WCF, AXIS2, Metro or any other framework developer/tester – you want to stay tuned for this series.
When a Java client sends a request to a secured WCF service sometimes this soap fault can come back:
The problem is with the X.509 certificate/key that the client is using: It is of version 1 of X.509. WCF only supports version 3 certificates. We can see that the request strictly stated it was using v1:
Interestingly enough, Wcf can work with the certificate content itself so if we could change the SOAP to have “v3” instead of “v1” everything would have worked. However the straight forward way to solve this is to use X.509V3 at the client side. BTW We can see the certificate version by double clicking its file in windows:
A lot of people use WCF default settings on production. In many cases changing these defaults can gear up the service throughput dramatically.
Let's look at the following use case:
The WsHttpBinding implicit defaults can be explicitly written as bellow:
Let's simulate a load on this service by employing many virtual users who constantly call the service one time and immediately disconnect. The number of users should be large enough such that service will use its max capacity. The results are:
Note: I didn't use a super strong server here but as we can see below it shouldn't matter for our needs. Also a load of just a few minutes was enough to prove our theory.
Those are not very good results of course.
Now let's tweak the configuration a little bit:
And with the same amount of virtual users we get these results:
That's 3.5 times faster!
So, what happened here? Since the only change we did is in two settings we need to analyze each of them.
negotiateServiceCredential This setting determines whether the clients can get the service credential (e.g. certificate) using negotiation with the service. The credentials are used in order to authenticate the service and to protect (encrypt) the messages. When this setting is set to "true" a bunch of infrastructure soap envelopes are sent on the wire before the client sends its request. When set to "false" the client needs to have the service credentials out of band.
The trade off here is better performance (using "false") versus more convenience (using "true"). Setting "false" has its hassles as we now need to propagate the service credential to clients. However, performance wise, setting "negotiateServiceCredential" to "false" is always better.
Take a look at how many infrastructure messages are exchanged when negotiateServiceCredential is "true":
While when not negotiating life is much brighter:
establishSecurityContext This setting determines whether WS-SecureConversation sessions are established between the client and the server. So what is a secure conversation anyway? In a very simplified manner we can say that a normal secured web service request requires one asymmetric encryption. Respectively, normal N requests require N asymmetric encryptions. Since asymmetric encryption is very slow, setting up a secure conversation is usually a good practice: It requires a one-time asymmetric encrypted message exchange in order to set up a session; Further calls in the session use symmetric encryption which is much faster.
Now remember that in our case we assume that clients call the service just one time and disconnect. If a secure session is established the message exchange will look like this:
If we do not use secure session we have:
So it is clear that we're better off in the latter case.
With secure sessions there isn't really any trade off and the decision is quite scientific: When only one client request is expected set establishSecurityContext to "false".
Summary Wisely changing WCF defaults can yield a significant improvement in your service performance. The exact changes need to be made and their exact effect are dependent in the scenario. The example above showed how to speed up a certain service 3 times faster.
When you use SSL with WCF or .Net 2.0 web services you might get this exception:
This means that the X.509 certificate that the server presented is not valid according to your client's trust chain. the trust chain is the list of certificate issuers that you trust. In many cases this means you should not trust this web service. In some cases you decide to trust it anyway, due to the fact that you know the author or are still in early testing stages. You have two options:
Option 1 - Make the certificate valid You would need to have the server certificate or its issuer's certificate in the trusted certificates store of your client. This can be done using WinHttpCertCfg.exe or using the "mmc" console.
Option 2 - Configure WCF/.Net 2.0 to not validate the certificate With WCF, a common gotcha is to try and achieve that by setting:
However this will not work with transport level security (SSL) but only with message level security. The correct way to do it is the same one as with .Net 2.0 web services. Just add this code before calling the service:
When you use Visual Studio to add a Service Reference (VS 2008) or a Web Reference (VS 2005) to a web service you do not see the generated proxy immediately. One reason can be that th proxy was not generated due to errors and in this case VS notifies you in the "Error List" pane. If import was successful you can see the generated code by clicking the "Show All Files" option (see images).
Before
After
BTW most of the time you don't really need to look inside the proxy - you can just use it.
Many web services require sending or receiving large files. There is an interesting evolution of attachments standards - however today MTOM is the preferred way to do this. Nevertheless not all SOAP stacks support MTOM and in addition some existing services might already employ older techniques. These techniques may include Soap With Attachments (SwA) or WSI attachment profile (SwaRef) MIME attachments or DIME. I have investigated the attachments support of a few known soap stacks: .Net WSE2 & WSE3, WCF, Axis, Axis2, Metro (WSIT), CXF (XFire), gSOAP, SpringWS and JBossWS. The bellow table summarizes the web service attachments support matrix (click to enlarge):
Note: Some of this information I took from the providers web sites which did not always supplied a nice sheet with the list of supported standards. You are encouraged to correct me if I made a mistake.
The conclusion is as expected: MTOM should be used for new web services; If you know you’ll never have .Net clients then you can also use Soap With Attachments (SwA) or WSI attachment profile (SwaRef) MIME attachments; Beware of DIME if you care for I14Y.
It is sometimes useful to build a WCF CustomBinding equivalent to some other binding. This allows a richer set of customizations. Here is the CustomBinding equivalent to the WSHttpBinding defaults (windows authentication):
Update: Convert bindings automatically using the WCF BindingBox.
The default binding in Wcf 3.0 is WSHttpBinding. Wcf 3.5 brings the new WS2007HttpBinding binding but WSHttpBinding is still the default. These bindings do not interoperate together well due to the fact that WS2007HttpBinding uses some newer standards.
When the client uses WS2007HttpBinding and the server employs WSHttpBinding we may get this exception in the client side:
And the inner exception is:
On the server side trace we see
And the inner exception:
When the client uses WSHttpBinding and the server employs WS2007HttpBinding we would get the same exceptions with http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue being replaced by http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue.
The reason for the errors is the different WS-Trust versions between the bindings. WS-Trust is used when the negotiateServiceCredential or establishSecurityContext settings are set to true (which is the default). In these cases infrastructure messages are exchanged between the client and the server and these messages require the WS-Trust version to match.
We can see the different versions if we use the reflector to check the bindings static constructors.
In WSHttpBinding:
In WS2007HttpBinding:
So, which binding to use? In many cases this does not matter since both bindings expose similar functionality. You might want to consider the following:
WSHttpBinding is supported by .Net 3.0 clients.
WS2007HttpBinding uses WS-* standards while WSHttpBinding uses drafts. You might face a requirement to work with the standard.
Different soap stacks support different standards so if you need to interoperate with a specific framework verify the standards it supports.
In the long run WS2007HttpBinding should be used as it supports the actuall standard.
Nevertheless, for most services this decision will probably only have a very minor effect.
Geospatial and location based services became very popular these days. One concern for developers of such applications is how to represent the data in the system. This includes simple data types such as points or coordinate systems and complex ones such as advanced topologies. The correct approach is of course to use types from the standard schema set of the Open Geospatial Consortium (OGC).
For a .Net developer this may imply the following needs:
Use xsd.exe to generate classes for serizliation
Create .Net 2.0 / WCF web services that utilize these schemas
Consume Wsdl's with these schemas
Unfortunetely the OpenGIS standard schemas are not interoperable with .Net. This has already been noticed by developers for older OpenGIS versions but newer versions seem to be equality incompatible.
If you only want the fix without the details download it here and see in the end of the post the fix details:
Here are some of the errors one gets when trying to consume Gml 3.1.1 and Gml 3.2.1 schemas in .Net:
Gml 3.1.1 - WCF
While using "add service reference" we get this error:
And after this an empty proxy code is generated:
Gml 3.1.1 - .Net 2.0
The wsdl importing stage seems to work fine. Let's build a one line client:
Such a simple client - what can possibly go wrong? Well nothing, except this:
And this is after I have omitted some inner exceptions.
In some cases (depending on .Net 2.0 patch level) the below exception will appear - not much improvement:
Finally, depending in the types we reference, we might get this one as well:
Gml 3.2.1 - WCF
Proxy is generated but the simplest client throws this exception chain:
Gml 3.2.1 - .Net 2.0
Guess what?
Why these errors happen?
The errors appear in run-time when we instantiate the client proxy or web service. At this stage .Net creates the serialization assembly for each type and fails to do it for the proxy. Actually if we have marked the "generate serialization assembly" build option we could already see these errors in compile time.
Now what?
We need to fix the schemas or the proxy in order to make them interoperable with .Net. The fix must be compatible with the original schema, so it may change the schema syntax but must result in an isomorphic schema.
Making Gml 3.2.1 work
There are two reasons for this schema incomparability:
Cyclic schema references
From gml.xsd:
From deprecatedTypes.xsd:
One way to solve this is to remove deprecatedTypes.xsd altogether - it is not really required. We'll be nicer and just replace inside it the reference to gml.xsd with these direct references:
Non-string lists
.Net does not support the xsd:list data type. When the list is of strings it works anyway since unresolved types are treated as strings. But for other types it is not supported. MSDN contains some more information on xsd:list support in .Net.
basicTypes.xsd contains this:
Which becomes this in the .Net proxy:
which causes a run-time error since the XmlTextAttribute is only appropriate on strings.
The solutions is to replace all non-string lists in the schema to strings so the above becomes:
And after this Gml 3.2.1 classes are serializable by .Net!
Making Gml 3.1.1 work
This version has two issues:
Same issue with lists as in 3.2.1 - same fix
I've seen this one a couple of times. Basically when there is a multidimensional array of a type which has a single child element in some cases .Net code generation is incorrect. Don't ask, long story... Just replace in geometryPrimitives.xsd:
With:
And we have 3.1.1 working as well!
Download fix
I have uploaded the fixed schemas to save your time:
After you extract the zip the fixed schemas are in the below folders:
@YaronNaveh
