Using TFS for Mixed C#/Managed C++ SharePoint Projects

Currently, I am doing a massive TFS migration for a health insurance company, and as part of the migration I am verifying build events for all their projects. Actually I am verifying almost 10 gigs of them, so it’s going to take me the better part of a month! Now aren’t you jealous.

I was migrating some managed C++ / C# SharePoint projects and noticed something very, very interesting.

With mixed language managed C++ projects, particularly, or at least in my case, when bundled with other C# projects, it might be noticeable that some of the compiled C++ projects don’t make it to the drop location. However, some do. While it appears sporadic, those that are referenced from the C# projects are still copied. After investigation I found the root cause is that managed C++ projects actually don’t consider some MSBuild properties. In this case, the problem is the lack of observance of the OutDir property. To understand this, consider the way that Team Build harvests outputs for managed C++ projects for the drop location, they override the OutputDirectory property (in vsprops). So if CustomizableOutDir is set to true, getting those compilations to the drop folder because a manual push.

How to fix it? Get TFS 08 SP1 which has a modified CustomizableOutDir property that lets you work around this! If this option is not on the menu, you can work with CompilationOutputs item group, or something similar, so that you can ultimately override some task with a Copy task to support cloning the files to the drop location.


Take Advantage of Lambdas with RunWithElevatedPrivileges

One of the compelling features in C# 3.0 is the presentation of lambda expressions, cultivated out of the anonymous delegate (type-safe function pointers) support (don’t need to define a method somewhere else) that was present in C# 2.0. A lambda expression organizes with a left side composed of the arguments and a right expression which is the body of the method, split with a =>.

In the context of SPSecurity.RunWithElevatedPrivileges to encourage execution of a method with Full Control rights, it is common to see it as an anonymous method. For example, when using the SPUtility.SendEmail method it is ordinary to elevate rights. Using pre C# 3.0 mechanisms this would normally take on the form:
SPUtility.SendEmail(SPContext.Current.Site.OpenWeb(), false, false, “”, “this is my subject”, “this is my body”);

This is a fair amount of real estate on the code surface. Wouldn’t it be nicer if we introduced a little bit of syntax sugar to tidy it up? This is where lambda expressions are accommodating. Taking the above method, this instead takes on the form:
SPSecurity.RunWithElevatedPrivileges(() => SPUtility.SendEmail(SPContext.Current.Site.OpenWeb(), false, false, “”, “this is my subject”, “this is my body”));
This is much cleaner, and required less typing!