Configure WCF in IIS for anonymous access

This case may sound strange and I have seen loads of post that describes how to get out of this behavior. But we have a case where we want to allow anonymous access and the let a external component manage the security validation.

This turned out to be very hard to figure out and required some wizard-like skills of Anders Granåker amongst others.

OK – the case is very simple. I have a WCF Service that I want to allow anonymous access to. I don’t care about message and transport security (for now). Just allow anonymous access – I’ll take care of the authorization in code.

Here is what I had to do to get it to work on Windows 2003 R2:

1. Create a account on the server
2. Put that account into the IIS_WPG group
3. Create a virtual directory for my WCF service
4. Create an application in that virtual directory
5. Set the account as Identity on the application pool that the virtual directory is using (DefaultAppPool for example)
6. Set the account as the anonymous account the virtual directory is running under (Directory Security)
7. IISReset to get the settings to take

The last step is a bit interesting… In this time and age you could think that a simple recycling of the application pool would be enough but … no. Do an IISReset to be sure.

Another gotcha that confused us a lot was that when you set an account to be the anonymous account for the virtual directory, you’re prompted to set the password. And retype it to be sure. But that password is not check if it’s the right password! Beware – I locked out our administrator account due to this.

Now it works – and we have a build script that is doing regressions tests via SOAPUI.

Changing endpoint from the command line when testing services with SOAPUi

I have been singing SOAPUi’s praises lately and it’s really great for testing services. In this post I describe how I made the whole thing work for testing WCF Services.
But, as stated in this post, there was still one more thing to be solved… The endpoints from the command line. You want to use different endpoints in different environments. And in my specific customer case I want one of them to stay the same all of the time, since that endpoint points (sorry, could not resist myself) to a “singleton” kind of service.
Luckily the SOAPUi team also have some great support (Thanks Ole, who replied in Swedish!). So here you have it – how to change the endpoint for one of your services under test from the command line – which in my case means the build script.

1. I first created a sample WCF service project (very vanilla, i didn’t touch the code just the default generated code).
   By the way; really cool hosting and test client stuff in Visual Studio 2010
2. I changed the binding to basicHttpBinding since that’s the only thing that work with SOAPUi. I used the WCF Service Configuration tool in Visual Studio of course.
3. I then created a normal SOAPUi project and let SOAPUi create testcases for me. I added asserts just to make sure that the I didn’t get an error back.
4. I started my service and ran the testcases – It worked!
5. I then, and here is the trick, created a project-wide property (Click project file and chose Custom properties in the lower part of the project window) to hold the endpoint value.
   
   1. I named the project wide property DemoServiceEndpoint
   2. I gave it the address of the service I was testing as value
