Today I’ve been spending some time learning how to implement a simple self hosted WCF (Windows Communication Foundation) service. To implement a self hosted one, you need to create a Web Service Library project to create the dll. Then the idea is you can self host the dll either through a console application or service application. I’ve been following along pluralsight’s training course on basic WCF implementations, configuring services with endpoints at 8:37, and I’ve seemed to hit a snag.
I’ve gotten to the point where I’m changing the default port from a debug port (8732 or 8731 in their example) to use port 8080 and my service will not stand up. In addition to that I’m also adding tcp service endpoints as well. When I try to debug the service, I keep getting the following error:
Please try changing the HTTP port to 8732 or running as Administrator.
System.ServiceModel.AddressAccessDeniedException: HTTP could not register URL http://+:8080/evalservice/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details). —> System.Net.HttpListenerException: Access is denied.
So this provided a bit of tricky. I had to take a brief step back and think about how this was implemented. The obvious answer is to use a manifest to inform windows that I’ll need administrator privileges. But in my case I’m using a service library and it’s being hosted by Visual Studio’s WCF Service Host.
I’m not at the point where I have created an application that will host this service library. So how can I get WCF Service Host to run as administrator? Seems in the meantime, I need to run Visual Studio 2010 as Administrator. But what happens when I’m no longer debugging?
At that point I can use the manifest to make sure that hosting application has administrator privileges when it runs outside of Visual Studio
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3"> <!-- UAC Manifest Options If you want to change the Windows User Account Control level replace the requestedExecutionLevel node with one of the following. <requestedExecutionLevel level="asInvoker" uiAccess="false" /> <requestedExecutionLevel level="requireAdministrator" uiAccess="false" /> <requestedExecutionLevel level="highestAvailable" uiAccess="false" /> Specifying requestedExecutionLevel node will disable file and registry virtualization. If you want to utilize File and Registry Virtualization for backward compatibility then delete the requestedExecutionLevel node. --> <requestedExecutionLevel level="requireAdministrator" uiAccess="false" /> </requestedPrivileges> </security> </trustInfo>
Above a snip of the app.manifest that I will need. Note I changed the highlighted line 16 from “asInvoker” to “requireAdministrator”.
So to the best of my research today, it seems that if you want to debug the service library, you’ll have to run Visual Studio 2010 as Administrator. If you’re not needing to debug the internal workings of your service library, then you can “Run” the hosting application by selecting it’s project and pressing CTRL + F5. Then you will be prompted by UAC to run the process as Administrator. It will stay running while you debug the client communicating with the service library.
Hopefully this will be more straight forward in the upcoming Visual Studio 2012. Or maybe I missed something in my research here? Feel free to drop me a line in a comment below to let me know, and I’ll update the post.
As always, hope this helped someone else out there.