Geek Runs Through My Veins : Developer Solutions

Developer Solutions Team on Channel 9

clichten — Wed, 29 Mar 2006 20:25:00 GMT

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.

What Tools Do You Want After MSBee?

clichten — Sat, 03 Dec 2005 00:24:00 GMT

As mentioned in an earlier post, I'm on the DDCPX team here at Microsoft. Within that team, I'm working in the Aftermarket Solutions group, which is responsible for MSBee along with our tools we're preparing. Consequently, as we complete tools, we're eager to begin development on new ones. Thus, I'm asking you if there are any tools you'd like to see us produce. Specifically, have you been using Visual Studio and thought to yourself, "Gee, I was there was something that did X"? That X is precisely the thing that we want to hear about. As an example, I was recently working with FxCop in Whidbey and discovered that FxCop didn't provide a way to get summary data (violation breakdowns by components, rules, rule types, etc...). Thus, I wrote a tool that reads FxCop XML files, displays the total number of defects, and can present the data in an Excel spreadsheet for easy viewing.

So, if there are any tools that you'd like to see from us, please add a comment to this post with your idea. Additionally, if you think the FxCop tool I mentioned would be useful for you, please post a comment as well.

Targeting .NET 1.1 with MSBuild

clichten — Wed, 05 Oct 2005 23:50:00 GMT

Another idea we've been kicking around recently is plugging a hole with MSBuild and .NET 1.1. As is, VS 2005 only supports building managed applications against .NET 2.0. This means that all managed applications built using VS 2005 require .NET 2.0 as a pre-requisite. This hurts us with ISV's and software vendors that distribute software running on previous versions of .NET. For them to upgrade to Whidbey, they'll need to redistribute .NET 2.0 to their customers or ask their exisitng customers to upgrade. Additionally, Enterprise customers that want to upgrade will need to ensure .NET 2.0 is fully deployed within their infrastructure / environment. As this isn't completely straightforward, and Whidbey cuts them off from targeting the .NET 1.1 runtime, this could slow adoption within our customer base.

Thus, we're considering offering custom MSBuild targets that take converted Everett projects and solutions and allow them to target the .NET 1.1 runtime.

While some people have already offered simple custom targets to solve this problem, there still are major holes in those solutions. For example, we'd like to support COM references; I haven't seen any solutions that handle this. Additionally, there's the opportunity to have command line builds for solutions containing Web References and utilizing the Web Services client stack.

I'm currently researching this idea and estimating interest. If this is something you'dd like to see, please add a comment to this post.

Building VC projects with msbuild (without using vcbuild)

clichten — Wed, 08 Jun 2005 01:35:00 GMT

Along with DDCPX engineering improvements, I've begun spending time looking for useful tools for the VS developer community. One project I have begun is msbuild/vcbuild related. For those who aren’t familiar with msbuild, msbuild is destined to be the official build engine for MS. Instead of using makefiles or sources files, msbuild uses XML based configuration files which execute various tasks. The XML format for msbuild is used in the .(vb|cs)proj files produced by Whidbey so msbuild can be used directly with these files for command line builds.

As many people have noticed in the Whidbey betas, C# and VB project files both use msbuild XML elements. However, C++ is not fully integrated with msbuild; there are no cl or link tasks. Instead, executing msbuild blah.vcproj causes msbuild to invoke vcbuild to do the actual processing. Since this will not be changed prior to Whidbey RTM, I am working on a tool that converts .vcproj files to msbuild formatted files. Thus, a user could convert his .vcproj file to a msbuild formatted file that uses cl and link tasks (as opposed to the standard vcbuild task). Passing this file to msbuild would consequently build your C++ project without using vcbuild.

At this point, I'm continuing my prototype while I measure community interest in such a tool. So, if you are interested, please leave a comment or send me an email.

DDCPX Aftermarket Solutions

clichten — Tue, 07 Jun 2005 23:25:00 GMT

Greetings. My name is Craig. I'm a developer on the DDCPX team at Microsoft. DDCPX stands for Developer Division Customer Platform Experience and is focused on increasing customer satisfaction of developer products throughout the product lifecycle. My primary role on this team, thus far, has been improving our engineering practices, with a key step being the use of the CoreXT build environment. CoreXT is a MS internal build environment that integrates a variety of tools (including PREFast, PREFix, PRESharp, FxCop, OACR, NUnit, and WiX) and features with NT build. Two significant improvements over Razzle (another internal build environment) are that CoreXT has built in support for multiple build types within the same build window and CoreXT provides multiple versions of VS compilers (and associated libraries) along with multiple versions of the .NET framework. Later posts will likely have some CoreXT discussion, coming primarily from my administration experiences.