AdventureWorks Security and webHttp endpoint behavior
Yes... these are the two devils that kept getting in my way today. I'm going to tell you exactly what I found out about these two things since my fruitless web searches got me nowhere but some poor soul who follows me one day may find this blog post.
AdventureWorks
Everybody knows about the Northwind database but apparently the SQL team didn't like it too much. A few years back they came out with the AdventureWorks database (in several flavors) including a trimmed down AdventureWorksLT database for sample applications. They did a very nice job on the design of this thing and unlike the Northwind database security is clearly in force.
I have never tried to write code with the AdventureWorks database so I tracked down the Codeplex project where you can install the SQL 2005 version of AdventureWorks. Of course if you are installing on SQL 2008 the MSI does everything you need. But if you install on SQL 2005 you must manually attach the database files. Since I'm running on Windows Vista I had to run SQL Server Management Studio Express as Administrator to do this. That worked great but then when I ran Visual Studio or my App I was getting "Access Denied" whenever I tried to connect to the AdventureWorksLT database.
Finally after a great deal of searching I found the "Walkthrough: Installing the AdventureWorks Database". This has good instructions for granting permission to ASP.NET to use the database. I also added my account to all the grant statements as well. That way I can access the DB even when I'm not running VS or my app as Administrator.
Then I had a load of fun writing my first real LINQ to SQL code. Wow - this stuff is fantastic and unlike a lot of our stuff I didn't have to read a book or take a class before I could use it.
<webHttp />
Next week I'm giving a talk on RESTful services at Tech-Ed Israel and I'm frantically working on my demo code. There are a number of pretty simple things in WCF that support this and many of them are clearly documented. However this one little devil, the webHttp endpoint behavior was not one of them. Yes, it is documented here, but every sample and slide deck I looked at neglected to mention this thing.
The samples didn't use config files because they wanted to show the use of the config free WebServiceHost. Great, but I wanted to host my service in IIS so I can't use that (or so I thought until I found Steve Maine's blog post about the WebServiceHostFactory - beware however that the full name changed since Steve's post. In the RTM release it is System.ServiceModel.Activation.WebServiceHostFactory).
I built my service, I decorated the interface with WebGet and UriTemplates but whenever I tried to invoke my service via the RESTful API, nothing. It just didn't work. Normally if WCF detects a configuration that would not be valid it blows you up (as Juval says). In this case I wonder how the webHttpBinding can possibly work but I digress.
As the end of the day was approaching and I was just about to give up, I was reviewing the MySpace guy's implementation of REST Chess and I noticed that little tag in the app.config file.
Wohoo! My service now works with the RESTful URI! Now I can focus on the HttpModule to support URL re-writing tomorrow and get busy playing some games tonight.
Fighting Through It
Some days it seems that it is just one battle after another, the first time to do "x", the first time you do "y". Each new thing is just another obstacle of learning to overcome. Unfortunately the information you need is often just out of reach... but don't give up. Yes, it should be easier to get this stuff done, but in the end that's why you get paid the big bucks.
See you next time...