So I tried the new virtual machines on Azure for Visual Studio. I’ve always dreamed of using a vm to do my development on, but never really trusted it because Visual Studio (VS) is such a performance hog. Well, here are my results. I downloaded “ImageResizer” from Codeplex, a popular C# program, and then built it on my local machine and the Visual Studio VM. My local machine runs 64-bit Win 8.1 Pro with a Intel i5 4670K CPU @ 3.4 GHz and 8 GB of RAM. It is also on VS Ultimate 2012. The Azure VM has a AMD Opteron Processor 4171 HE at 2.10 GHz and 3.5 GB of RAM on 64-bit Windows Server 2012 R2 Datacenter. It is running VS Pro 14 CTP (the latest and greatest).

Now, the results.

My local machine built it in ~1.1 seconds.

The VM built it in ~3.1 seconds.

A factor of 3. Not great, but not that bad either. I could see myself doing it, maybe…. lots of advantages (clean machine, always running the latest and greatest, etc.). But it still feels like it’s on the cusp of prime time.

So you’re using .vdproj setup projects are you? And you want to automate them with TFS 2010? Well, you’re in the right place, although I would recommend you start moving those setup projects to a msdeploy solution.

First, to automate the building of .vdproj project, you’re going to need to write your own msbuild file because they are not in msbuild format and therefore TFS Build does not know what to do with them. I found some good examples on the net on how to do this, but I updated mine a little for 2010. Here it is:

After you’ve done that save the msbuild file as, for example, AutomatedSetupBuild.proj and add it to source control at the same level as the solution file you intend to build. Then select it when you are creating your build definition.

One last thing on drops. If you intend to create a drop, there is a twist. TFS Build usually overwrites the “OutputPath” property in msbuild files to the “Binaries” folder on the build agent at build time. Since the “OutputPath” property does not apply here, you will need to overwrite it in the .vdproj file. Simply open the .vdproj file in a text editor and find the word “Release”. Change the “OutputFilename” to “..\\..\\..\\Binaries\\*.msi”. My .vdproj file had an “8:” prefixing the path which I simply left.

So, you have some old .Net 1.1 apps that you don’t want to upgrade, BUT you want to use TFS 2010 for your source control. Well you are in for a treat! (kidding)

First, you’re condemned to using VS 2003, because VS 2005, 2008, and 2010 only deal with .Net 2.0 and higher.

Second, because of this, you’re condemned to using the TFS 2010 MSSCCI provider; which is a not very well documented, unsupported by MS free tool. 🙂 (Have fun)

This guy has a great post with screenshots to lead you through the gauntlet!

Third, heaven help you if you’re migrating your source from another source control provider like SourceSafe or PVCS. You’ll need to unbind the code from the old source ccontrol provider and then re-bind it to TFS 2010. A treachous course that shouldn’t be taken lightly.

Error: The property ‘value’ located at ‘/webServer60/metaKey[@path=’/LM/W3SVC’]/metaProperty’ is marked as secure. You must specify an encryption password to archive this property.

Since this was a production server setup by someone else, I thought that I had to get the password from them. NOPE!!! After an hour of scouring the web to see how even to set this password in IIS 6; a colleague pointed out that it needs the password to encrypt the metabase properties going into the package!!!!

So I could set any password!!! Just have to remember it when I go to deploy that package somewhere else.

Type sn -v NameOfAssembly.dll at the command line. It will say “NameOfAssembly.dll is valid” if it is strongly named. It will say “NameOfAssemby.dll does not represent a strongly named assembly” if it is not.