I made a post to the Team Build forums about two weeks ago about the inability to use multiple .testrunconfig settings in a Team Build and, unfortunately, haven't heard back from anyone on it yet. So I figured I'd post it here in case anyone else is stumbles across the limitation and is looking for help.

The problem lies in the way that you specify test lists and test configurations in a Team Build build type. While you can technically supply multiple test meta-data files per build type, you can only supply one test configuration for them all to run under. This stems from the fact that they chose to use a separate property, called RunConfigFile, to specify the testrunconfig file to use for the build type as opposed to making it a piece of meta-data for the MetaDataFile item. I'm somewhat baffled why they went this route, regardless of whether they wanted to support multiple test meta-data files, since they used item meta-data for everything else about it.

Why might you want to have two testrunconfigs? Well the main reason that I had was that I have some tests that need to be run under an ASP.NET host and others that only need to be run under the default host. I guess I technically could run the others under an ASP.NET host as well, but, aside from that not making sense logically, if my testrunconfig is shared across solutions then some of those solutions might not have a web project for the ASP.NET host to be configured with.

Anyway, I recommended a solution in the post that's really simple to do: just modify the Microsoft.TeamFoundation.Build.targets file to pull the testrunconfig from the MetaDataFile item instead of a property. The only downside is that you need to make sure you do this on all machines where you're planning on running builds.

I just made a post to the ASP.NET forms for Web Application Projects about this because that's where it's affecting me immediately, but honestly I think it's a bigger problem than that.

Basically I've got an ASCX whose code-behind is marked with ParseChildren(false). I then use AddParsedSubObject to handle the adding of controls inside of that with some custom logic. Unfortunately, despite no errors at runtime and no errors in the source view (those little “squiggles”), I end up with this error when I switch to designer view:

This also seems to prevent WAP from being able to split the file into the new partial classes model. It's worth noting that I didn't have this problem with my WAP conversion experiments prior to RC1.

So Mimeo has officially made the shift to VS 2005/.NET 2.0 this weekend. Part of that was cutting over to Team Foundation Server completely. We've been using TFS for about a month now with great success, but we've only been using the Work Item Tracking features thus far. This weekend, I finally migrated our Visual Source Safe Database over to Team Foundation Version Control. It's quite simple and well documented here on MSDN. However, I did encounter one error during my experimentation phase:

Unable to write to SQL Server: .\SQLEXPRESS due to Error: The size (4969) given to the parameter 'Mappings' exceeds the maximum allowed (4000).

Luckily I found a work around. You can read about my experience in this post in the VSTF TFVC Forum. Hopefully it saves someone else some head scratching.

This interview with Michael Wallent over on Channel9 is hands down the best public explanation I've ever seen/heard from Microsoft on why WPF was created and what some of the major goals and design decisions were.

Some interesting tidbits that came out of the interview:

• Plans to make an WPF “scene” 100% scriptable for smoother integration with Web apps
• Plans to expose the MIL (Media Integration Layer), which is the lowest level for WPF rendering, as a supported API so others can build rich media applications on top of it directly as opposed to necessarily forcing you through the managed API
• Plans for a faster release cycle of future versions

Woah, hold the presses! A semi-cool product name coming out of Microsoft? Jason Sacks just announced the next Windows SDK is almost upon us and also let slip this first mention I've seen of a new product name for Monad: Windows PowerShell.

Interesting. I immediately searched to see if this was indeed the first time the name was mentioned and AFAICT it is. Although the name “PowerShell” itself has been used numerous times...

Update 4/25:

Looks like I was ahead of the ball by a little bit last night! It was released today and the name change is official, learn more over on the new PowerShell blog.

I did some research back in the beta days of VS2005 for upgrading our existing site to take advantage of a bunch of different features that we had either written custom code or used third party code for. One of those features was localization/globalization. I had spent a bunch of time writing custom resourcing support into our existing ASP.NET 1.1 app that very closely mimic'd what ASP.NET 2.0 and Web Site Projects were going to offer. I have a LocalResources directory per sub-directory that contains all our resx files and then I have a bunch of functions that understand how to resolve those resources based on the page/control type name and then we use DataBinding syntax in our code-in-front to get those resources into our UI elements.

Anyway, Web Site Projects supports this concept through the App_LocalResources directory. You plop your resx files in there and then they get compiled into the correct resource path. Then in your ASP.NET code you either use an explicit Resource expression or the meta:resourcekey attribute to populate your page/control with content. You can read all about it here on MSDN.

Unfortunately it seems that Web Application Projects still don't support this feature even in the latest RC drop. They do have support for App_Data, App_Browsers and App_Themes (even though it's named Theme on the context menu right now)... so I'm just hoping App_[Local|GlobalResources] support is forthcoming.

