Geek Runs Through My Veins

Moving on...

2006-06-09T06:23:00Z

After working on the DDCPX team and in the Developer Solutions group for over a year, I’ve switched to a new team in Microsoft. Consequently, this means I’ll no longer be working on the MSBee project. This was a difficult decision considering how much I’ve enjoyed developing MSBee and the positive experience I’ve had working with the VS developer community.

A fellow developer on the team, Bertan Aygun, will be taking over MSBee development. You may have noticed him replying to questions in the forums and handling issues on the MSBee CodePlex site. He also has a blog at http://blogs.msdn.com/bertan.

As for me, I can’t discuss my project since it’s confidential; I do hope to admit to it at some point in the future. This also means that I won’t be discussing it in my blog; I do hope to continue posting although my main source of material is now gone. :)

MSBee - 2 Weeks on CodePlex

2006-05-31T03:48:00Z

MSBee has been on CodePlex for a little over 2 weeks. In that time, there have been 1,350 downloads of the 1.0 Release and it's been the most downloaded tool on CodePlex! Additionally, the Power Toys releases have garnered attention from blogs, including Soma's, and online news sites such as InfoWorld. This attention has brought in an in-flux of users who are thrilled that we're providing these tools. Naturally, I'm very excited and proud to be part of such an early success in these relatively uncharted waters for Microsoft.

I'm also looking forward to seeing contributions to our Power Toys, particularly MSBee of course, from the developer community. Each tool has room for further development and I've already added 6 work items for MSBee. One popular request, integrating MSBee into the VS 2005 IDE, is already being worked on by Jazzynupe, who's building Visual Studio templates for targeting .NET 1.1. We're also working on an issue identified by Jamie Cansdale regarding the app.config file that comes with the RCR executable.

MSBee 1.0 is available on CodePlex

2006-05-16T20:18:00Z

One of the most satisfying moments for any project is saying "It's done." For MSBee, this moment has come as the 1.0 release and its source code were posted to CodePlex yesterday evening. Thus, if you go to http://www.codeplex.com/Wiki/View.aspx?ProjectName=MSBee, you'll find the new home for MSBee, replacing the GotDotNet page. The 1.0 Release is available under the Releases tab. You can obtain the latest source code by going to the Source Code tab and downloading the latest check-in. We're using the Microsoft Permissive License with MSBee.

We're looking for developers to come join the MSBee project. So, if you have a feature suggestion or a bug fix, you'll be able to share your contributions with the community.

Right now, you can participate in the community through:

Answering questions on the forums at http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID6&SiteID1
Submiting issues or feature suggestions at http://www.codeplex.com/WorkItem/List.aspx?ProjectName=MSBee

Soon, we'll have more information on providing bug fixes and checking in new features.

MSBee will be on CodePlex

2006-05-14T03:42:00Z

As the post's title indicates, MSBee's source code will soon be available on CodePlex; we're just waiting on final approval of the shared source license. CodePlex is an environment for creating, hosting, and managing open and shared source projects, similar to SourceForge. CodePlex uses Team Foundation Server as a source code depot and to perform work item tracking. The CodePlex website describes all its capabilities and features.

As soon as the MSBee project has been created, I'll announce it here.

MSBee 1.0 Is Coming Soon

2006-05-06T04:26:00Z

MSBee 1.0 is now code complete, meaning we're just a few days away from the final release. Subsequently, our MSBee shared source release is also on track and will be available soon.

Earlier today, I was reading a blog post by Josh Ledgard, a co-worker on the Solutions team. The post discussed feedback he received on keys to successful source releases and I wanted to respond to some of those suggestions by explaining what we've done for the MSBee release.

Multiple people provided feedback that the open source community is becoming very fond of the Microsoft "permissive" license. We've noticed that as well and the MSBee source release will come with a permissive license.

Another individual mentioned lowering the barrier to entry when it comes to contributing. Specifically, he's been frustrated by projects that require tons of dependencies and, even after installing them, have other nuisances that require additional work before he can successfully build.

