After another week of working with it I’ve come up with a few new pieces of information.
WCF service configurations can now be validated during builds. Unfortunately this seems to currently be limited to the service project itself so clients are still out of luck. Still it is a step in the right direction.
Of more importance is that you can finally disable the service host from starting up whenever you start the debugger. This has been an issue since WCF was introduced. Whenever you start debugging a solution that contains a WCF service project the WCF service host automatically starts up irrelevant of whether you need it or not. You can now disable this in the WCF service project settings. So if you are self-hosting be sure to uncheck this option so you don’t have an extra host running around.
VS2010 and IISX don’t play well together. There is a forum posting on this but MS has never been able to reproduce it or even admit it is a problem. The symptoms for those of us who experienced it are straightforward. After a debug session or two IISX and the debugger stop talking completely. VS locks up and you have to kill IISX before you can recover. This seems to be a deadlock scenario when you are mixing multiple web apps and perhaps WCF services. It makes IISX almost unusable in VS2010.
As of yet I have had no issues with IISX and VS2011. I’m running the exact same code through the site and I’ve yet to lock anything up even after multiple starts and stops. Hopefully this problem is resolved because IISX is the way to go.
Unfortunately an issue just as ugly has popped up. It has been reported on Connect but who knows whether it’ll get replicated and resolved. The problem comes into play with how VS11 loads web projects that use IISX and a specific port. When VS11 attempts to load an IISX project it talks with IISX about hosting the project (not sure how it works) and IISX fails the request. VS then refuses to load the project, dumps an error to the output window and moves on. There are two problems with this. Problem 1 is that the error message tells you to go hand edit the IISX config file to remove the reference to the project using the port. Keep in mind it is the same project. Also keep in mind that VS should be able to fix this up itself. Problem 2 occurs after you’ve resolved problem 1. VS will still fail to load the project because, since IISX was unable to comply VS seems to remove the option of using IISX and just leaves IIS turned on. Hence if you do not have IIS running or you are not an admin then VS cannot talk with IIS to get the necessary metadata. Therefore you also have to edit the project file and change the UseIIS setting for the project back to false. Then you can reload the project, reenable IISX and things should work. Let’s hope MS fixes this before the release.