a trace of thought on...BizTalk Server, Team Foundation Server, AppFabric, etc. RSS 2.0
 Tuesday, April 13, 2010

A blog post?  Here?? Yes, I know it has been an extremely long while.  I've been doing some writing over here, for the blog associated with my new company (Marcato Partners, LLC) that is focused on agile development coaching.  Even with that focus, I'm still doing technical consulting of course - I just delivered this talk on Velocity (AppFabric Caching) at the Twin Cities Code Camp this past weekend (April 10, 2010).  I’ll be delivering something close to this again at the May 20th, 2010 at the local Connected Systems User Group.

Tuesday, April 13, 2010 12:30:31 PM (Central Standard Time, UTC-06:00)  #    Comments [2] -

 Wednesday, May 13, 2009
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;
// special case needed for "off domain" case.
directoryPath = "WinNT://localhost/" + identities[1];
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.

Wednesday, May 13, 2009 8:24:59 AM (Central Standard Time, UTC-06:00)  #    Comments [4] -
 Friday, April 17, 2009
Star Trek Premier and MIX09 recap, all in one night in the Twin Cities on May 8th.
A match made in heaven, naturally.

Friday, April 17, 2009 10:12:44 AM (Central Standard Time, UTC-06:00)  #    Comments [0] -

 Saturday, April 4, 2009
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!

Saturday, April 4, 2009 1:18:10 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
 Tuesday, March 24, 2009
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...

Tuesday, March 24, 2009 1:42:42 PM (Central Standard Time, UTC-06:00)  #    Comments [1] -
Team System
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.

Tuesday, March 24, 2009 1:36:07 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
 Monday, March 9, 2009
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...

Monday, March 9, 2009 7:33:47 AM (Central Standard Time, UTC-06:00)  #    Comments [0] -
 Monday, February 2, 2009
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...)

Monday, February 2, 2009 4:36:25 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
Team System
 Tuesday, January 6, 2009
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.

Tuesday, January 6, 2009 10:19:16 AM (Central Standard Time, UTC-06:00)  #    Comments [0] -
<December 2014>
About the author:

Scott Colestock lives, writes, and works as an independent consultant in the Twin Cities (Minneapolis, Minnesota) area.

© Copyright 2014
Scott Colestock
Sign In
All Content © 2014, Scott Colestock
DasBlog theme 'Business' created by Christoph De Baene (delarou)