6. I then opened the tree down to the test request in question and then chose the Test Property-tab in the lower part of the project tree
7. Here I entered this expression that reads the value from my project wide property:
       ${#Project#DemoServiceEndpoint}
8. I repeated for my other test request and tested. It still worked!
9. OK – we’re closing in now. Now I used the Test Runner to create my command (nifty stuff SOAPUi dudes!). Here I got the opportunity to set my parameter ${#Project#DemoServiceEndpoint}.
10. After some tweaking I managed to “harvest” the command into a .bat-file.
    
    

    "C:\Program Files (x86)\eviware\soapUI-3.5\bin\testrunner.bat" -sDemoTestSuite -PDemoServiceEndpoint=http://localhost:8732/Design_Time_Addresses/Marcusoft.SOAPUiDemo.WCFService/Service1/ C:\Dev\Marcusoft.SOAPUiDemo\EndPointOverrideDemo-soapui-project.xml 

    
    
11. And it worked!

So now I can change the endpoint from the command line! In my build script when I have deployed the service to the testing environment for example! Yeah!

You can download my example here.

SOAPUi and MSBuild

After my last post I cannot withhold you from this nugget. It’s a guy (Todd) that have created some MSBuild targets to call SOAPUi from a build script.
I am about to try it out… I’ll get back to you if I run into problems.

[UPDATED]
Yup - it worked! Great! Thanks Todd.

Still have some issues in that the switch /endpoint will override all the endpoints in the SOAPUi project... But I'm on it...

[UPDATED AGAIN]

See this on how to solve the endpoint problem.

SOAPUi and testing WCF Services – how I made it work

I have already blogged about SOAPUi but then it was more me thinking and seeing it was a good idea to use SOAPUi to do testing of service.

Now I have actually done this – and I love it so far. In the last project where we our deliverable was a service I think we spent about 30% of our time creating and maintaining the test client.

Not to speak about all the time we had to spend explaining for the client that “no this is NOT the GUI you will see later on”.

So the thought of a general test client for SOAP services is very compelling. And SOAPUi has done a great job making your job easy and fun… Almost all of the time.

They have an amazing amount of documentation. I guarantee that everything I am about to tell you is in there somewhere… This is my short story for our case.

So the case is as follows – I have a quite simple WCF service. One trick is that we need to call a common security service (let’s call it SECI) to get a token that we have pass into our operations.

We have worked contract first and started with a WSDL-file. I used WSCF.blue (great tool) to generate the service stub. And then…

• I downloaded SOAPUi. Go on - do it now- it’s free!
• I created a new project by pointing the wizard to my WSDL-file. I also asked the tool to create a starter testcase for me.
  Beware of the location or endpoint address – it’s read from the WSDL-file and most likely you will need to change that to your computer or the server where your service is deployed.
• I then added a new WSDL to the SECI service to the project. This is needed to be able to call

I was now ready to create my test case with the test steps I need to call the SECI service and insert the token into the request I wanted to test.

• First I created some parameters for my test suite. This is actually hidden away a bit.
• Open the test suite editor by right clicking it and chose “Show TestSuite Editor”
• In the lower section of the editor you’ll find a “tab” that is named Properties
• Here you can add properties that will be visible for the whole test suite
• I added some inparameters to the SECI service and the token I will pass on
• I then called the SECI service, passing it values from the parameters I created in the earlier step.
• To get the values from the response of the SECI service into the request to my service I used a Property Transfer. In it I transferred the value of the token node into a variable that holds the property for the token.
  It’s a quite deep structure with dropdown boxes and namespaces in the UI here but it’s not to hard to understand.
• Finally I could easily insert the value of the token variable into my request, as before.

It wasn’t to hard after I got understanding about the variables for the testsuite. I sure beats having to code your test client manually…

Great work SOAPUi!

ÖreDev day #3 – afternoon

The fallacy of efficiency

Dan North – given a talk on not believing in efficiency (the theme of the conference) ;).

What he is aiming at is the difference in efficiency (the effort we burnt so far) and effectiveness (the outcome is what’s important, not how much we burnt so far).

OK – this is great! He is dropping gold ever ten seconds. I just hope to get hold of the slides, and try to post them here. I cannot possible summarize it here… It’s boarder-lining on politics but I like it.

Dan North – check him out. He’s great and quite funny also.

OK – best so far! By far!

Explorations of NHibernate

This will be another talk by Stephen Bohlen, the speedtalker… So I don’t expect to be able to write to much during this.

We’re learning about add-ons (etc.) to NHibernate.

Here are some nuggets that I managed to throw down:

• Rhino Tools
• uNhAddins
• NHibernate Validator (hey, first hit on Google to Torkel). Here’s it using a fluent interface
• NHLambdaExtensions
• NHibernate Burrow – business transactions (without hitting the database)
• Fluent NHibernate, which I praised already
• NHProfiler
• and finally HornGet.NET

This was great but oh so fast, I’m short of breath…

Productive WCF

Going into the last part of the day and I am beginning to feel tired…

OK – Juval Löwy is up now and I expect some pretty advanced stuff.

Yep – I will be some not so well-know productiveness things in WCF. Another list:

• WCFServiceHost a generic WCF host supplied with Visual Studio. Works great when debugging.
• And a generic test client, WCFTestClient. And this can be combined together. Great stuff!
• Instrumentation for WCF can be applied with <diagnostics performanceCounters=”all” />
• I already knew about the WCF Service Configuration Editor in Visual Studio, but it’s a secret for many.
• But I didn’t know about Microsoft Service Trace Viewer
• InProcFactory looks cool – you can actually create a WCF-service from any .NET-class, on the fly.

Another great session. I’m running out of batteries now. Not sure if I can document the last session… Maybe – I’ll publish now, just for sure.

Accessing Data in the Azure Cloud

Julia Lernman based her talk on the frustration on not understanding how to use it, from a developer perspective. Suits me just fine – I’ll learn all the cloud religion later… :)

