You see quite a few code samples for retrieving "FullName" (or other properties) from an Active Directory that look like this:

string directoryPath = "WinNT://somedomain/someuser";
string fullName;

DirectoryEntry directoryEntry = new DirectoryEntry(directoryPath);
if (directoryEntry.Properties["FullName"].Value != null)
{
   fullName = directoryEntry.Properties["FullName"].Value.ToString();
}

One issue with this code is that when "somedomain" actually corresponds to the local machine name (because your are trying to retrieve the "FullName" of a local account), it can take an extremely long time to run. This is probably because the underlying framework is off trying to find a domain controller before falling back to the local security store.

To work around this, consider code that would look like the following when formulating the directory path:

string[] identities = windowsIdentity.Name.Split('\\');
string directoryPath;
if(Environment.UserDomainName.Equals(Environment.MachineName,StringComparison.OrdinalIgnoreCase))
{
   // special case needed for "off domain" case.
   directoryPath = "WinNT://localhost/" + identities[1];
}
else
{
   directoryPath = "WinNT://" + identities[0] + "/" + identities[1];
}

Using "localhost" will cause the property retrieval to be just about instantaneous, whereas using the computer name (from a local account Windows identity) results in up to a twelve second delay.

Star Trek Premier and MIX09 recap, all in one night in the Twin Cities on May 8th.
A match made in heaven, naturally.

I had a chance to do a talk on profiling code for Microsoft's "Build Your Skills" event on March 24th in St. Louis (and March 31st in Minneapolis).  I mentioned a utility I'd written for cleaning up performance session files that are generated from URLs (so that only DLL/EXE remain.)  You can find that here.  In addition, you can find the slides here.  All sorts of fun details on profiling terminology, types of profiles, resigning assemblies (or turning off assembly verification), etc.  I'm hoping to record a screen cast of the talk soon...

Fantastic turnout at both locations, and really great questions - thanks to those who attended!

I had a chance to do an updated version of my TFS 2008 / Scrum talk at the MN VSTS User Group.  Slides are here.
What a great turnout!  And great questions from the group...

I haven't seen many "Fatal Execution Engine Error (79FFEE24)" sorts of messages lately - not since .NET 1.0/1.1 days.

But we were wrestling with an issue for multiple weeks in which a WCF service would crash with exactly this error.  Since this service uses the DataContractSerializer, this post seemed quite relevant.  The workarounds suggested there were not going to be a fit for us, unfortunately.

The really insidious part of this problem was that the initial failure mode was causing a third party library (that our service invoked) to fail...complete with a stack trace that pointed deep into the third party code.  However, when we removed the call to this library, we got the "Fatal Execution Engine" exception while WCF was attempting to serialize the service response.  (Really nasty, and it points to some sort of stack corruption perhaps.)  You could see that WCF serialization was at fault by analyzing a crash dump of the IIS worker process with WinDbg.

After talking with some folks at Microsoft support, they indicated that the DataContractSerializer issue is fixed in .NET 4.0, but there is not a hotfix available for .NET 3.5sp1 at this time.

The workaround they proposed - and which has resolved our issue - was to place all assemblies that contain types "T" used in contracts that have IEnumerable<T> into the GAC.  (In other words, if your contract has IEnumerable<T> elements, then all types T have to be strong-named & in the GAC.)

Why does this work?  The bug with DataContractSerializer apparently does not manifest itself when assemblies are loaded as "domain neutral" (shared across all appdomains.)  You can force strong-named/GAC'd assemblies to be loaded as "domain neutral" by using the LoaderOptimization attribute.  But if you're hosting in IIS, you are automatically getting LoaderOptimization(LoaderOptimization.MultiDomainHost) behavior for your application.  If you're not hosting in IIS, this bug doesn't seem to appear at all.

This workaround is a hassle, of course - it ripples across the application in many ways...but it does resolve the issue.

I'll be giving a talk for Microsoft's "Build Your Skills" event on March 24th in St. Louis (and March 31st in Minneapolis) on the topic of code profiling.  We'll look at the profiling tools built into Visual Studio Team System Developer, and a few others to boot.  You can get all the details here.  There is a whole slate of great talks planned for the day, so register now if you're in the area...

A frequent pattern in TFS/Team Build is to merge from one branch to another using a label as the basis for the merge.  (That is, you select a label in the source branch that designates the point you want to merge "from".)  Often, this label was applied by Team Build automatically.

This might play out like: "I know this build of this feature branch is good; I'll use the corresponding label as the basis for a merge back to the trunk."  Etc.

If this sounds like you and your shop, be sure to enable the feature that Buck Hodges discusses here to make sure that your build label sticks around even when your retention policy indicates the corresponding build should be deleted.  Otherwise, if the merge process takes awhile (due to conflict resolution, or lunch) you might find that upon completion of your work, you get an error indicating the label you were using cannot be found.

If this scenario does play out poorly for you...you could attempt to deduce the time at which your build label was applied and then apply your own label (with the same name) to that point in time on the source branch.  The merge process will then complete...

(No, really, I didn't get burned by this...)

I had a chance to record another podcast with Jeff Brand, Jason Bock, Rocky Lhotka, and Kirstin Juhl a couple weeks back - you can find it here.

Have you had a chance to play yet ?

Many folks have noted that a lot of the Visual Studio elements that have been present within BizTalk to support the development experience are no longer...quite so BizTalk specific!  BizTalk projects now build upon C# projects, and thus a lot of the differences that you used to see in navigating property pages, compilation settings and build mechanics are now gone.  This is a very good thing - it allows you to leverage skills you already have on your team.

MSBuild support is now first class.  Everyone who went through the trouble to install (and invoke) DevEnv.exe on their build server in order to build BizTalk projects will be glad to know that this is no longer required.  (Builds can be ever so much faster when you aren't relying DevEnv...)

Because of the close relationship with C# projects, you can now have C# artifacts directly in your BizTalk projects.  Many people have noted that when you "Add new item...", C# classes aren't offered as an option.  The product group has explained that this is because currently, the designers (such as the Orchestration designer) are unable to provide intellisense for types that are within the same assembly.  So, you are required to use "Add existing item...".

(This sort of reminds me of the interaction between pipelines and schemas - the former require fullly qualified assembly information at run time, which they won't get if you combine these two artifacts in the same assembly.)

If this limitation persists, will the feature get used?  I tend to think so.  There are often cases where the smart thing to do in an orchestration is to delegate to a component...but the work you do in that component is, at times, so specific to the orchestration that it makes sense for them to be co-located for deployment and organizational purposes.  What do you think ?

The support for unit testing is extremely welcome - check it out.  Debugging maps is great as well, but I'm now (often) partial to the external XSLT approach these days.