There and Back Again : Visual Studio Team System

Looking for cool VSTS tools

hdierking — Thu, 19 Jun 2008 02:33:08 GMT

My friend and Team System MVP, Mike Azocar, is running a contest to find the coolest community-built tools for Team System. To enter, just submit a screencast that showcases your Team System tool. You've got until August 31, 2008 to get your entry in, so get crackin!

More information can be found here on Mike's blog.

The Visual Studio Gallery

hdierking — Fri, 29 Feb 2008 04:23:37 GMT

Once upon a time (ok, fine - 2 weeks ago), I was doing some Ruby development in Notepad and just had a craving for more. Don't get me wrong - I love the raw performance of Notepad, but between Visual Studio (with R#) and Eclipse, I just had a need for something more aesthetically pleasing. One thing that I've always loved about the Eclipse side of the universe is that if I'm ever in need of a new plug in, I can simply go to the Plugin Central portal and browse through hundreds of different plugins, from language tools to modeling tools. As I was hoping, I came across a fantastic plugin for Ruby development.

If you hadn't noticed yet, we have now launched a similar one-stop-shop for Visual Studio add-ins - the Visual Studio Gallery.

One of the things that I found particularly interesting about the Visual Studio Gallery is in how you can source Visual Studio add-ins from a variety of different sources, from CodePlex to the new MSDN Code Gallery portal (if you just want to surface the code and not binaries), to your own hosting provider. The particular combination of this with something like CodePlex strikes me as particularly cool.

So Mad Right Now

hdierking — Thu, 04 Oct 2007 05:24:38 GMT

All I want to do is install VS 2008 - that's all. Unfortunately, the uninstall story with VS 2005 is so complicated that in the process of individually uninstalling the 10+ different applications (according to MSI), I have somehow also corrupted my LifeCam software, so now I'm unable to webcam with my wife and new baby while traveling.

Maybe I had never noticed before because I was a full-time developer and I was in a constant state of reformatting my machine anyway, but seriously - is formatting the only viable option for installing Visual Studio?

At the moment, it certainly seems that way...

Error Installing VS.NET 2005 SP1? 0x643 Ring a Bell?

hdierking — Sun, 27 May 2007 07:06:08 GMT

I have run across this error now in a couple of VPCs - and I finally cared enough to search out the problem today. The error occurs when trying to install Visual Studio 2005 SP1 - as far as I know, the error is not limited to a specific edition of the product. The installation will get to about 50% completion and then throw an error with an error code 0x643. In doing a little digging, it seems that the solution is to update your software restriction policies as follows. This information was pulled from this KB article.

Click Start, click Run, type control admintools, and then click OK.
Double-click Local Security Policy.
Click Software Restriction Policies.
Note If no software restrictions are listed, right-click Software Restriction Policies, and then click Create New Policy.
Under Object Type, double-click Enforcement.
Click All users except local administrators, and then click OK.
Restart the computer.

Not sure if you've run into this problem yet, but if I've seen it more than once, so I'm fairly certain that you either have seen it or will see it in the future.

DSLs - Not Quite Child's Play ... But Closer!

hdierking — Wed, 16 May 2007 20:53:33 GMT

One of the books I've been reading recently Jack Greenfield's (and several other really smart people) book Software Factories. While I'm not yet sure that I buy into the notion that the creation of software solutions will undergo an industrial revolution of sorts (at least in a measurable timeframe), the thing that really drove me to this book was the discussion on domain specific languages - or "little languages" if you're coming from the UNIX world. I've been following the efforts on DSL coming out of companies such as Microsoft, JetBrains, and Intentional Software for a while now and while I think that model driven architecture is probably too prescriptive as an approach, I do think that there is a great deal of business value to be gained by promoting language oriented programming.

While Jack's book is incredibly insightful, it also (at least for me) can be a pretty difficult read as it takes me back to my old CS days. In fact, much of the work on DSLs reads this way as we are just now starting to try and describe and articulate the theory behind the tools. Therefore, I think it's always fun to see a practical implementation of a "little language".