For MSBee, we made a conscious effort to significantly reduce the pain of that experience. We've intentionally used publicly available tools for code analysis (FxCop), testing (NUnit), and building the MSBee installer (WiX). All these tools are available as binary distributions so you don't need to build them while you're trying to build MSBee. We also provide a MSBuild file that lets you specify where you’ve installed these tools. This file is imported by all the MSBee projects so once you add your paths to the Settings file, all the projects become aware of the tool locations. Additionally, by using a MSBuild file, we can give you an informative error if you forget to provide a path in the Settings file, instead of a cryptic build error.

We're also providing our unit test and scenario test projects, along with a batch script to run the tests. The unit tests include tests for each task in the MSBee DLL. The scenario tests build test projects using MSBuild with MSBee. Thus, when you make changes to the existing code, you can run these tests to verify that your change didn't break any functionality. Additionally, you can add new tests as needed.

Another user mentioned her desire to have architectural diagrams and relationship trees for classes and project dependencies. While we don't provide that level of documentation with MSBee, you will get the MSBee ReadMe, a spec and design document on the installer, a design document on ResolveComReference, and our Test Plan. Additionally, I spent considerable time supplementing our code with comments that describe how everything works. And our forum is always available for questions.

In short, we've made a concerted effort to make working with the MSBee source a pleasant experience and to eliminate some of the commonly experienced pitfalls. I hope that contributors will feel the same way.

Finally, on an unrelated note, I mentioned in a previous post that I couldn't properly run my tests with NUnit through the External Tools dialog in VS 2005. It turns out there is no VS macro that points to a project's bin\<configuration> directory.

Designing a Tool to Build VC Projects Using MSBuild

2006-05-02T01:06:00Z

About eight months ago, I spent time working on a solution for a gap in MSBuild VC++ support. When you currently build a VC++ solution with MSBuild, MSBuild is really executing vcbuild.exe to do the actual work. There are no cl and link tasks or any other C++ MSBuild tasks, and C++ projects still use the old VS project format instead of relying on MSBuild. Thus, I prototyped an application that could convert VC++ projects to MSBuild projects and created cl and link tasks.

Since then, this effort was abandoned in favor of MSBee. However, I've composed a document that describes the issues I discovered while prototyping and how you might go about building this tool. My hope is that some interested people in the community will continue this project to fill this gap in MSBuild compatibility.

The document is attached to this blog post; feel free to post additional questions.

Developing MSBee - FxCop, NUnit, and Team Build

2006-04-21T00:32:00Z

In my previous Developing MSBee posts, I mentioned some issues I was having with FxCop and NUnit.

Regarding FxCop, the IDE kept crashing when I tried running fxcopcmd.exe as a post build event. Jeffrey Van Gogh from the FxCop team debugged the problem and discovered it was a MSBuild parsing issue. Specifically, MSBuild attempts to parse the output of fxcopcmd.exe and then add it as regular warnings to the Error List in the IDE. If fxcopcmd can't find a source location for a particular error in the assembly's .pdb, it displays <source location not stored in PDB> as part of the output. This typically happens with violations that are tied to an entire assembly or namespace, as opposed to a particular method. It turns out that using < and > was causing the MSBuild logger to crash, hence bringing down the IDE. Jeffrey has worked around the issue by replacing < and > with [ and ] and this change will be in FxCop 1.35 RTM. Thanks again to Jeffrey for his help in solving this.

Unfortunately, my NUnit problems haven't been solved. As people pointed out, I could use TestDriven.NET along with other tools, although I still feel compelled to find a solution here since it seems like it should be easy. I did determine that the problem is VS; for some reason, the Target macros are referencing the obj directories instead of the bin directories when using External Tools.

Finally, I wanted to share a blog post by Gautam Goenka, a developer on Team Build. The post is a response to a frequently asked question to their team; how to build .NET 1.1 applications using Team Build. In his post, Gautam goes over the simple steps to use MSBee with Team Build.

