.NET 4.0 Client Profile and the Power of Defaults

Note:  The issues raised in this post were addressed in Gibraltar 2.5 which was modified  to be fully compatible with the .NET 4 Client Profile.

The good news

The Gibraltar Agent works just great with .NET 4.0. We support the same application environments we support for older versions:  WinForms, WPF, Services, and ASP.NET.  If you’re looking for Silverlight support, drop us a line - we are working in that direction and would like to hear about your project to see how it fits into our roadmap.

So, if you want to leap forward to VS 2010 the very instant you can download it from MSDN, don’t let us stop you - you can use Gibraltar just like before.

And the not-so-good news

We were doing some broader testing with Visual Studio 2010 RC and ran into the same issue as one of our component vendors, DevExpress:  Their CTO covered it well in his article on .NET 4 Client Profile: the Good news and the Bad news.  The bottom line problem is this:

• By default, VS 2010 creates new Windows projects with the .NET 4 Client Profile.
• The .NET 4 profiles split up the .NET runtime libraries by application type instead of technology, so the Client Profile doesn’t include any of the System.Web classes that have shipped in the core library since .NET 1.0.

What this means is that if you create a new WinForms .NET application in 2010, then add the Gibraltar Agent to it you can’t load it or use it because internally we reference the System.Web namespace.  A user will believe we’re just flat broken right out of the box.

Fortunately, as long as you change the default target (which Visual Studio will prompt you for in a compiler warning) then the Gibraltar Agent works.  It’d be nice if that warning was an error - since you get other errors which will lead you in the wrong direction:

It’s easy to miss warnings when you’ve got errors…

Because of this we’re going to have to refactor some of the internals of the Agent and align the agent into separate libraries by .NET 4 Profile.  This is unfortunate because we’ve worked hard to have the smallest number of assemblies (usually you just need one) and this is going to create more complexity for our users.  These changes will wait for Gibraltar 3.0 because they would be a breaking change from the standpoint that the changes won’t necessarily let you just drop in the same assemblies and go.