.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.

Related Posts

PostSharp Diagnostics Now Supports Loupe in the Box

The latest update to PostSharp Diagnostics adds Loupe support, enabling extensive high-performance logging to be added to any .NET application with virtually no code changes. PostSharp even has a great free option for developers that complements Loupe Desktop! Read more

Loupe Agent for .NET Core Now Available

The first release of the Loupe Agent for .NET Core is also our first open source version of the Loupe Agent. This is the first step in our plan to open source the entire Loupe Agent to make it easier for anyone to extend and take advantage of what Loupe... Read more

We've Moved Loupe Service to App.OnLoupe.Com

Loupe Service now has a shorter, direct site name that's faster, anywhere in the world. Just to go App.OnLoupe.Com, the new CDN-accelerated endpoint for the Loupe Service. Your existing Agents and Loupe Desktops are unaffected by this change, but access to the web UI will be redirected to the new... Read more

Rock solid centralized .NET logging

Unlimited applications, unlimited errors, scalable from solo startup to enterprise.