Rolling my own .NET 4.5 SDK

All I wanted to do was get my TFS 2012 Build Server going. (Getting the core components running was quite a struggle.) I expected some initial failed builds so wasn't surprised when I was informed of the following:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (983): The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

Finding the .NET 4.5 SDK didn't sound too hard to do. It wasn't, and I learned that it was part of the Windows Software Development Kit (SDK) for Windows 8. I downloaded the indicated file, which was named sdksetup.exe. Its size hinted that unfortunately it wasn't a standalone installer but (ugh) a web installer. I gave the sdksetup.exe a go on the server but wasn't surprised that it failed due to lack of internet connectivity through our proxy server. My next idea was to either extract the files that I needed locally or install and then copy the files to the server, which has worked before.

I missed it the first time around, but the Windows 8 SDK had an option to download the required files for installation to a separate computer see ('.NET Framework 4.5 SDK Tools on Windows Vista and Windows Server 2008' after the jump). This is important because- and I missed this initially as well- "The installer for the Windows SDK for Windows 8 is not supported on Windows Vista and Windows 2008 Server." Well, that's pretty cool that I can create my own installer, I thought, and away I went.

Nothing too exciting initially.

I appreciated being able to deselect all of the stuff I wasn't going to need on a build server.

Ugh. More proxy issues, even locally. Shades of Mordac! I could easily download the .NET 4 redistributable though, so I was still undaunted.

Now things started to get silly. Where was I supposed to find sdk_tools4.msi? Searched Google, other folks were wondering the same thing.

Maybe I already possessed sdk_tools4.msi and didn't know it. Everything proved that theory valid. Hoorah! Now I could build my SDK installer, get the builds rolling, and move on.

It wasn't to be. After browsing to my local copy of sdk_tools4.msi and clicking Retry, the SDK builder process gracefully prematurely ended, mentioning something about 'bad payload' or the like. Sdksetup.exe revealed an important secret at this point: a log file! Mine was located at 'C:\Users\[Username]\AppData\Local\Temp\standalonesdk'. The file was thankfully extremely verbose, and I could see all of the failed web requests for various resources.

For example, when I was prompted to specify the location of netfx45_dtp.cab...

...I searched the contents of the log file for these entries:

[1F08:1CA8][2013-01-24T15:05:16]: Error 0x80070005: Failed to send request to URL: http://download.microsoft.com/download/F/1/3/[long alphanumeric string]/standalonesdk/Redistributable/4.5.50710/netfx45_dtp.cab
[1F08:1CA8][2013-01-24T15:05:16]: Error 0x80070005: Failed to connect to URL: http://download.microsoft.com/download/F/1/3/[long alphanumeric string]/standalonesdk/Redistributable/4.5.50710/netfx45_dtp.cab
[1F08:1CA8][2013-01-24T15:05:16]: Error 0x80070005: Failed to get size and time for URL: http://download.microsoft.com/download/F/1/3/[long alphanumeric string]/standalonesdk/Redistributable/4.5.50710/netfx45_dtp.cab

I then plugged the URL into a browser which then prompted me to download the file. After downloading, I then specified the location of the file in sdksetup.exe and clicked Retry. It took about 10 minutes or so to get all of the files. Not the most elegant of solutions but hopefully this wasn't something that I was going to have to do often.

Finally I was finished. But would it work?

I copied my new .NET 4.5 SDK installer- and supporting files- to my Windows Server 2008 R2 build machine.

So far so good.

Looking promising.

Done!

I then queued a build, which subsequently completed successfully.

Build server and the lost TFS message queue

I couldn't get the TFS 2012 RTM build server running initially. My build controller and associated agents were all stopped. The Event log told me that

Build machine [Machine Name] lost connectivity to message queue tfsmq://buildservicehost-1/.
Reason: Please contact your administrator. There was an error contacting the server.
Technical information (for administrator):
  HTTP code 500: System.ServiceModel.ServiceActivationException

Research yielded some similar scenarios, but the configurations were too different from mine to be considered as viable solutions. Example: my build server wasn't using SSL.

I remembered reading that an update for TFS 2012 was available. Because my TFS 2012 instance is not in production use I thought that I would give the update a shot.

I apologize for the lack of tension and drama in this post, but the update resolved the issue.

Favorite Queries In Visual Studio 2012 Team Explorer

I really need to spend more time exploring Visual Studio 2012's Team Explorer. I just discovered that after adding a query to 'My Favorites' you'll be presented with a helpful summary of the number of Work Items, their State, and the type of query, such as a Flat List or Tree of Work Items.

Here's what it looks like:

After I made this discovery I did some research and found this nice post on many other new Team Explorer features.

Enjoy this ad with my compliments!

MvcBuildViews in a CI environment

This post isn't going to break any new ground in the world of computer science, but I still wanted to say a few words about the importance of using MvcBuildViews in your continuous integration environment.

My team had just finished a quick and slightly dirty ASP.NET MVC 3 project. The three of us rapidly created a very usable internal departmental financial application with two of the members of the team being ASP.NET MVC neophytes. A lot of learning occurred during development, both about the basics of HTTP and client scripting as well as Visual Studio's ASP.NET MVC 3 tooling.

I was finishing off numerous TODO's toward the end of the project when I entered "/p:MvcBuildViews=true" in the MSBuild arguments section of the Team Build process tab. The build crashed immediately due to nonexistent namespace issues. It seems that a family of CRUD Views had been created at some point that used a Model that no longer existed. Apparently the plan had been to go back and clean up dead code, but there was never any follow-up due to other priorities. The dead Views certainly weren't hurting anything. Also, a user could only access them if they somehow typed in the correct URL, a near impossible eventuality. However, I abhor dead code and extra files in a project. It not only distorts the size and complexity of a project but also increases the size of the deployment.

Using MvcBuildViews helped me remove four Views from our final deployment package. That's a trivial amount for large, enterprise projects. However, for a small department application likes ours, that's 20% of the Views. So not only are there now dramatically fewer Views to manage, the steepness of the learning curve for new developers is reduced.