This seems to be a great but basic talk. I’ll leave it and try to grasp it. I am a beginner on this…

Custom tool warning: cannot import wsdl:portType

I chased this bug for a while - more and more frustrated... This was what happened: I updated a WCF Service Reference and got this error (or actually warning) in the Error List of Visual Studio. Also I saw that the Reference.vb was totally empty.

OK - after some trying of my own (why do I do that over and over? Don't think - steal from others...) I though of searching the Net and of course found the answer in five seconds.

Here is a guy that solved it - but the header and description of the post is quite different so I'll try to give my own explanation here.

In the Configure Service Reference... dialog box there is an option "Reuse types in referenced assemblies". Exactly what that means is hard to grasp (just try for yourselves) - but I understand it as the tool tries to download the assemblies that the service is referencing.

The solution, however, don't have much to do with understanding that (if you don't want to) - simply clear that box and regenerate. It works!

WCF with handcrafted WSDL generated no FaultExceptions<T>

This is problem that has haunted us for the good part of the autumn and winter;

early on in our design process we chose to create the WSDL for our services by hand. This decision mainly had to do with that you can express stuff in XSD that WCF-attributes doesn't support, such as string length etc.

Also we were using the ErrorHandlerAttribute found in the excellent book "Programming WCF Services" by Juwal Löwy.

What we saw was that even though we had created the wsdl for handling the fault and their details correct, we didn't get the details over to the client (that is the T of FaultException<T>). We checked the wsdl and the generated client proxy (and it's wsdl) file over and over, and line by line but just couldn't find it.

And finally it dawned on us... It was Mr Löwy's fault ;). Seriously - it was the use of the ErrorHandlerAttribute that caused the problem. The WSDL was correct all along.

The ErrorHandlerAttribute operates on the message level which I understand as; it actually generates the SOAP-message/XML that is returned to the client. Since that SOAP-message wasn't specified in our WSDL we got this problem.

That was really a long way around to get some details back, but I hope and think that it was worth it. At least we learned some interesting stuff about how the WCF inner workings works.

AddressFilter mismatch at the EndpointDispatcher

The complete error message was: "The message with To '[my service address]' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher."

We got this message when we deployed our services to the production environment. In this environment we first encounter BIG-IP and clustering. And that's when we hit this brick wall.

The scenario was that BIG-IP had one DNS-name/Ip-address that "forwarded" request to two different servers. However when we accessed the servers with wsHttpBinding we ran into trouble and the above mentioned error message.

The strange thing was that it worked fine with basicHttpBinding, which puzzled us for a while.

Well, thanks to the excellent knowledge in the Avega Microsoft community, we got an answerer in matter of minutes.

As this post points out you can handle the problem by setting the AddressFilterMode to Any, which basic means - ignore addressfiltering.

As far as I understand WCF matches the address property for the client and the server and if it doesn't match (according to AddressFilterMode) the above mentioned error message is thrown.

And for the strange behavior that basicHttpBinding worked it must have to do with that basicHttpBinding doesn't care about that kind of matching. I believe that it has to do with WS-Addressing and that is not a part of basicHttpBinding.

I love to be challenged about this - this is just what we figured out in the project.