Developing MSBee - Trying to use NUnit in the VS IDE

2006-04-18T04:47:00Z

For the upcoming MSBee shared source release, I've spent time migrating our unit tests from MSTest to NUnit since NUnit is freely available to the developer community. MSTest and NUnit have similarly named attributes and Assert methods, which helped make the migration trivial.

Although I'm not trying to stir the pot, I feel like mentioning that after using NUnit, I still prefer MSTest. Some reasons include:

Integration within the VS IDE
Just one click to run tests under a debugger
VS can generate accessors, for private variables, to be used in test methods

While I'm not interested in debating these assertions (at least not in this post), the first point is of interest to me in this post. While developing MSBee, I wanted to have some integration between the VS IDE and the NUnit GUI for running our tests. After reading the NUnit 2.2.7 documentation, I followed the instructions to add nunit-gui.exe as a custom tool in the VS IDE. I'm using $(TargetPath) for the arguments and $(TargetDir) for the initial directory. Unfortunately, when I tried running NUnit via the Tools menu, I received a delightful FileNotFoundException: Couldn't load nunit.framework or one of its dependencies. After doing some reading in the NUnit forums, a few others appeared to be hitting the same issue although no workarounds were posted. If I remember correctly, someone attributed the problem to NUnit searching the obj directory instead of the bin directory when using the Target macros. Whether this behavior is being caused by NUnit or VS is unclear.

I've tried working around this with different macros and thought I succeeded by setting $(ProjectFileName) for the arguments and $(ProjectDir) for the directory. While this did cause my tests to run, I recently realized that when I change to a different build configuration and re-run NUnit, it runs the test DLL in the previous configuration's bin directory. Presumably, the Target macros would solve this problem, provided that they worked. I later tried using other VS macros, including $(OutDir) or $(Configuration); I hoped I could append them after $(ProjectDir) to build a path to the bin directory. This time, I was hit with the bitter taste of an ArgumentException that specified illegal characters in path.

Since I want some Test GUI integration in my IDE, I'll continue to stubbornly attempt to get NUnit to load my real target path. If anyone else has experienced this problem, or knows a workaround, feel free to post a comment. BTW, I realize I could use tools like TestDriven.NET to provide IDE integration. However, at this point, I really want to force VS and NUnit to obey me, hence I'm looking for a resolution to this particular problem.

Developing MSBee - Part 14

2006-04-16T04:37:00Z

I've been remiss in blogging lately so let me update you on MSBee's progress. We're heading into the third week of Sprint 3 and we're still on course for RTM in early May. With our ResolveComReference work complete, we're focused on preparing for the shared source release.

One issue I've been working through is transitioning to the publicly available version of FxCop. MSBee is developed using Visual Studio Team Suite, which includes a special version of FxCop that is integrated with MSBuild via a task and is controlable via the VS IDE. For the shared source release, I want users to be able to build MSBee without needing any version of Visual Studio. Additionally, I want to maintain our FxCop builds so defects in code contributions can be caught. To accomplish this, I'm working on switching MSBee from FxCop in VS 2005 Team Suite to FxCop 1.35, which is available on GotDotNet.

The problem I'm having is with VS crashing. I've set up a post build event that runs FxCopCmd.exe. When FxCop finds no violations, the build succeeds with no issues. When a violation is discovered, it's written in the Build Output window. Unfortunately, Visual Studio crashes immediately afterwards due to an ObjectDisposedException. One possibility is that there's a conflict between the two versions of FxCop on the machine, although I'm skeptical of that being the culprit. Another cause may be related to VS trying to parse the FxCop warning that gets written to the console. Or it could be something completely different. If you've experienced this problem before or know of other possible causes, feel free to leave a comment.

Developer Solutions Team on Channel 9

2006-03-29T20:25:00Z

