Is Don Box saying what I think he's saying?  That might just give us enough time to get it all downloaded from MSDN before the parades and football games!

Have you ever had one of those ideas pop in your head that makes you feel stupid and brilliant at the same time?  I had just such a situation the other day when I was working to debug some custom tasks I'd written.  The tasks were fairly simple - checking out and back in some assemblies that had just been compiled during a Team Build. 

I followed the MSDN documentation for creating a custom task and used the TFS SDK to perform the necessary actions to create pending edits and check in the changes.  I fired up MSBuild and ran the build locally after deploying my assembly to the appropriate folder and identifying the task in my build script.  Of course, things didn't quite go right as the log file showed.  Thinking how easy this was going to be to fix, I set a breakpoint in the first line of the Execute override and anticipated the excitement of seeing the debugger spring to life. 

I was running MSBuild at the command prompt and passing in all the parameters that I needed to run the script.  I switched over to the command prompt, started MSBuild, then switched back to Studio to attach to the process.  Needless, to say this wasn't working.  Had I been as bright as I could have been I would have found this article from 2005!!!! and saved myself some heartburn.  Alas, I didn't feed the Google monster just the right words and all I got in return were bunny trails. 

Left to my own devices I thought if only I had time to attach to the MSBuild process before my task ran I would be able to catch the breakpoint.  Well, I do know how to slow something down so I decided to create a new custom task for pausing the build allowing me enough time to attach to the process and begin the debug prior to the custom task completing.  I came up with the following:

    publicclassPause : Task

    {

        public Pause()
{ }

        privateint _milliseconds;

        [Required]

        publicint Milliseconds

        {

            get { return _milliseconds;
}

            set {
_milliseconds = value; }

        }

        publicoverridebool Execute()

        {

            if (_milliseconds
> 0)

            {

                Thread.Sleep(_milliseconds);

            }

            returntrue;

        }

    }

I registered the task and called it from my build script right before the custom task I was trying to debug:

                <
            Target
            
            
            Name
            ="BeforeCompile">

                    <
            Pause
            
            
            Milliseconds
            ="20000" />

                    <
            Checkout
            
            
            CheckoutItems
            ="@(SharedAssembliesPathsToUpdate)" />

                </
            Target
            >
          

Now I had adequate time to get to the debugger and find my boneheaded mistakes.  Ended up being an easy change and then things worked great.

Ever the optimist, I commented out the pause task execution and checked in my TFSBuild.proj file so I could run the build on the build machine.  I kicked off the Team Build Type in Team Explorer and kaput.  It died before it really began.

Fortunately, I had VS2005 loaded on the build machine so I fired it up, uncommented my pause task invocation, checked it back in to TFS, kicked off the build, attached to the MSBuild.exe process that the Team Build Service started and hit my breakpoint.  The problem ended up being related to the Team Build temporary workspace and some incorrect assumptions on my part about how it was created and how the mappings would work.  Once I got that figured out everything ran as expected.

Is this solution elegant?  Probably not.  But it is simple and occasionally simplicity is elegant in its own right.

P.S. Don't forget to remove any calls to the pause task as this has the obvious side effect of slowing down your builds!

Microsoft patterns & practices has just delivered an ESB Guidance package for creating an Enterprise Service Bus using BizTalk Server 2006 R2.  You can read about it here.

It would be interesting to know if this is in line with the path to Oslo.  Christian Weyer has a post which describes some of that vision.  It's interesting that this latest push for formal SOA from Microsoft (remember EDRA & EDAF?) doesn't appear to explicitly include an ESB path.

I've been working a lot with Team Foundation Server lately (2005, unfortunately) doing builds and have created a bunch of test builds out on my client's TFS.  I knew the easiest way to delete builds was using the TFSBuild.exe utility but I couldn't find any help on how to send multiple build numbers to the utility on the command line.  I saw a couple of references that said to separate them with commas but that didn't work - it appeared to interpret the concatenated list as one build number.

So, I tried using spaces between each build number and that worked.  Hopefully, this will help anyone else trying to clean up their build messes.  I have a feeling things would have been quite a bit easier had I worked in TFS 2008 but my client couldn't wait until they brought that upgrade into their environment.

Example below: (be sure to use quotes if build names contain spaces)

C:\>tfsbuild delete http://tfsserverurl:8080 "Team Project Name" Development_RC1.3.4 Development_RC1.3.5 Development_RC1.3.6 Development_RC1.3.7 /noprompt

