Code coverage for open source .NET with AppVeyor and Coveralls

Code coverage is a useful metric of the quality of your code. It shows how much code is being covered by unit tests. It doesn’t necessarily mean that the unit tests are well written, but no metric can probably tell you that. However, aiming for a specific code coverage, let’s say 70%, is a good practice, because failing to meet the goal might mean somebody didn’t write enough unit tests.

I’d like to have code coverage as part of the CI I had set up in a previous post with Travis. The bad news is that code coverage and Mono seem to be strangers. There is an open source module called monocov but I couldn’t get it to work. In fact in the homepage it says it’s not maintained. In my opinion, these kind of tools are essential and they should be included in the core Mono package. I hope they change this some day. Continue reading “Code coverage for open source .NET with AppVeyor and Coveralls”

Troubleshooting TypeLoadException in mono

I don’t do a lot of .NET programming these days. At work we deal mostly with JavaScript. However, C# is still the language I’m more fluent in and, also important, a language that I really like. That’s why sometimes I like to code a bit in C# at home. That can be either on Windows or on a Mac with Mono. The problem with Mono is that things can always be a bit different and require some extra effort. Continue reading “Troubleshooting TypeLoadException in mono”

WCF with IIS and multiple http bindings

If you’re writing a WCF service using .NET 3.5 and the service is hosted in IIS, there is a situation where you will get this strange error message:

This collection already contains an address with scheme http.  There can be at most one address per scheme in this collection.
Parameter name: item

This will happen when the web site in IIS has multiple bindings for the http scheme. This is a common scenario for servers that host multiple sites, where different bindings are used to identify the site based on the host header.
If you can’t get rid of the extra bindings in IIS, the following articles provide some insight on how to resolve this issue:

I used these articles to resolve the same problem at work. I managed to solve it with changes to the web.config alone, but I couldn’t get the WCF service to listen to both host headers. So, if my web site listens to both mydomain.com and http://www.mydomain.com, my WCF service can only be accessible from one of these host headers. For that specific problem, the solution was good enough.

Trying to reproduce this configuration at home was impossible. I got different error messages with the same configuration that had done the trick at work. In another article, I read that this behavior of WCF is “by design”, which is enough for me to be just happy that I got it to work in that way and leave it there.

I guess Microsoft realized that this is a much needed feature that should work out of the box and this is how .NET 4.0 works. Supporting multiple bindings in IIS is just a boolean setting:


<serviceHostingEnvironment multipleSiteBindingsEnabled="true">
</serviceHostingEnvironment>

The setting is still false by default, but Visual Studio 2010 will explicitly set it to true in the web.config when creating a new Web Application.

Another good thing is that in .NET 4.0 the error message is more descriptive and helps you resolve the problem:

This collection already contains an address with scheme http.  There can be at most one address per scheme in this collection. If your service is being hosted in IIS you can fix the problem by setting ‘system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled’ to true or specifying ‘system.serviceModel/serviceHostingEnvironment/baseAddressPrefixFilters’.
Parameter name: item

Hope this helps.