About a month ago, at the end of our first sprint, we invited Ken Levy to check out our first 3 power toys for Visual Studio 2005. Channel 9 has now posted the video, in which you’ll meet our team and catch demos of MSBee, Managed Stack Explorer, and the TFS Administration Tool.

MSBee - Beta 2 Released

2006-03-24T21:47:00Z

We've just released MSBee Beta 2! You can download it by going to the Beta 2 homepage and clicking on the MSBee Beta 2 Release link.

Beta 2 adds more great features to MSBee, including:

Support for the ResolveComReference task!
Redirecting the LC task to target .NET 1.1
Defining a FX1_1 constant to let you exclude .NET 2.0 specific code
Providing a BaseFX1_1OutputPath property for replacing the default 'bin\FX1_1' base path.

Additionally, the ReadMe document demonstrates a way to import MSBee .targets files without needing to manually edit your project files.

Big thanks go to everyone on the Aftermarket Solutions team for their invaluable contributions throughout the sprint.

MSBee - 2,000 downloads and Beta 2

2006-03-22T20:47:00Z

We have exciting news from the MSBee home office; we've passed the 2,000 downloads mark! This is a great milestone for the Beta 1 product.

Even more exciting is that Beta 2 is now code complete. As promised, Beta 2 will include support for resolving COM references. Look for the release announcement on this blog this Friday!

Developing MSBee - Part 13

2006-03-11T07:48:00Z

In my previous Developing MSBee post, I began discussing how the ResolveComReference task is being implemented. As I mentioned, we want to produce .NET 1.1 COM interop when necessary. Consequently, our code must run with .NET 1.1. To do that, I proposed using an app.config file and then you wondered why would I have an app.config file if I’m making a task? Well, it turns out that I’m not just making a task.

The MSBee DLL will contain a ResolveComReference (RCR) ToolTask that has the same properties as the MSBuild ResolveComReference task. However, the tool task will run an executable that does the actual work of resolving COM references. This executable contains the MSBuild team’s ResovleComReference code, along with pieces of their Framework and Utilities DLLs. This allows us to leverage their code and just replace the .NET 2.0 specific pieces with .NET 1.1 equivalents. Naturally, we’re dogfooding MSBee to build the application.

To transfer our RCR task’s properties to the executable, we place some values on the command line as switches and others are written into a temporary response file. The executable parses its command line and processes the response file to retrieve the task’s input. When the executable finishes, it writes the resolved COM reference data, which is stored as TaskItems, into a temp file. The RCR task will process the temp file when the executable returns and add the TaskItems to the appropriate output arrays. Unfortunately, TaskItems are not Serializable so the TaskItem metadata is manually converted into a string before it’s written to a file. When a file containing TaskItem metadata is processed, it must rebuild each TaskItem by parsing its string.

So, that’s a condensed explanation of how the ResolveComReference task will work in MSBee. One unfortunate result of this approach is that the executable itself will not be shared source since it contains intellectual property. However, the RCR tool task will be shared source along with the other MSBee tasks.

MSBee - Signing Files

2006-03-10T22:13:00Z

As I mentioned in a previous post, we planned on implementing the SignFile task in MSBee during this sprint. This decision was based on early adopter feedback, which indicated that users wanted this task. However, as we've reviewed the situation, we realized that the better question to ask is: Are users interested in authenticode signing or strong name signing in MSBee? So, if you have an opinion on which of these is more important, please add a comment identifying which one and why.

BTW, the ResolveComReference work continues; the functionality is about done and I've moved on to testing. I'll be adding another post on its design soon.

MSBee - TestDriven.NET

2006-03-05T08:12:00Z

Jamie Cansdale, who develops TestDriven.NET, is adding a new test runner that uses MSBee. This means that for a C# or VB project, you'll be able to try building the project using MSBee as a test for .NET 1.1 compatibility.

You can read more about it, and sign up to be an early adopter, via his blog post: http://weblogs.asp.net/nunitaddin/archive/2006/03/01/439359.aspx