Objective Disclosures

Following up on my previous post, I tried working with an application framework on my XP SP2 system and when I ran the NUnit tests, all transactional Commands were Red with: "The partner transaction manager has disabled its support for remote/network transactions."

The first thing I found was that Windows 2003 is in fact more secure in deployment, and thus required some loosening.

Then I discovered that this was also an area where SP2 had in fact made things more secure, and also require some loosening.

While this was a bit painful to slug through, it's still good to find these things on the developer desktop rather than on first deployment to staging or worse to production...  It's another very useful benefit to running with Virtualized systems as it allows the simulation of the real environment so that things that shouldn't work (like local system access accounts and short-circuited security) break were they are broken ;)  

One thing to consider with this is it is yet another reason to start moving app servers and web servers out of the DMZ and into the corporate and network and leverage the ability of ISA 2004 to run in the DMZ exclusively.  Topic for another day. 

Now if I could just convince myself to take my user account of the Administrators group... 

I don't know if you've been spending much time working with any of the .NET 2.0 based systems we are building (Longhorn, Yukon, Whidbey), but I've been working with some form of them for about a year and a half now.  One of the difficulties I've had is trying to work with any combination of these as to keep things relatively stable and happy, you need to make sure the version of the redist is the same.  For example, if you went to PDC, you got the Goods which were a version of the three of these that were all built using .NET 1.2.xxxx.yy (I can't remember anymore).  So you could install the kit together and they were relatively happy together.  Try doing that outside a planned milestone when downloading releases from each of the build servers.  Not pretty, and not something that the product teams should be wasting cycles on when driving to get these out, but it makes for an interesting challenge for those of us that can't wait to get our hands on the latest bits...

With the release of the official Whidbey Beta 1 and Yukon Beta 2, I don't know if you noticed but they both have different releases of .NET 2.0 (40607.16 and 40607.42, respectively).  While all works relatively well if you install Yukon first and then Whidbey, try and get both of those to work on top of a recent Longhorn build (say 4091 which uses a later build release of the framework)...  Good luck - there is a black art method to do this, but with the frequency of needing to updating your builds, this isn't ideal.

So, to combat this I've resolved to running to Windows XP SP2 as my base OS today and focus on getting my dynamic releases isolated to Virtual PC's.  At MGB, a friend (JEQ) pointed out to me the value of differencing disks and how to setup a more space sensitive virtualized environment that also saved considerable time in setting up virtualized machines to run these releases.  I haven't had time to consider this until I blew up my OS the other day with an unexpected .NET install by the Ocracoke tools as I tried to "simply" add in the testing tools to my sync'd up Whidbey/Yukon install where I had them both running 40607.40.  Ooops.  The world is not happy with two installs of .NET 2.0 on the same box and don't even try to gracefully uninstall...  time to rebuild and rethink how I'm doing this and JEQ's differencing drives popped into mind.

Using an ISO image from MSDN I created a base Server 2003 Standard Edition disk, got it all patched and then sysprep'd it (also for XP). Then you mark that disk read-only and go into Virtual PC and create a new disk, select differencing and point to the Server 2003 image as the base.  Now create a new Virtual PC system that uses the differencing disk.  When you boot it, voila you can now have a new SID system that you can install whatever release of whatever app on top of.  This is nice for me as I now have a clean SQL 2000 SP3 machine and a Yukon Beta 2 machine that uses very little space because they are both load up the base image and then add the "differences". I can then boot one or the other and hit it from my VS.NET base installation.

Now I'm on the path to doing the same with some XP Images to keep a Whidbey build loaded into and an isolated Ocracoke; I'll also build Server instances with BizTalk 2004, HIS 2004 and others (LCS...) while never installing Server 2003 again.  The same also works for Longhorn so I can install and not hose myself anymore...

Take a look at something fun to play with: Windows Media Player 10 Technical Preview is online on the public site (http://www.microsoft.com/windows/windowsmedia/mp10/).  It's got some nice Longhornish styling built-in and some noticable improvements in the navigation of large libraries and some cool integrations.

What I am dumbfounded on is why it still doesn't support Genre / Artist / Album or Genre / Album / Artist or at least some sort of custom categorization (i.e. Folders!) of the artists and albums.  With a large music library opening that Artist list or Album list makes my eyes glaze over, it's just not navigable.  But, here's the thing, this an opportunity to make the product better, so I'll submit that request to the community forum and hope that it makes it into the final release.  Download the preview, take a look and posts your requests.

The latest issue of MSDN Magazine (http://msdn.microsoft.com/msdnmag/issues/04/09/default.aspx) has an interesting article on applying the Command Pattern to the problem of distributed systems.  It proposes a neat technique of essentially encapsulating some piece of work within a Command and shipping that off via MSMQ to have some other endpoint process it.

This is cool stuff as I like the use of ICommand's to encapsulate data processing associated with a physical store abstracted away from the data entities.  For example, a Model object (binds data and the rules internal towith it) can use ICommand's as a persistence layer to work with any underlying store, freeing it from direct dependancies on a Database, a Web Service, a Queue, etc.

One issue with the proposed delegation of Execute() over the proverbial wall is the loss of security and other aspects that should be applied to the execution.  One way to resolve this is to combine the Command pattern with the Template method pattern to implement an interception framework embedded into the Command to ensure proper safety with Execute(). 

For example:

Public Interface ICommandAttribute

   Sub PreExecute(ByVal cmd As ICommand)

   Sub PostExecute(ByVal cmd As ICommand)

End Interface

   Public Sub Execute() Implements ICommand.Execute

      Dim ICommandAttrs As ICommandAttributes() = _

         Me.GetType().GetCustomAttributes(GetType(ICommandAttribute), True)

      For Each ICommandAttr in ICommandAttrs

         ICommandAttr.PreExecute()

      Next

      Me.MyExecute()

   End Sub

   Protected MustOverride Sub MyExecute()

So creating a custom attribute that implements ICommandAttribute allows you encapsulate any sort of aspect that may need to be enforced with the Command.  An AuthorizationAttribute could check the current thread's IPrinicpal and check that it is valid for Execution of this Command, preventing rogue processes from picking Commands off the queue and firing them adding security to the distributed Command.  Later, I'll blog a bit more about the Model / ICommand relationship...

I've found that it is always so difficult to document the work that we do, so I wanted to open up this channel to get out some of the things I've been working on so that I can at least point to it as a source of some documenation.  Documenation of the theory of why I've built certain things the way I have; not necessisarily to say that it is the best and only way, but at least to express why I thought it was the way to go at the point in time I did it.

I think that's why so many people have taken to the blogger lifestyle - we can't always remember why we did certain things at points in time, or if we even did them at all.  This timestamped public attestation puts it out there so we can at least be a bit clearer about the past.

I work for Microsoft Consulting Services (MCS), building solutions for customers using .NET and our Enterprise Servers.  I typically work using Agile Software techniques (primarily a derivative of ScrumXP) when building stuff.  I plan to talk a bit about things as we build them (while ensuring customer confidentiality) and document what I learn as I go - partly for my sake (so I can jog my memory later) and partly for others (let me know who you are and why you are reading this).