Thanks to all that helped us solve this.

WCF Self-hosting and configuration

One of the really cool features of WCF is the possibility to be able to change binding in the config... Of course the transport need to be supported by the host. For example you can't use TCP/IP transport in a web-site hosted service.

So - you'll have to create the host by yourself - selfhosting. However there are some nasty configuration to be done in order to get the service to work. Otherwise you'll get this error message:

HTTP could not register URL http://+:[yourport]

Here is an article from Microsoft describing how to get it to work. And here is another article describing how to solve it

WCF Config: How to configure wsHttpBinding for no security

Yes - I know that this is quite rare but if you want something really easy in place then this is how to use wsHttpBinding with no security:

<service name="FaktureringsTjanst"
        <endpoint address=""
binding="wsHttpBinding"
bindingConfiguration="myBindingConfigurationWsHttp"
contract="IContract"
behaviorConfiguration="FaktureringsTjanstBehavior" />
      </service>
    </services>

    <!-- Bindings -->
    <bindings>
      <wsHttpBinding>
        <binding name="myBindingConfigurationWsHttp"
maxReceivedMessageSize="500000"
sendTimeout="00:05:00"
receiveTimeout="00:05:00">
          <security mode="None">
            <message clientCredentialType="None" />
          </security>
        </binding>
      </wsHttpBinding>
    </bindings>

Full speed and free

My situation right now is quite strange for me. The project I am involved in at work is really running full speed ahead - with my largest Scrum-team so far, 9 people - and at the same time I have some days a week off.

This has to do with a great Swedish invention called parenthood leave (my translation). When you think about it, it's actually quite amazing - I get a lot of days from the government to be with my child. Sweden is fantastic.

The hard part for me is to switch on and off since I am not a work a day a week (or so) I still have my mind on ODP.NET, WCF and Aspects. But hey - I might learn.

Today me and Abbe have been on a really long walk around some beautiful archipelago right in the middle of Stockholm. That was great! And more of those days are coming. I'll be sure to bring my camera for the subsequent "tours".

Cool WCF-utilis

From the last post I found a new URL for code stuff from MSDN that I never heard about before. But this place is golden, golden I tell you.

Here are two small nuggets that I found in my first try:

• http://code.msdn.microsoft.com/FileTransportChannel
• http://code.msdn.microsoft.com/WCFExtras - that contain, among other things, an implementation to get WSDL in a single file (that Christian Weyer does here)

Validating WCF-messages with WSDL

When you first think about it, it's quite strange that no validation, takes place out-of-the-box ,against the WSDL that describes a service (asmx or WCF). Then you (read: I) forget it and all of a sudden you don't think that much about it; the generated proxy or services code doesn't contain logic. Period.

It's even more so when you only create services that is generating WSDL when asked. BUT (and it's a big but ;)) - when you start doing Contract First you are actually specifying the WSDL first and then generate the code... then the question arises again.

I mean you're specifying things in the WSDL that doesn't get generated into the code. Things like format, lengths and stuff like that. It's a bit strange that it's lost. And the best scenario is that it's simply validated when the request is received.

Lo and behold - here is mr Skonnard with a brilliant solution. Here are some other articles brushing on the same subject.

Thanks to Fredrik for finding this, especially since I serious doubted that it could be done. We are trying to implement it now - I'll get back to you with our experience in a while.

WCF, WSDL and differences from web services

I'm back after a four week vacation (oh yeah - us Swedes really has things going for us). More about the vacation later.
First thing to learn this "season" is that the WSDL generated by WCF (Windows Communication Foundation) services differs from the one generated with ASMX web services.

The main difference is that the WSDL is generated with some kind of virtual links. That is; parts of the WSDL-file is retrieved using a different URL. For example:
schemaLocation="http://localhost:3236/Bokforing.svc?xsd=xsd0

