Doodle Graphics

ASP.NET 1.1 Browser Capabilities are evil. We've already updated the out of the box BrowserCaps in our Machine.configs for our ASP.NET 1.1 sites as per SlingFive's recommended updates, and our clients were happy - Safari, Opera and Firefox all saw the site as they should do.

I was happy too - until I installed Microsoft's latest Live offering - Office Live Connector  - this updated my Internet Explorer user agent string to:

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.590; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; WWTClient2; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)

(additions in bold)

I will go back and fix the BrowserCaps shortly, and when I do, I'll update this post, but in the mean time, I've removed the offending keys from IE's user agent string via the registry*

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform

Now, I may have just broken my Office Live integration, who knows, but that's a price I can live with until I've fixed the browser caps correctly.

Update: 24 March 2009

Looks like it's deeper than that - I've just upgraded my machine to Internet Explorer 8 and the downleveling has happened again - I'm seriously going to have to take a look at what's in my UserAgent, and understand the BrowserCaps section properly - no one else in the office seems to be having this issue however, so it's clearly me.

Update: 30 March 2009

Hmm, removing the World Wide Telescope (WWTClient2) seems to have also resolved the issue, which is odd, as I've had that installed for some time.

Belated Update: 23 June 2009

Thanks to this answer on StackOverflow, I was able to find an actively updated Browser Caps by Owen Brady. Not only that, but Owen's quite knowledgable on this issue, and a quick email exchange led me to discover that ASP.NET 1.1 gets upset when your User Agent string is greater than 128 characters - which is why removing the Office Live stuff worked I guess, but installing IE8 took me back over the limit . Anyway, the other thing Owen pointed out was to set the default tagwriter to the HTML 4.0 tagwriter, rather than the 3.2 one:

<!-- 08-06-06 Think its safe to force the newer tagwriter -->

<!-- tagwriter=System.Web.UI.Html32TextWriter-->

tagwriter=System.Web.UI.HtmlTextWriter 

*Use with caution, don't edit the registry unless you know what you're doing, I'm not responsible if you break your machine, etc., etc.

Filed under: Fixes

We had the following issue: We'd gone back to an old .dbml file, and added a new table on to the design surface. Visual Studio proceeded to check out the project file, and delete the .designer.cs file from the system - which we failed to notice initially, as it's a nested file. What we did notice however was that nothing would compile, especially not our DAL, as the partial class within the data context contained lots of red squiggly lines and complained that most of our data objects no longer existed.

Looks like I'm not the only one seeing this, and MS fixed it last month, but I'm not sure when the fix is coming out.

Thankfully, there is a work around, and it seemed to work quite well for us:

In your partial class, move any using statements inside the namespace:

namespace DataContexts {

  using System.Collections.Generic;

  using System.Linq;

  partial class ConfigDataContext

  {

    [...]

  }

} 

Then right-click on the .dbml file in Solution explorer, and select "Run Custom Tool". This will then regenerate the designer files, and your code will now compile.

Filed under: Fixes, LINQ