.NET 4.0 Client Profile and the Power of Defaults
ByNote: 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:
4 Comments
April 9th, 2010 at 12:02 pm
Yes, this is a strange thing for Microsoft to do. Fragment .Net to a client profile to save a whopping 8 MB on the install? Why? This one split in the fragment will cost millions in developer and support costs to deal with it in the field with end users. Sad.
May 3rd, 2010 at 11:04 am
Jason,
You miss the larger point of the split, which is NOT about saving space, it’s about a clean separation between client and server libraries. Because .NET v.Next will probably turn Silverlight and WPF into a single runtime. The only way to get there is to have a clean separation. And I *highly* doubt it will cost “millions in developer and support costs” to spend 30 seconds fixing your project. You have to jump through hoops to upgrade ANYWAYS. If you read about the changes before you upgrade, you save yourself a LOT of hassle.
Jay,
You already have a version of Agent targeted for the web, you might just consider moving related stuff over to that assembly. Resharper is a great tool for refactoring. Also, this post might help you us you are using classes in System.Web.HttpUtility (They are now in System.Net.WebUtility): http://10rem.net/blog/2010/04/07/encoding-decoding-uris-and-html-in-the-net-4-client-profile
HTH!
May 3rd, 2010 at 4:11 pm
You’re right that we’re not as bad off as some – we have only a minor amount of code in our core Agent that is affected, but it’s pretty critical stuff: For example we use it to make sure UI options in the agent can’t get enabled while running in an ASP.NET web site, and we change the behavior of how we grab user identity, etc. We do have an extension for the agent for the web, but we’ve always considered that optional, even for ASP.NET. We can adapt, but we have to think it through carefully to make sure people can’t get themselves in trouble.
But to Jason’s point, it means for us we have to increase our testing to be sure what we do works correctly in both modes, and it means we’ll have to “unbundle” some capability from our core Agent which may confuse some users.
July 22nd, 2010 at 10:08 pm
[...] our previous releases all work under Visual Studio 2010 there were a few seams that could get in the way. For this release [...]