FWIW, I posted in the ASP.NET forums about this if anyone is interested in voicing their opinion for support of this feature. Perhaps it's all smoke and mirrors and I really only need to create a regular old directory named App_LocalResources for it to all work, so I'm looking into this. As for now, I am waiting for a response to my post with bated breath. :)

Update 4/19:

I received a response to my post from the individual at MS who is working on these features. The good news is support is coming, but definitely check out the post for the details.

It's late and I'm definitely overtired and getting that halo effect around my monitor, but... am I missing something or does VS 2005 give you no way to do PDBOnly builds through the IDE? Well, in any case I made it do it by editing the csproj, which is just an MSBuild file, by hand.

All you have to do is go into the file and find the <PropertyGroup> that corresponds to your configuration and platform, in my case Release|AnyCPU, and edit the <DebugType> property to be “pdbonly” instead of “none”. 

I certainly hope I'm just missing some checkbox somewhere because I don't know how any development shop worth their salt can possibly do release mode builds without PDBs.

Check out this response from Monad Architect Jeffrey Snover to some constructive criticism from the community. In it he justifies some of the design decisions that were made. He really tries to drive home the point that Monad is primarily a shell language and secondarily a scripting language.

He also mentions that there will be a new drop coming “next week” and it will include extended support for auto-completion/intellisense which is something a lot of the community has been clammoring for. Can't wait!

I just posted this question to the forums, but I figured I'd post here as well in case anybody subscribers out there know the answer and also for future edification:

I create a new ASP.NET performance session and point it at my web application directory (i.e. not using IIS). Now, I can sucessfully get performance data for the web site itself, but I cannot seem to get performance data for any other project assemblies I've configured for instrumentation.

At first I noticed that it was instrumenting the project assemblies in their respective project \bin directory as opposed to my web site's \bin directory. Then I tried using target binaries and selected my assemblies directly from the web site's \bin dir, but that didn't help either (and also doesn't seem like the right thing to do).

I certainly hope it's possible to instrument and profile other assemblies in an ASP.NET based session. :\

Stay tuned for an update, hopefully I get an answer pretty soon. Profiling your unit tests is one thing, but when I actually get to profile the application and it's usage patterns, as played out by some recorded web tests, I should get a lot better picture of where my problem spots are.

Update 4/15:

So I got a response to my post and the good news is this is possible with the lower level profiling tools it's just not something supported by the IDE today. Here's the link that was given to me which includes all the details on how to setup such a performance session. Happy profiling!

Update 4/18:

Make sure to read the latest details on the thread. It just seems like Web Application Projects aren't directly supported for instrumentation.

You can read all about RecursiveDir here, but basically MSBuild supports a syntax for recursive directories that goes a little something like this:

C:\My Projects\**\*.xml

Basically this says, go recursively through every directory under C:\My Project and find me all the files with an .xml extension. Simple right? Ok, now imagine you structured all your projects in such a way that you kept certain xml files in certain subdirectory of each project... let's call it “Test Results”. So, if I want to grab all the test results for all projects, but not any other .xml files, I would do this:

C:\My Projects\**\Test Results\*.xml

Follow so far? Now consider the following example directory structure:

C:\My Projects
      |- Project A
            |- Test Results
                  |- 4-11-06.xml
                  |- 4-12-06.xml

Ok, the documentation states that the RecursiveDir metadata will be equivalent to the path that is expanded by the ** notation. When I use the first path declaration I end up with the following for RecursiveDir:

Project A\Test Results\

Great, that's just what I'd expect because the ** resulted in both the Project A and Test Results directory being selected. However if I use the second path I still end up with this for RecursiveDir:

Project A\Test Results\

Hmmm... not what I'd expect. I would have expected only Project A to be included in the RecursiveDir value because Test Results was an explicit part of the path.

We started working with MSBuild recently and I had to write my own task for selecting XML nodes out of documents. Here's an article that covers my experience in detail complete with source code for the Task.

Today was a learning day for me. The subject? MSBuild. I was familiar with the basics and have used nAnt for a while now, but now that Mimeo's getting ready to transition to VS 2005 + Team Foundation Build we really want to know what we're going to have to do to migrate our existing scripts.

The number one thing to get your head around is Items and their Metadata. Read this and then read it again immediately. That link also links to this page about well-known Item Metadata which is important to understand. Items are like structs. Items usually represent assets imported into MSBuild from the file system. This could be source files for a compilation task or some binaries that you're moving around as part of a deployment. One thing to be careful not to fall into the easy trap of thinking that Items only represent assests on the file system though... they don't. Despite that documentation you just read show absolutely no examples of anything but creating Items from the filesystem, you can create an Item out of thin air with any set of Metadata you want. I think the confusion around this stems from the fact that you have to specify a value for Include. Turns Include really just isn't a great name. The value for Include doesn't have to be a file system path at all. For example this is a perfectly valid Item:

