Learning WCF - Port contention issues during debugging

When working through exercises from the MSPress book on WCF for .NET 3.5 and from Bustamente's "Learning WCF" I ran into an issue when "self-hosting" WCF services in a console application.

One self-hosting example featured a solution with two projects:  1) a WCF service ("library") project and 2) a console app used to host the WCF service in the library project.   Each had an "app.config" file in it indicating that it wanted to use port 8080 under the local host URL:

... snip ...  <host> <baseAddresses> <add baseAddress="http://localhost:8080/NetStarCommandService" /> </baseAddresses> </host> ... snip ...

The solution built fine but when trying to run it presented this error message:

"HTTP could not register URL http://+:8080/NetStarCommandService/.  Another application has already registered this URL with HTTP.SYS"

If I changed the port number in either of the app.config files the code would run fine.

The problem turns out to be with a Visual Studio 2010 feature I was unaware of.  When you start a solution which has a WCF service in it Visual Studio will quietly start the WCF hosting service for the WCF service before running the code in the solution -- this causes the library project and the WCF hosting service to grab the port first and then prevent the self-hosting console code from running on that port.

The solution is very simple:  Right-click the WCF service project (the "library" project) in the solution, bring up its properties, and take a look at the "WCF Options" tab on the properties screen.  Uncheck the "Start WCF host when debugging another project in the same solution" checkbox and the project should run correctly.

Getting started with WCF - A Security Issue

Most of the free documentation I've been reading on WCF starts with a first "Hello World" application you try and create with WCF wherein you set up a contract, service, and host and then develop a client to call that host which returns a simple text string (e.g., "Hello WCF").

Most of this free documentation came out when WCF was first introduced, before the introduction of the Vista OS and Windows 7, and implicitly assumes that you're coding under credentials with admin rights on your machine.

The first roadblock I ran into, then, was a security access violation with an error message that read like:

"HTTP could not register URL http://+:800/.  Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkID=70353 for details).

Having run into this sort of issue before my immediate response was to try running the binaries under my machine's sysadmin account, but it still didn't work.

It turns out that listening on an HTTP port is considered a restricted operation in MS post-XP OS's, so if you want to do this using your standard dev account you'll need to explicitly elevate its rights to include listening on specific HTTP ports.  The NETSH command to do this for me was:

netsh http add urlacl url=http://+:8000/user=graperpc\dgraper

You can then check the current status of listening rights by entering:

netsh http show urlacl

Extremely slow response with a VS2010 solution

I copied a solution from my dev environment into a production environment and noted an extreme decrease in responsiveness ... e.g., a five second delay between a keypress and its appearing on the screen; 30 seconds plus to go from designer view to code view, etc.

The solution was pretty simple (although it destroys all my breakpoints) -- delete the SUO file for the project so that VS2010 has to build a new one.  Once that was done, performance was normal.

Converting everything in a file to lowercase with GVIM

To do it as a "replace":

:%s/[A-Z]/\L&/g

The obverse (to convert all to uppercase):

:%s/[A-Z]/\U&/g

Or, simply type:

ggVGu

Error 1001. The specified service has been marked for deletion

During windows services development there are periods during the final deployment process where I'm installing and uninstalling services pretty rapidly on a server and I occasionally run into this message: "Error 1001. The specified service has been marked for deletion." This error message will cancel the installation and, if you Google around for cures to this problem, the general consensus is to reboot the system.

The systems I work on require extensive permissions from a lot of people/departments to reboot, bringing development to a halt, so I found an easier way to get around the problem. It turns out that the error message is actually complaining that "services.msc" is currently open (in my case, I've left the server manager app open to list current service statuses), so stopping this process (again in my case, simply closing server manager) allows the service to be installed.

Glitch in setting up a setup-deployment project for 64-bit apps in Visual Studio 2010

I have a windows service that was originally developed for 32-bit machines that I converted to 64-bit. The original setup/deployment project would not compile properly, though, and I would get this error message when attempting a build under Visual Studio 2010:

"File '64bitWindowsService.exe' of project output 'Primary output from 64bitWindowsService (Active)' targeting 'AMD64' is not compatible with the project's target platform 'x86'"

Getting past this problem was easy: Examine the properties of the setup project and change its "TargetPlatform" setting from 'x86' to 'x64'"

The setup/deployment project would then build OK but when I would try and do an install thru Visual Studio (by right-clicking on the project and selecting 'Install') I'd get another error message:

Error 1001: Exception occurred while initializing the installation: System.BadImageFormatException: Could not load file or assembly 'file:///C:\Program Files\Microsoft\Setup1\64bitWindowsService.exe' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Here the solution came from resetting the "Platform Target" of the windows service from "x64" to "Any CPU" (right click the windows service project, select "Properties", and click on the "Build" tab). Once that is set it seems to build and install OK.

Removing a Visual Studio 2010 solution from TFS source control

A Google search on this brought up a lot of intimidating-looking solutions requiring text-editing the ".sln" file, but a simpler and easier solution was available in the VS2010 interface itself.

- Select the solution in the Solution Explorer
- Click on the "File" menu item
- Click on "Source Control"
- Click on "Change Source Control"

Select the solution from the datagrid, then click on "Unbind"