BizTalk Server 2006 R2 makes it easy to expose WCF services from BizTalk’s messaging or orchestration engines via MSMQ, TCP or HTTP (or custom WCF bindings). For SOAP web services, similar to the old Web Services Publishing Wizard, the WCF Service Publishing Wizard can be used to expose a schema or orchestration as a WCF Web service hosted in IIS. The WCF service’s .svc file, written by the wizard and used by the WCF hosting support in IIS, always points to a common BizTalk WCF assembly (depending on choice of basic or WS-* binding) versus one specific to your BizTalk application.
Since the .svc file for the BizTalk WCF web service is “generic,” BizTalk needs a way to link the WCF Web service, hosted in IIS, to a port and receive location in the BizTalk messaging engine (in a different process). This mapping is based on the service’s relative URL, the part after the domain name (like ‘/MyBTSWCFWebService/MyBTSWCFWebService.svc’). If there is a mismatch in the virtual directory name or SVC file name in IIS vs. the relative URL string entered in the receive location in BizTalk, the two will not make the connection, and you will receive an error when you attempt to connect to the web service. If you try to bring up the service in Internet Explorer, you’ll see an ASP.NET error similar to “Receive location for address “/MyBTSWCFWebService/MyBTSWCFWebService.svc” not found. (The BizTalk receive location may be disabled.)”.
The very important thing to note is that the URL matching is case-sensitive!
Not knowing this may lead to a scenario that can consume most of a day in frustration (trust me on this one). Being unaware that the virtual directory and SVC filename are case-sensitive in BizTalk, let’s say that you create the virtual directory on a new BizTalk workstation with a different case than what is configured in your common port bindings XML file (assuming that you maintain one). After deploying the BizTalk application and attempting to view the service description through Internet Explorer, you find that you receive an error stating that the receive location does not exist or is disabled.
Now, if you somehow realize that you need to correct the case, you go back and delete the virtual directory, recreate it with the correct case, and try to view the service again. Unfortunately, you see the same error again! Careful inspection will reveal that throughout the error page text, some occurrences of the virtual directory name are in the correct case, and others show up in the incorrect case of your original virtual directory name.
I can tell you that no amount of restarting IIS, redeploying the BizTalk application, re-creating the virtual directory, rebooting, or even un-configuring and re-configuring BizTalk will get you past this error! It is really nasty.
As a last hope, we started a mass search of the registry and a complete text search of the entire hard disk — and that finally resulted in the answer: the ASP.NET Temporary Files cache (<windir>Microsoft.NETFrameworkv2.0.50727Temporary ASP.NET Files). Through all of the re-creating, restarting and reinstalling, the same cached files were still being used every time! Blowing away everything in the ASP.NET cache folder solved the problem. My co-worker James ran the hard disk text search and discovered this when he came back the next morning and checked out the search results.
[In case you’re curious, the specific location of the bad vdir name in the cache is Temporary ASP.NET Files<vdirname><random alphanum><random alphanum><svcfilename>.svc.<random alphanum>.compiled.]
Hopefully this will save some of you many, many hours of frustration!
