Feeling rather adventurous this night, I decided to install the Windows Azure SDK and give it a whirl. Whether cloud computing is the direction things will take in the future, or a hopeless flame in a deep valley, we’ll see. Since it’s always a good idea to get a head start on new things, you may find yourself downloading the SDK and wishing to learn more by utilizing the provided samples.
One annoying requirement of, what seems like the whole damn SDK, is that you need to be running SQL Server 2005 or 2008 Express edition. If you have, let’s say, SQL Server 2008 Enterprise or Developer edition running when attempting to build any of these sample services, it will fail, complaining that it couldn’t find the SQL server instance.
The reason for this is because during the creation of the various sample tables required by Azure to do its thing, the devtablegen.exe tool is used, appropriately so. The devtablegen.exe utility has an optional parameter “/server”, which allows you to specify the name of the SQL server. If you do not specify this parameter, it defaults to localhost\SQLExpress. Pretty stupid, Microsoft.
And, you will notice that this parameter is not specified in the build script employed by MSBuild when building the samples. To correct this, navigate to and edit the file: %SamplesDir%\MSBuild\Microsoft.Samples.ServiceHosting.targets.
Find the?DevtableGenForceCreateFlag property. Below it you’ll see the UpdateSamplesTableDB?target element. In this element, find the Exec?element and add /server:YourServerName?to the Command?attribute. Save, and then re-run RunDevStore.cmd.
Should build fine now…why Microsoft would have the default value for the SQL server be localhost\SQLExpress?is really beyond me; very unprofessional…really, why is that a better alternative to just defaulting to (local)?