I spent the past two days playing with setting up TeamCity on Azure. This is just a poc more than anything else, but it’s always fun to do something new. I had to fiddle about with some things that didn’t work as expected, so here are some notes to remember what I did.
I played a bit with StyleCop.Analyzers the other day and I wanted to share what I did. I’ll be showing how to add a stylecop file, how to use the same rules across projects, how to create a custom ruleset file.
In this post we’ll see how to create a .NET Core solution with two projects with using nothing but the command line. Once that is setup, we’ll do a bit of TDD using Visual Studio Code.
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”
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.