Microsoft (R) TfsBuild Version 8.0.0.0
for Microsoft (R) Visual Studio 2005 Team System
(C) Copyright 2006 Microsoft Corporation. All rights reserved.

Deleting Development_RC1.3.4... Done

Deleting Development_RC1.3.5... Done

Deleting Development_RC1.3.6... Done

Deleting Development_RC1.3.7... Done

I can't even begin to count the number of times I've been tracing a problem with some set of code and realized there was a problem with my understanding of what the .NET Framework Base Class Library was doing and why. 

Now we'll be able to find out.  Scott Guthrie just announced a new capability with Visual Studio 2008 and .NET 3.5 for retrieving source for many of the framework assemblies.

This is huge.  I can't wait to be able to drill into some of the framework without needing to use Reflector outside the debug bubble.

I seemed to have hit a quirk in the registration of event sinks in the SMTP service.  As I discussed in this previous post, I had a need to create a managed SMTP event sink and worked out all the kinks in using that to send to a local MSMQ.  Everything has been running great.

However, I needed to install a new version in a side-by-side mode and couldn't for the life of me get the second assembly to load after registering it with the smtpreg.vbs utility.  I tried everything I could think of but nothing seemed to work.  In order to even register I had to create the new version with a different class name so the ProgID would be unique.  I also had to change the ComVisible attribute Guid property so that I would have a new ClassID.  All of this was pretty obvious.  But even after making sure things looked fine in the registry and the IIS metabase (the actual SMTP sinks are all located in the metabase,) I couldn't get my event sink to fire.  I was even registering using a unique name for the registration entry by appending a 2 to the name (e.g. SMTP2MSMQ2 vs. SMTP2MSMQ.)

I had just about given up when I thought I would try prefixing the version to the registration name vs. appending it.  It worked!  I haven't spent any more time (I had already spent way too much time on this) to figure out what the heck was going on but left it up to some weird registration matchup logic due to the name beginning with the same letters.  You can register the same SinkClass multiple times to manage different patterns of email addresses, etc. but apparently the same name with different SinkClasses is a no-no.

There is a very interesting article out from Microsoft all about hosting the Workflow runtime behind a Windows Communication Foundation service layer.  There are some great points on using duplex channels so events from the runtime can be sent back to the client.  The design is fundamentally similar to what I've been working on for a few clients as described in this post.

It appears that this is an evolution of the Expense Reporting Sample that's been out awhile.  The first version used .NET Remoting instead of WCF.  Guess they didn't want to use someone else's alpha code to build their beta code :-)

Check it out.

Ever had one of those moments when you wished you either knew everything there was to know about software development or had decided to become a pea farmer in Brazil (not that they even have pea farms in Brazil, but they might, but....) instead of a software developer.  Well, I have and a show of hands in a crowded technical gathering would prove my point.  This self-realization should give the reader enough pause about reading on without me clearly stating that I'm sure someone else has solved this problem in a much more elegant way - after all, I'm not even sure they farm peas in Brazil.

Anyway, just when I had decided that I should've given myself more time when I made that fateful "farming vs. programming" decision, along comes an Intellisense moment which made it all better.  I knew about the Convert class and had used it numerous times so I did the fateful "conv+tab+." and started looking for gold.  Sure enough I found it in the ChangeType() method.

The problem...

A fellow developer had written a handy generic method for the type friendly retrieval of application configuration settings.  Everything was working well until I tempted Fate and asked for a value type, int in this case, back from the method:

Error 1 The type 'int' must be a reference type in order to use it as parameter 'T' in the generic type or method 'ConsoleApplication1.Program.GetSetting<T>(string)'

Well, that seemed like an important capability to have so diving into the wrapper I went:

            public
            static T
GetSetting<T>(string key) where T
: class

{

   returnConfigurationManager.AppSettings[key] as T;

}

To start with there was no way to call this method passing int as the generic type because of the class constraint.  So, I quickly modified it to the following:

            public
            static T
GetSetting<T>(string key)

{

   returnConfigurationManager.AppSettings[key] as T;

}

