Editors Note: This article has been updated to reflect the release of Gibraltar 2.5 which addresses the issues raised.
While Gibraltar works well with Visual Studio 2010 and .NET 4.0, one place we’ve gotten caught up is with the Gibraltar Agent for PostSharp. In a nutshell, the current version uses PostSharp 1.5 which isn’t supported (and doesn’t work) with Visual Studio 2010.
To use Visual Studio 2010, you need to update to PostSharp 2.0 CTP5 or later. This requires a new version of the Gibraltar Agent for PostSharp. An additional wrinkle is that the .NET Runtime target of an aspect and the application that’s using it must be the same. This hasn’t been an issue in the past because the .NET runtime was always 2.0 (even if you were using .NET 3.5 because that is just a set of additional libraries on top of .NET 2.0). With the release of .NET 4.0 this changes and you need to have a version of the aspects that specifically targets .NET 4.0, or you get strange errors.
To add to the complexity, there are two versions of Gibraltar that are “current” today: 2.1.1 which is the current release version, and 2.2.0 Beta 1 which is the current Beta version. Many people are using 2.2.0 Beta 1, and if you’re new to Gibraltar you should start there. Because we ship a strongly named binary for our PostSharp aspects it has to match with our Agent version as well. Taken in total, this would means we need a version for .NET 2.0 and 4.0, Gibraltar 2.1.1 and 2.2.0.
If you’re in this situation where you’re using Visual Studio 2010, or for another reason are running PostSharp 2.0, you’ll need to upgrade to Gibraltar 2.5 or later. It includes a version that targets PostSharp 1.5 and .NET 2.0 (like before), another for PostSharp 2.0 and .NET 2.0, and another for PostSharp 2.0 and .NET 4.0. Since the same application could theoretically combine all three they have unique file names to ensure there aren’t any conflicts. The capabilities of all three are basically the same.
Back in January of 2016 we decided to completely transition out of our data centers and into the cloud (primarily Azure). We knew we had to do something - either make some big investments in new hardware or commit ourselves to migrating everything off our own gear. After looking at... Read more
We’ve updated Loupe 4 with key improvements to managing issues, a slew of performance upgrades, and our first built-in Excel export in the web UI. If you’re a Loupe SaaS customer you’re already running 4.0.2 (just upgrade your Windows client) and if you run your own server you can download... Read more
Use SQL Elastic Pools to lower SQL Azure costs by sharing throughput between multiple databases. Designed primarily for SaaS applications this can work anywhere you have peaks and valleys in your load. Read more