<Person Include=“DrewMarsh”>
  <FirstName>Drew</FirstName>
  <LastName>Marsh</LastName>
</Person>

Include, when it's not a path, basically becomes the unique identity of the Item. You can check this yourself via that well-known metadata I mentioned before like so:

<Message Text=“%(Person.Identity)” />

Technically this translates into something in the lower layers of MSBuild called an ItemSpec. Confusing as hell I know, but if you want to really leverage the power of MSBuild you have to use Items and Metadata to communicate between tasks. One last thing about Items that you have to wrap your head around is addressing them and their metadata in different ways.

MSBuild also has properties, but properties are really only there to represent scalar values. You can nest XML in them too which is pretty neat. The XML can even be filled in by more properties which MSBuild will expand. The XML is passed to Task implementations as a string and the task is then responsible for parsing it. The neat part about this though is it's a nice way to pass structured data to a task for configuration.

For anyone coming from nAnt, the one thing you'll miss the most is functions... there are none. Everything has to be done with Tasks. You'll also likely be used to a expanded library of tasks that have been built up around nAnt over the past couple of years. There is a set of community tasks available already that mirrors a lot of the stuff that nAnt and the nAnt-contrib project offer. Unfortunately my first experience with their XmlRead task left a lot to desire. It really doesn't do a good job working within the rich realm of MSBuild at all. So, also as part of my learning today, I spent some time writing my own XmlSelectNodes task and will be putting together a post with the details on that shortly.

Finally, I did stumble across a bug that I have reported. If you have a single quote anywhere in a path that your Including using the recursive directory feature, the RecursiveDir metadata will not work. This had me ripping my hair out for at least thirty minutes wondering if I totally misunderstood the concept. Then I tried a simple example in a path without a single quote and it just worked. :\

Peter just posted a nice little MSH script for listing out csproj files and their guids. Feeling inspired, here's one I wrote that helps me find all projects that reference another project:

get-childitem -Include *.csproj -Recurse | where-object { ([xml](get-content $_)).SelectSingleNode('//*[local-name() = "ProjectReference"]/*[local-name() = "Name" and text() = "<your project name here>"]') -ne $null } | sort-object Name | select-object Name

Plop the friendly name of your project into the “<your project name here>” and you can easily find any projects that reference the project you're lookin' for. Note I had to use ugly XPath local-name() hacks to get around the fact that otherwise I'd have to pass in an XmlNamespaceManager to SelectSingleNode to map the namespace for MSBuild.

Want to be a WPF Evangelist? Here's your chance.

It's times like these that make me wonder if my company realizes how lucky they are that I'm so loyal. ;P

You can read about what's new/fixed in the RC here on Scott's weblog, download it here and, for more info on why this new project type was created, check out this MSDN article.

Wow, ask and ye shall receive! James Manning has released an initial implentation of an MSH provider for TFSC. Make sure to check out the MSH Community Workspace, where he contributed the source, too!

Update:
James contacted me to let me know about two things:

1. I had a little typo in the title (“TSFC” instead of “TFSC”) which I've fixed
2. I should probably be calling it TFVC from now on... Team Foundation Version Control vs. Team Foundation Source Control.

Thanks James!

Karsten Januszewski posted a great entry yesterday about the learning curve of WPF. Basically the general message you get for WPF is that it's going to make our lives simpler and improve the developer and designer experience such that you'll be able to crank out great looking, functional, feature rich apps all day long. I personally agree with this message, but it's important to remember that it just won't happen overnight.

There are so many different facets to WPF that it's going to take some time to figure out how to brng them all together effectively to deliver a great product. One of the biggest problems I see is that people are so used to doing things one way that when feature X doesn't work exactly the same in WPF as it did in their previous client technology they'll get frustrated and keep trying to force WPF into doing something unnatural for it rather than taking a step back and figuring out what the “right” way to solve the problem is on this new platform.

Anyway, Karsten does a really good job explaining it, so I highly recommend you check out his post.

Well, wonder no more. Pablo Fernicola lays down the nitty gritty of hardware rendering in WPF. If you wondered exactly which pieces are GPU accelerated and which pieces still require CPU resources, this is the article to read.

Stumbled across the blog of Tim Cahill today. Apparently he's the man to talk to when it comes to WPF performance. Playing with WPF and having some problems squeezing every last ounce out of CPU and GPU? Check out his blog for ways to analyze and optimize your WPF apps!