Which, of course, just means I'm a lazy programmer (which, of course, translates to reduced crops of peas if I had chosen that profession.)  At first glance, I thought removing the class constraint would be the answer.  Since we don't have to think things out all the time in this age of change/compile/test/change/compile/test/scream/change/compile/test development I let the compiler tell me if my guess was wrong (isn't that the whole point of generics anyway?) kind of like a game of "Who Wants to Be a Millionaire?" without the lifelines:

Error 1 The type parameter 'T' cannot be used with the 'as' operator because it does not have a class type constraint nor a 'class' constraint

This error message was so useful since I had just purposefully removed the class constraint.  The super-fast-non-thinking-programmer in me changed it to:

            public
            static T
GetSetting<T>(string key)

{

   return (T)ConfigurationManager.AppSettings[key];

}

The very brief moment of insight which caused me to change the cool and friendly as cast to the traditional brute force cast proved NOT to be insightful at all as the trusty compiler let me know: 

Error 1 Cannot convert type 'string' to 'T'

And I thought you could cast pretty easily in the .NET Framework.  Well, you can, but the compiler has no idea what T is going to be so it stops you from making a bad cast and getting a runtime error which of course is apparent evil.  Strong-typing vs. dynamic-typing aside, we were in a real pickle.  We needed this generic method to deal well with a variety of types so...

The solution...(well, you read the title, right?)

            public
            static T
GetSetting<T>(string key)

{

   return (T)Convert.ChangeType(ConfigurationManager.AppSettings[key], typeof(T));

}

ChangeType() has several overloads but the one I was interested in took two parameters: 1) object value and 2) Type.  This was exactly what was needed and I had another moment of "I am invincible" and was sure that I had chosen the right pill (talk about mixing movie metaphors.)

The catch...

Everything compiled and my unit tests proved it to be working swimmingly so what was that gnawing concern growing in the pit of my "been around the bend a few times" stomach.  Things seemed happy and well adjusted.  That's about the time I always have hair stand up on the back of my neck.  What's the catch?  Performance?  Odd inconsistencies that will absolutely drive me nuts later?  Deprecation in the next release of the framework?

Armed with nothing but paranoia, I decided to research this little bad boy and see just how awful it was.  Come to find out my worries weren't too justified as I found out while Reflectoring the method in mscorlib.dll.  They actually did what my cohort and I thought we were going to have to do in examining the incoming T parameter's type and finding the right translation from the string results of the ConfigurationManager.AppSettings[key].  So maybe I'm not as crazy as I thought since the framework folks did just what I had planned. 

However, one thing jumped out when I looked closely at the disassembly:

            IConvertible convertible1
= value asIConvertible;

            if (convertible1 == null)

{

   if (value.GetType()
!= conversionType)

   {

      thrownewInvalidCastException(Environment.GetResourceString("InvalidCast_IConvertible"));

   }

   return value;

}

As I pondered the deeper meaning of what I had just found I realized that it might be a bad thing if I passed in a type parameter for T which was not of the IConvertible ilk.  Which led me to the final version below:

            public
            static T
GetSetting<T>(string key) where T
: IConvertible

{

   return (T)Convert.ChangeType(ConfigurationManager.AppSettings[key], typeof(T));

}

With the IConvertible constraint on the T parameter I could rest easy that this method should provide years of use without any harmful side effects and that I could lay to rest the ongoing controversy in my mind of peas or C# (yeah, right.)

I've been spending some time working with hosting the WF runtime in a WCF-wrapped Windows service.  The idea is to allow these services to be run on servers behind a load balancing technology like NLBS.  In my research I ran across a few great articles and samples which might be useful so I thought I'd post them here.

My goal for these hosting services is to make them as loosely-coupled as possible.  Ultimately, I'd like to have the full set of runtime and service events available through a publish/subscribe architecture similar to Juval Lowy's so that the disconnected and potentially remote consumers could be notified of status and process changes in their respective workflows.  Also, to accomplish the loose coupling, I am taking bits and pieces from the Workflow Adapter/Connector and WS-Transfer Service for Workflow articles that Roman Kiss posted on CodeProject.com.  There's a lot of work to do but I think in the end the architecture is a sound one.  I'm not sure I'll go all the way to WS-Transfer yet but it's definitely a compelling protocol.

There's a good example of hosting workflows in a Windows service out on the Workflow community site.  It also demonstrates the use of IExtension in WCF for hosting the Workflow runtime.

Just wanted a common place I could reference this presentation and code samples.  It was a fun side project that Matt Brown and I have enjoyed presenting to the local user group and a couple of codecamps here in Colorado.  It was originally done pre-Beta 2 so there are definitely things we would do differently now but it does show some cool WCF and WF concepts.  And, it might help in your next job search.

Enjoy.