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. :)

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. :)

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 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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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!

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.

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.

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

It's time to discuss how the ResolveComReference (RCR) task will work in MSBee, since I've already finished a prototype. Before delving into an explanation, however, let's recap the problem: When the standard RCR task runs in MSBuild, interop assemblies are generated as necessary. Since these assemblies are generated with .NET 2.0, build errors occur when they're referenced by .NET 1.1 tools, like csc or vbc.

The other key issue is how do I guarantee that the code will always execute against .NET 1.1? This is the easier problem since app.config files can enforce required runtimes. Of course, an app.config file implies we’re creating an application, not a task. And I’ll leave you with that thought until the next post…

To give you an update on MSBee's progress in sprint 2, we've already finished retargeting the CompileLicxFiles target. Now, I'm working on a prototype for the ResolveComReference task. In a later post, I'll discuss our approach and some of the issues I've hit thus far. For now, I just want to share a VS.NET tip I saw today. While building some code in VS 2003, I had a directory of files that I wanted to share among multiple projects. When I used AddExistingItem to add the files to each project, I wrongly assumed that the original paths to the files would be maintained. Instead, it turns out that VS will copy these files into the project directory and then add them. I spent a while tooling with VS and hacking my project files to try to force VS to add the original files but to no avail. Then I found this great post in Shawn A. Van Ness's blog on how to accomplish this.

In brief, it is possible to edit the project file directly although the changes aren't obvious. The easier option is to use AddExistingItem and select the file(s) to add in the dialog box. Instead of clicking Open, however, select the small arrow on the right side of the Open button and choose Link. This will open the files in your project without copying them, so you can add the same file in multiple projects.