With the release of IE 8 I have been experiancing issues with the UltraWebMenu 6.1 running under .NET 1.1
The first issue was that access was denied to HM_Arrays.js (I dont get this error in versions of IE prior to 8, nor did I get it in the IE 8 Beta releases).
The Second error is that the UltraWebMenu does not show up at all (shows up in IE < 7 and was showing in beta versions of IE8) in IE 8 release.
I could only get the second error to occur after I managed to clear the first error by grating ASPNET and IIS_WPG full control of the website.
Just a further tidbit. We had issues using Response.Browser.JavaScript. Apperntly this will always return false for IE 8 release (we had to comment out code that was using it). I belive this is related to Microsoft not supporting the .NET 1.1 framework and as such did not update the framework code that tells Response.Browser.JavaScript that IE 8 is a supported browser that has javascript. Which means that the UltraWebMenu could be using this same code, determining that IE 8 doesnt support javascript and hiding itself.
Hi there,
I have been struggling with this exact issue for quite a while, thinking that it's all server-side related, permissions related, etc., and here are my (very different) findings and solution:
1. The problem is not related to IE 8.0, although it was happening to some of our clients who were, coincidentally exclusively, using IE 8.0. But, once we downgraded one of them to 6.0 and 7.0, the problems persisted.
2. The issue happens at the core of the UltraWebMenu DLL deciding (on the server-side) which browser your user is using. If it decides that the browser is of "good" kind, then the result is positive and you get the page that you wanted, fully rendered. That would include references to 2 external script files: /ig_common/scripts/ig_csom.js and /ig_common/webbars2/ig_weblistbar.js. But, if the control decides that your browser is not what it wanted, then your user would get a much shorter HTML file, and only 1 tiny javascript file: /ig_common/webbars2/ig_weblistbarNS4.js.
In other words, the control decided on the server-side that your user's browser is an ancient Netscape 4 browser, and thus it supports extremely limited functionality. In addition to this file, the "Netscape 4" users would also need to get the HM_Arrays.js, which, for whatever reason doesn't load well from the server. But, like I mentioned, it is merely a side-effect of the problem, and not the actual cause.
3. The actual reason for this error in browser detection occurs due to a user-agent string that is too long. In my case, I was able to prove (with Fiddler) that when the user-agent string is longer than 240 characters (the value itself), Infragistics goes totally crazy and thinks that the user's browser is a Netscape 4, which then breaks everything else. Here is an example of my user's user-agent string, which took the UltraWebMenu out of control:
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MDDR; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; OfficeLiveConnector.1.4; OfficeLivePatch.1.3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C)
The solution: see if this reasoning applies to you (you can look at your IIS logs, perform a TCP dump using Wireshark, or use Fiddler to capture HTTP traffic and then look at the user-agent string), and if yes, then: in your registry, Go to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent, and you will see a list your supported User-Agents. I'm sure you don't need all of them. Take one out (such as of these .NET CLRs), and try again. Here is a link explaining how to remove User-Agent values: http://www.pctools.com/guides/registry/detail/799
Once you get back to the "safe" 240 characters limit, your web page will render perfectly well. I recommend to remove a couple of extra user-agent settings and buy yourself a little "cushion," just in case your user will add something in the future, and it will bounce back beyond the safety limit.
Good luck!
-- Isaac
this might not be the best solution, but its a solution.
The thought to tamper with the http headers struck me out of the blue so I started researching IHttpHandler and IHttpModule and quickly realized that these structures recieved the request to late in the game to be of use. So I was stuck with writing a custom ISAPI filter. Basically the filter catches incomming requests that have a User-Agent of MSIE 8. and replaces the User-Agent with a generic IE 7 User-Agent "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)".
Seems to work well, the UltraWebMenu is working and Request.Browser.JavaScript returns true when browsing in IE8 release
Yes and No, in 2008.3 (which we have a license for) there is no .NET 1.1 version (on top of that I'm sure it would have the same issue due to the framework on which it is built). We are currently in the process of updating our product to .NET 3.5 and are close to the end of the project.
The problem is that we are trying to find a workaround so that our existing customers that download IE 8 can survive this transition. I am fully aware that 6.1 is not supported, all things have an end in the development cycle... well unless Microsoft is concerned (which it is). More of what I'm looking for is a hack, cheat, trick, or any other dirty method that might put off the inevitable. I'd really like to avoid the term "Royally Boned" when talking to our customers.
Thats more the intention of my post, rather than asking for a fix I'm just need some insight to the code, if there is ANY kind of method that I can use to de-break this for a couple more months.
The maintenance period of NetAdvantage for .NET 2006 Volume 1 ended prior to the release of Internet Explorer 8. This means that no further code changes are being made to this version, such as to introduce compatibility with Internet Explorer 8.
We're working toward compatibility with Internet Explorer 8 in our upcoming release of NetAdvantage for Web Client 2009.1. We won't have all of the regression testing completed as we'd like, since the browser was only released-to-market very recently.
Due to the magnitude of the required changes, earlier verisons of the toolset are not likely to be updated for Internet Explorer 8 compatibility.