This seems to be working fine in Visual Studio 2008 (and hopefully in 2005 also), since they are capable of navigating such references. But there are problems when you want to send the WSDL-file to someone as an attachment, or in other environment that can't navigate such links.

Fortunally Christian Weyer has a suggestion on how to solve this. There are also some other very useful stuff in there on how to use namespace correctly in the attributes of WCF.

Since I am forced to use VB.NET I translated the code using this excellent tool found at Developer Fusion

It is quite tricky but can all be done with base-classes so that not every developer in the team needs to worry about it...

Two gotchas appeared for me;

1. The @ServiceHost Factory is a bit strange since is doesn't show up in intellisense. It works quite fine though. Read more about it here, and here.
2. The loop found in the private method
   RemoveXsdImports was quite tricky to translate into VB.NET since its using a kind of looping that not is supported by VB.NET. Also the Developer Fusion tool didn't translate it correct.
   Here is the code:
   
   
   Private Sub RemoveXsdImports(ByVal schema As XmlSchema)
   Dim i As Integer = 0
   While i <>

WCF Data Contract Versioning

I've been checking out a very interesting subject for my current project; WCF contract (and services) versioning.

The support for this is so much better in Windows Communication Foundation (WCF) than for mere web services, that going to WCF could be worth the effort based on that parameter alone.

Here are some good tutorials, best practices and intros to the subject:

• Service versioning from Microsoft
• Best Practices: Data Contract versioning, also Microsoft
• Short but good article on the subject by Das Blonde, aka That Indigo Girl, aka Michele Leroux Bustamante
• Forward-Compatible Data Contracts

Well, that should get you started to handling versioning of your WCF contracts and services.

Web Service Factory

Following a tip from Robban I've been checking out the Web Service Factory tool from Microsofts Patterns and Practices gang.

Robban and I were discussing the use of Contract First design in an upcoming project and I was interested to see if there were any good tools out there.

Well as it turns out there are good tools... but the one that seemed to be most complete was the Web Service Factory (horrendous name, by the way...). Also for us Microsoft-coders the PoP-gang is well-known and often delivers with great quality.

I have now been checking it out and it is good. Here is some of the stuff I've been checking out

• The home of Web Service Factory (and the Codeplex home)
• Introduction
• A video showing off some features

I am not yet convinced that we will go this way (the completeness is maybe too great fiddling with servers etc.) but it sure looks good.

How to get equivalent proxy-classes to implement a shared interface

After reading the great patterns book i was talking about earlier i soon ran into a problem that at first seemed pattern-like but was not after some examination.

The case that we are integrating against a back end AS400 system, via Microsoft Transaction Integrator. The "problem" is that the department that is responsible for the integration is creating a web service for each program ("method") we are accessing. I brushed on this in an earlier post about naming those web services.

A lot of the stuff we are sending back and forth are equivalent but not the same, for example an header that all methods expect. They are equivalent but not the same since they are located in different namespaces, since the header are generated once for each web service.

So what we wanted was to create an interface that all the headers could implement. To create the interface was not hard. I simply made an interface that declared all the properties of the header. I called the interface... IHeader (duh!)

But to get all the generated header classes to implement IHeader was another thing altogether. Luckily the generated classes of the proxy are partial classes. So we created another partial class with the same name, in the same namespace. That partial class implemented our new interface.

Now we just had on big obstacle to get over; implementing the interface. Implementing interfaces in VB.NET is explicit. That mean that we explicitly had to code the call the underlying implementation, in our partial class, to get the whole thing to work. We are counting on ca 40-50 methods and web service so that would be all lot of dumb code.

Even more stupid is that all the code already is "implemented" since we know that all our header classes has the properties declared by the interface. So we had to do the whole thing in C#, which supports implicit interface implementation (whoa - fancy phase alert). So nice!

The whole thing collapses to a single line of code (excluding namespacestuff). Here is an example:

namespace LF.Tjanster.Sak.DataAccess.TI.Migg.ListData.HamtaVerksamheter
{
    public partial class WS_Migg_Header : IHeader { }
}