The Scratch language is a visual programming language for kids developed by Mitchel Resnick and team at MIT's Media Lab. The language allows kids to build software systems that do some very basic - but very real things. What's cool is to think about the next step - when we come to a better understanding of integrating different DSLs to create richer systems. As an example, taking a Scratch application and integrating it into a distribution language would be an easy leap for allowing kids to create simple games that they can immediately promote to the Internet to play with other kids all over the world!

Microsoft Acquires TeamPlain – Free to TFS Customers!

hdierking — Tue, 27 Mar 2007 21:18:12 GMT

This is a really awesome deal for current Microsoft Team Foundation Server customers. Check out the entry on Rob Caron's blog for more information.

Stop the Presses – TFS Exam!

hdierking — Thu, 01 Mar 2007 00:43:59 GMT

Saw some nice coverage the other day regarding the Team Foundation Server exam (70-510) – currently in beta. The beta for this exam has received overwhelmingly strong interest and I'm very excited to see how it does when it goes live. Team System is a big part of Microsoft's long term developer story and it's good to see that there's so much interest even at this early stage of its development.

Team System Unit Tests and Deployment Items

hdierking — Sun, 25 Feb 2007 02:24:57 GMT

Just a quick tip in case you haven't yet encountered this yet. In the course of my development rhythm, I use both Visual Studio Team Edition for Software Testers and TestDriven.Net as test harnesses for my unit tests. This is primarily due to speed. As I'm sure you're aware, the VSTE test engine takes a good bit longer to initialize than TD.NET and because my programming style is very TDD in nature, I like to run my tests more frequently, and from the test code itself. Now, I ran into a situation today where I wanted to do some testing on an Xml schema that I wrote. Therefore, I have the following test.

   1:  [WorkItem(93), TestMethod]

   2:  public void testGetAssetTypeSchema() {

   3:      XmlSchema assetTypeSchema =

   4:        ((IXmlSerializable) new AssetType("temp")).GetSchema();

5:

   6:      XmlReaderSettings xmlSettings = new XmlReaderSettings();

   7:      xmlSettings.CloseInput = true;

   8:      xmlSettings.IgnoreComments = true;

   9:      xmlSettings.IgnoreWhitespace = true;

  10:      xmlSettings.Schemas.Add(assetTypeSchema);

  11:      xmlSettings.ValidationFlags =

  12:        XmlSchemaValidationFlags.ProcessIdentityConstraints;

  13:      xmlSettings.ValidationType = ValidationType.Schema;

  14:      xmlSettings.ValidationEventHandler +=

  15:        new ValidationEventHandler(settings_ValidationEventHandler);

16:

  17:      XmlReader xrdr = XmlReader.Create("Workstation.xml", xmlSettings);

  18:      XmlDocument xdoc = new XmlDocument();

  19:      xdoc.Load(xrdr);

  20:  }

My "Workstation.xml" file sits in the project directory along with everything all of the rest of my code files. I run my test using TD.NET and I get a file IO exception – my Xml file could not be located. Oh – woops! I forgot to change the "Copy to Output Directory" property. This ensures that when I build my project, the Xml file will always get copied into the output directory along with my assemblies. To do this, I select my Xml file in the solution explorer, and look at the properties window. I can then find the "Copy to Output Directory" setting and change it to "Copy always".

Now, at this point, my test will run just fine with TD.NET because that test harness runs my tests "in place". However, VSTE creates an entirely different folder structure to manage test runs and test results. Therefore, when I run my test with VSTE, my test fails again. To correct the problem, I need to add one more attribute.

[WorkItem(93), DeploymentItem("Workstation.xml"), TestMethod] 
public void testGetAssetTypeSchema() { ... }

The "DeploymentItemAttribute" will cause the VSTE test engine to copy my Xml file from the assembly output folder to the test deployment folder – and therefore the relative path I specify in my test still works flawlessly.