.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

Loupe 4.5 Released with New Log Viewer for Web

Rapidly diagnose each error in any .NET application with our new Web Log Viewer and Exception root cause analysis, new in Loupe 4.5. New integration with Azure Service Bus and Azure Search enables full Loupe functionality without any Virtual Servers in Azure. Read more

Cloudflare Vulnerability Does Not Affect Us

The recently reported Cloudflare vulnerability where fragments of secure, encrypted user data could be exposed to a third party does not affect Gibraltar Software even though we use Cloudflare because we only route static content through the Cloudflare proxy for acceleration. Read more

We're out of our Last Data Center

Back in January of 2016 we decided to completely transition out of our data centers and into the cloud. On Sunday we finally shut down the last cluster of our hardware. Read more for how we did it and whether we would do it all over again if we had... Read more

Rock solid centralized .NET logging

Unlimited applications, unlimited errors, starting at $25/month