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)?

 

The source control solution known as Team Foundation Server truly lives up to its name, as it is a tool that provides a foundation?that allows (and even requires) the intrepid developer to build upon it, so that the complex source control and software management needs of their organization can be met.

The extensibility of Team Foundation is a double-edged sword; although a great deal of things can be accomplished with it, the developer will quickly run into a pretty steep learning curve in regards to how to go about building upon TFS in order to achieve their goals.

There exists an extensive amount of possible programmability with TFS, as one can easily deduce simply by disassembling any of the provided TFS assemblies. Documentation regarding how to go about using these assemblies is scarce on the MSDN, however. To address this, I’m providing this write up as the first in a series of articles regarding how to utilize the Team Foundation API. As version control is the first thing that comes to my mind when I think of the words “Team Foundation”, version control shall be the first topic we’ll?explore.

Continue reading »

© 2012-2013 Matt Weber. All Rights Reserved. Terms of Use.