I don't know if this is a pattern but is sure is nice. By using partial classes and implicit interface implementation (again? I'll switch to writing books soon...) we solved a quite hard problem in a very nice way.

Now we can treat the headers uniformly by passing an interface instead of an implementation ("Classes are dead. Long live interfaces").

And we'll probably use the same trick for exception handling, and logging, and ...

WCF - wsdl configurations explained

OK - after an intensive coding session i can now proudly say that I understand 4 attributes of the WCF configurations (of the 1200 + that exists ;))

The attributes that you should set are:

• ServiceBehavior.Namespace - this get generated as the targetNamepace in the wsdl (instead of http://tempuri.org/). Also you should use this namespace in the endpoint, with the bindingNamespace-attribute in the config-file:
  <endpoint bindingNamespace="http://www.marcusoft.net/Services/" />


• ServiceBehavior.ConfigurationName - this is the name that you use as service name in the configuration file:
  <service name="OffertTjanst" >
  
• ServiceBehavior.Name - the name property has solely to do with the generated wsdl-file. It is generated as the Name-attribute in the wsdl-file:
  <wsdl:definitions name="ListDataTjanst" ...
  
• ServiceContract.ConfigurationName - (note: this is on the interface, service contract, all other attributes are on the service implementation) this name is used to reference the interface in the endpoint:
  <endpoint address="..." binding="..." contract="OffertContract" />

As i said at the start. These are the configurations i think are important - and the ones i feel really comfortable with... up to now.

WCF, WSDL and tempuri.org

It's back! Just when we thought that we've seen the dreadful namespace http://tempuri.org is coming back at us with full power.

The feeling you get when a web service is exposed under the namespace tempuri.org is that the developer of that web service is either sloppy or don't now what he is doing.

Well, well - don't be like that when it comes to using WCF. Here is an article describing how to do it. The key points are quite easy:

• Use the ServiceBehavior attribute. Note: on the service implementation - not on the contract!
• Set the namespace-property to the namespace you want.

Here is an example (yes, i know, it's in dredded VB.NET):

<ServiceBehavior(Namespace:="http://www.marcusoft.net/Services/2008/04/MyService", )> _
Public Class MyServiceImplementation
implements IService
...
End Class

WCF configuration or Do it yourself

Configuration of WCF-services is a vast area... anyone who looked into the subject are sure to agree on that. The whole idea with WCF-services is that you can via configuration tweak the behavior and appearance of a service without having to change any internal logic of the service.

When I tried my first services I was "tricked" into choosing one of the pre-manufactured project templates that Microsoft ships with Visual Studio 2008. This was bad decision. The number of configuration properties and stuff generated for me was so great that I didn't understand the true important stuff that I needed to know.

However, this Tuesday we had a interesting visitor at Avega - Christan Weyer. He gave an introduction on WCF. From that lecture I got so much more than from what the templates showed me.

So this is what you really need to configure on your service:

• Name - the name of the service
• Endpoint
  • Address - where to reach your service
  • Binding - how to reach your service (protocol)
  • Contract - the contract definition of the service

Here is an example:
<system.serviceModel>
<services>
  <service name="Tjanster.ListDataTjanst">
   <endpoint
      address=""
      binding="wsHttpBinding"            
      contract="Tjanster.Contracts.IListData" 
   />
  </service>
</services>
</system.serviceModel>

That's it! A bit more easy to read and understand the 50+ attributes that Visual Studio generates for you.

On the client it gets even worse with the number of attributes that Visual Studio generates. The only things you need to do is to configure the endpoint you're using. Like this:

<system.serviceModel>
<client>
   <endpoint
     address="http://localhost:3214/ListData.svc"
     binding="wsHttpBinding"
     contract="svcListData.ListDataTjanst"
   />
</client>
</system.serviceModel>

I am working on some details for how ConfigurationName, Name and Namespace relates to all this but I'll get back to that when i know how it works...