Skip to main content
Home Forums Silverlight Programming Report a Silverlight Bug Silverlight 2 RTW not working with IE6
44 replies. Latest Post by peteot on July 16, 2009.
(0)
Pat Pann
Member
0 points
9 Posts
10-28-2008 12:47 AM |
I have an app that worked fine with beta 2 under both IE6 and IE7 when deployed to a web server but when I upgraded to RTW and deployed the app to the web server it would only run under IE7 and not IE6.
I have created a simple "Hello World" app that reproduces the problem (see code below). Has anyone run into this and have a solution?
.xaml code>>>
<
</
code behind>>>
using
{
InitializeComponent();
}
proxy.GetHelloWorldAsync();
myTextBox.Text = ex.Message;
myTextBox.Text = e.Error.Message;
WEB SERVICE>>>>>
[
StefanWick
Contributor
2864 points
438 Posts
10-28-2008 1:31 AM |
What exactly is the error/problem you are seeing in IE6?
Thanks, Stefan Wick
early_ad...
6 points
3 Posts
10-28-2008 11:11 AM |
Hello,
I have not tried the Hello world app, but have tried to run the other application that Pat originally compiled with RTW & ran into the problem on IE 6. The error message just says 'Arguments not found' so the error text did not show up for me as the end-user. However, I did trace http headers & got the following on IE 6. The original app also runs on IE 7 & Firefox 3. This led us to believe there was a problem invoking the web service when invoked thru IE 6. So, Pat tried the simple 'Hello World' app & it looks like we're still not able to invoke a web service when the app is run on IE 6:
HTTP/1.1 304 Not Modified
10-28-2008 1:19 PM |
Stefan,
Below is the exact error message...again only in IE6.
[BrowserHttpWebRequest_WebException_RemoteServer]
Arguments:NotFound
Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See http://go.microsoft.com/fwlink/?linkid=106663&Version=2.0.31005.0&File=System.Windows.dll&Key=BrowserHttpWebRequest_WebException_RemoteServer
vijaydev...
111 points
25 Posts
10-28-2008 4:54 PM |
Hello Pat
This is a known issue with Silverlight on IE6. The workaround is to either a) not compress the content before sending it on the wire, or b) to not set the Cache-Control header to no-cache.
Thanks
Vijay
10-28-2008 4:58 PM |
Hi Vijay,
can you provide more detail on how to implement these changes - ie., how to 'not compress the content' or change to no-cache?
will either or both cause a performance degradation?
thanks,
Pat's co-worker who is an end-user
10-28-2008 5:26 PM |
The resources below might help you more (these are specific to IIS):
The first one will likely cause a performance hit (exactly how much depends on your scenario and the content you're sending across the wire, of course). The second though is likely to *improve* performance, because removing Cache-control=no-cache will actually turns on browser caching.
Hope that helps
10-31-2008 11:02 AM |
So Vijay what does this mean? Is Microsoft saying Silverlight does not run on IE6 or will the problem be fixed?
Re: the no-cache setting workaround, there is no such setting to be removed from the .net pages. Where should I expect to find the setting that should be removed?
10-31-2008 12:53 PM |
This is a known issue that, unfortunately, currently has no workaround. We definitely plan to fix it in the following release; but like I said, for the time being, to get this scenario to work in on IE6, you're going to have to either disable compressing the content (on the server side), or have the server not set the Cache header to no-cache.
I don't expect the .NET pages to have any information on removing the cache setting because that's a part of the HTTP protocol. What are you using to host your web server (i.e. IIS?), and do you have control over how the server is configured?
10-31-2008 1:12 PM |
We are using IIS and I can get access to it. Please advise where I can find the no-cache setting to remove and if it can be done for only the app in question (as opposed to all apps on the server).
Thank you.
10-31-2008 1:24 PM |
What version of IIS are you using? I'll follow up with the IIS team and try to get you some information.
10-31-2008 1:54 PM |
We're using IIS V6.0
kwatts
2129 points
436 Posts
10-31-2008 2:52 PM |
Pat,
Can you post a link to your Silverlight application so that other users can test this and verify that it is a genuine problem with IE6 and not just an issue to your specific installation of IE6?
Thanks!
-Ken
10-31-2008 4:17 PM |
Ken,
Microsoft has confirmed there is an issue with Silverlight and IE6 (although they haven't detailed the exact nature of the problem they are aware of).
As far as the app is concerned, it's on an internal site and is not accessible outside the company. If you refer to the first entry at the top, I have included code for a simple "Hello World" app that reproduces the problem. The Silverlight app makes a simple web service call to get "hello world" from the web server and display it in the Silverlight page. Both the Silverlight app and web app are hosted in the same web folder.
Pat
11-03-2008 12:21 PM |
Pat, here's some more information on modifying these settings off:
247404 How to Modify the Cache-Control HTTP Header When You Use IIS
http://support.microsoft.com/default.aspx?scid=kb;EN-US;247404
234067 How to prevent caching in Internet Explorer
http://support.microsoft.com/default.aspx?scid=kb;EN-US;234067
11-05-2008 11:35 AM |
Vijay,
I set "no-cache" using both IIS HTTP Headers properties and also with the adsutil.vbs and neither method resolved the problem.
To summarize, Silverlight 2 RTW does not work with IE6. The simple Silverlight "Hello World" app that makes a web service call to the same web folder to get a "hello world" string does not work when using Silverlight 2 RTW and IE6. The app runs fine under IE7 and FireFox and had run without problem using IE6/Silverlight beta 2. Although the example is for a simple "Hello World" app, we are experiencing the same issue with a production application and it is affecting a large number of our users who are still on IE6.
Surely, there has to be a workaround to this issue???
When will the next Silverlight update be released to correct this problem?
scindy
54 points
15 Posts
11-07-2008 10:39 AM |
I am having the same problems.
The exception is that this does not seem to be a IE6 problem.Hosted on Windows 2003 with IIS 6 - This works.Hosted on Windows 2008 with IIS 7 - This does not work.
So does anyone know why it would work in one and not the other?
11-07-2008 11:00 AM |
We will need more information to help debug.. your problem seems different from Pat's if it happens on other browsers as well.
What is your exact setup (where is your XAP hosted, what URL are you trying to access, is your content compressed or cached), and exactly what behavior are you observing (exception? error message? fiddler output?)?
Lucidiom
4 points
2 Posts
11-14-2008 10:38 AM |
We are seeing exactly the same behavior that Pat has documented with our production Silverlight 2 RTW app. Our web farm is served from Windows 2008 / IIS7. The web services calls work fine for clients running IE7, FF3, and Safari, but not IE6.
We have had to take the drastic step of temporarily barring access to our site for IE6 users -- 20% of our user base!
Please update the group as soon as possible on any additional workarounds or fixes.
Thanks,Jason
11-14-2008 12:41 PM |
Can you confirm that you are not also doing both the following?
If not, then this is a new issue, and the following will help us reproduce your problem in-house and debug the problem quickly:
11-14-2008 1:11 PM |
I had previously confirmed to you that the two cache settings were attempted and made no difference. If you're looking for source code to a stripped down app to recreate the problem please take a look at the source code in the first entry to this thread. That simple "Hello World" app reproduces the problem.
11-14-2008 1:26 PM |
To confirm, we did try the making the two changes you specified. (The 2nd article didn't cover IIS7 directly, but we figured it out.)Enacting these two changes did not fix the problem for us.
Pat's sample is probably the smallest soure code example possible, so I don't think we could add much by submitting our own. If there is anything else we can do to help, though, let me know.
11-14-2008 2:41 PM |
Just want to re-iterate the urgency with this request. We were ready to embrace Silverlight technology, however this is a major stumbling block for us. We had to backout Silverlight from a new web app that we are developing, because we're unable to get it to work with 2.0 RTW. The prototype worked well with the beta release, however, we have more than 1000 users on IE 6 & cannot afford to roll out a tool that does not work on IE 6.
How close are you to finding a solution? When will Microsoft provide a fix for this issue?
thanks,early_adopter
11-14-2008 5:07 PM |
We've assigned this a high priority and are actively looking into this problem; I'll post status updates to this thread as and when we make progress.
However, even if we do have a fix ready and tested, the earliest vehicle for shipping such a fix out would be a GDR update on top of v2, which is still under consideration, and for which the exact schedule is still not known. I'm hoping that as we investigate the problem further, we'll be able to come up with a workaround for you to implement in your app for the time being. We'll keep you posted.
In the meantime, it would definitely help me if you could share out a sample VS solution that demonstrates the problem. IE6 was one of the browsers that was tested prior to releasing v2, so I'm quite sure that there isn't a basic bug here that keeps all networking calls from working on IE6. (What Pat has shared out above is one example that I'm still trying to use to reproduce the problem in-house; but you might be facing a different issue).
11-14-2008 8:15 PM |
By the way, I just confirmed that I cannot reproduce the problem that Pat complains of, either with the HelloWorld sample he posted at the top of this thread, or with the sample posted here: http://silverlight.net/quickstarts/webservices.aspx. I was on Windows Server 2003 running IE6 and the RTM bits of SL v2.0.
This confirms my suspicion that there's something else in your various environment setups that could be causing a problem. If anyone else is facing issues on IE6, please a) share a standalone app with us for repro purposes, and b) please look carefully at your environment (proxy settings? response headers being set by the server? are you on official RTM bits? etc.), and let us know.
Jerald X...
12-22-2008 11:35 PM |
1. I have a SL (v2.0) application that connects to a web server (apache). When compression (gzip) is enabled, I get exception in my application in IE6. Vijay says that this is a known issue with Silverlight on IE6 and suggests not compress the content or remove the 'Cache-Control' header. As per this, I removed the 'Cache-Control' header on apache (but compression was on). Still I get the same problem in IE6. I used Fiddler to capture the response header that is given below.
HTTP/1.1 200 OK Date: Tue, 23 Dec 2008 04:26:40 GMT Content-Type: text/html;charset=ISO-8859-1 Pragma: No-cache Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 1120 Keep-Alive: timeout=120, max=97 Connection: Keep-Alive
Following is the exception I see in the application.
The remote server returned an error: NotFound at System.Net.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult) at System.Net.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState) at System.Net.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState)The remote server returned an error: NotFound
2. I face the same issue when I connect to the same page using SSL (https) even when the compression is turned off.
Any help (other than the option to use IE7) would be much appreciated.
johndd
260 points
76 Posts
01-02-2009 6:34 AM |
We've found another work around here. Rather than switching off caching and compression on the server you can disable this from the browser (only necessary for IE6) by turning off "Use HTTP 1.1 " settings in the advanced options.
This might make more sense if you have a larger IE7 user base and can find a way to set this by group policy (which seems likely if you're running in an intranet situation).
01-02-2009 10:59 AM |
Hi scindy,
I think compression was off by default in IIS6 (you had to add the gzip.dll as a web service extension), while in IIS7 it is on by default for static content (like the clientaccesspolicy.xml file).
01-02-2009 11:11 AM |
Got this working on all browsers.What I did was install the IIS 6 Compatibility on IIS 7 and everybody was able to start using the application on IE 6 and 7 without any problems.
01-05-2009 1:38 AM |
The workaround given by johndd (turning off 'Use HTTP 1.1' in IE) essentially tells web server not to send compressed content to the browser. When a web client (e.g. browser) makes a http request, it sets a request header 'Accept-Encoding' to indicate to the web server that if it can receive content in compressed form or not. Web server will not send the content in compressed form if this header is not set even though the compression is turned ON.
Compression is very critical for performance. Also, the above workaround does not work when https is used. Data encryption is another critical requirement to transmit sensitive data in enterprise applications.
peteot
19 points
22 Posts
01-05-2009 10:48 AM |
We are seeing this problem extensively (but unfortunately also intermittently) with both IE6 and IE7. The http header solution (pragma:no-cache; expires: -1) does seem to fix the problem (also for IE7). But this means that any server-side web service you want to access from IE6 (and IE7) need to have these headers (and therefore can also never be cached).
This really is unacceptable and Microsoft needs to devote someone to tracking down and fixing this problem. It is some kind of configuration for IE6 that is also possible, though less common, in IE7. You don't hear about all the AJAX sites having this problem so it seems to be specific to (or at least intensified by) Silverlight.
vknair
2 points
1 Posts
01-08-2009 4:06 PM |
We did couple of tests with our application and here's what we found:
Finally we decided to stick to option 1. This will create performance issues for IE6 users alone other browsers will function normally. The web server based setting would have degraded the performance for all clients. Also, our 100+ IE6 users are internal clients - so disabling HTTP 1.1 is not too bad.
We are testing one more option. At the F5 load balancer level, we want to test a script that will disable compression and caching for IE 6 clients only. This solution (if successful) will be the best option until we get a fix from MS since, IE6 clients does not have to use HTTP 1.0 for all web sites just to ensure that they can use the new Silverlight application. Also, techinicians won't need to update 100+ client machines. Also, IE 7 and other browser users will get the full benefit of compression and caching.
zmorris
10 points
6 Posts
03-03-2009 11:08 AM |
We just tried to demo our product to a potential customer and discovered he was using IE6 because all of the web service calls from the Silverlight client failed! Excellent! Thanks MS :(
We have not yet confirmed, but we assume he was running the latest (GDR1 2.0.40115.0) release as this was the first time he installed Silverlight. So it looks like this issue has NOT been fixed "in the next release"?
We don't even have any IE6 boxes on premises to test this for ourselves. Can anyone confirm that this problem is still not fixed in 2.0.40115.0?
Thanks.
03-03-2009 11:21 AM |
I'm sorry about what happened at your customer demo! I can confirm though that the bug was not fixed in the recent GDR update to v2 (2.0.40115.0). We do however have a fix for the bug in the latest builds of v3 (the 'next release' I was referring to), which will be available to the public sometime later this year (the schedule has not been finalized and I can't go into the details). As a temporary workaround, maybe you could try some of the solutions presented in this thread?
Timmy G
64 points
51 Posts
03-06-2009 12:04 PM |
I’m really disappointed to see this is not fixed in the latest patch. I’ve tried the workarounds suggested above and the only thing that has worked is to turn off Http 1.1 support in the browser which is really not an acceptable solution since we are developing an application to be used by the public. IE6 currently accounts for 20% of our web stats (yeah, that surprised me too). That means that now, 20% of our expected customer base is not going to be supported. Ouch! This is going to be a tough one to explain to the business folks – especially after a lengthy series of meetings to convince them to agree to using Silverlight in the first place.
Here’s the bottom line: IE6 is a supposedly a “supported” browser, yet you can’t call a web service from it. Not being able to call a web service from a RIA is about as bad a bug as I can think of. Therefore, I think MS either needs to : 1) “support” the browser by fixing the bug 2) provide concise guidelines on how to work-around the bug (a thread on a forum with hit and miss suggestions doesn’t count) or 3) take IE6 off the supported browser list.
a2005
37 points
39 Posts
03-09-2009 7:41 AM |
I fixed the problem by duplicating the WFC service to normal "ASMX" WebService. I created a ASMX service as a wrapper to WFC Service.
This bug is a killer for me and I can't wait for the unknown future version when this issue will be fixed completely.
It took me a bit of pain but at-least my application is working on IE6 and others.
I have added a flag in Web.Config so that when this bug is fixed, it will directly call WFC service.
Let me know if this trick works for you.
03-09-2009 9:37 AM |
We eventually got it to work with IE6 on an IISV6 web server as follows:
Go to IIS Manager on your web server, click on "Web Sites" folder (this folder is above your web root), open Properties, click Service tab, and uncheck both compress options under HTTP Compression section.
03-10-2009 10:57 AM |
Since the Microsoft Silverlight update (downloaded to my PC 2/26/2009), this bug has resurfaced in my application! I was using the pragra:no-cache; expires:-1 trick, which fixed the problem. Now I have the problem again. This only happens for me with SSL responses on IE7 and IE6. I have emailed the team at Microsoft who initially responded to some of my questions, but this has really gotten out of control. Not only did MSFT not fix this in the update, but they apparently made it worse. --Pete
mmatos
5 Posts
03-10-2009 12:22 PM |
After reading this post, our networking team has scrambled looking to see what changes were made to the networking code in the v2 update (GDR Vijay referenced a few times in this thread) and we can confirm that we indeed made no changes in our networking stack. Can you please provide more details of the "same" problem? Some people have said their issue only repros with IE 6, some have said it repros with IE 7. We're looking to nail down exactly what where the issue is so any more data or a fiddler trace with the new/same behavior would be helpful/.
The Silverlight team monitors these forums quite closely, as well as many other teams related to Silverlight within the company. We believe this medium of communication to be extremely useful for our developement and growth as a product so we encourage everyone to provide feedback as we go. Having said that, please understand that we are often left with difficult decisions about our product w.r.t to risk and cost benefit. The bug you are describing is a difficult one to fix because we are dealing with an older version of IE's networking stack. Many of these bugs were fixed in IE 7 and even more in IE 8 but because we are supporting IE 6 (a browser nearing its endlife: http://support.microsoft.com/gp/lifesupsps/#Internet_Explorer ), we are committed to making sure all scenarios work cross platform, cross browser. After much investigation and understanding of the situation, as well as feedback and direction from you all, we believe to have nailed down the issue and will provide a fix in the newest official release (new version, not update as the patch you downloaded was) of Silverlight. We understand the pain this issue has caused you and thank everyone for their patience and dedication in helping us move towards identifying the exact issue.
For the current v2 behavior, have you tried the following workaround below? Is this a viable solution for you?
"
03-10-2009 1:21 PM |
I posted additional detail at http://otoole.wordpress.com/2009/03/10/18/ including a screen shot of the response in fiddler. I also emailed team members at Microsoft who I had contacted before about this. You can go to http://tnm.mtuitive.com and see a messagebox appear with the exception "details." Here is what I've found: this affects IE6, IE7, and IE8. I am mainly concerned with IE7. Using pragma:no-cache;expires:-1 fixed the problem for a couple of months. Now I believe I am seeing the exact same behavior. I see the problem with using SSL; I don't see it when using plain old http. This is on a web host (Mosso) where I don't have that much control over the compression like you describe, however using Fiddler no decompression is required to view the response so I don't think it is compressed. I was online with Mosso for a couple of hours this morning before posting to this forum to make sure it wasn't a change they made on their end. We understand that it is hard to make Silverlight work on so many browsers, etc. This is exactly the pain most of us feel as web developers and one of the biggest advantages of using silverlight. Right now I am in a situation where any visitor to my site using IE is seeing this error. Any help is appreciated. If you feel you have the problem nailed down, please share exactly what you believe the problem is so that we can use that information to investigate workarounds. --Pete
03-11-2009 3:20 PM |
After a lot more testing and digging, I've pinpointed this problem to an interaction with SSL. In IE, you can go to Tools / Options / Advanced and check "Do not save encrypted files to disk". This clears up the problem for me. From reading online, it seems that preventing caching with this option unchecked leads to a bug where IE does not save the file to disk due to the cache restrictions, but then cannot load the file because it expects it be on disk. Checking this apparently causes everything to happen in memory. Many thanks to the forum post at http://silverlight.net/forums/t/55653.aspx for this tip. Asking users to check this box is a big problem, however. I saw one suggestion online about setting cache-control to private instead of none. However, the original workaround to the gzip/caching bug required that we prevent caching. This leaves me in a pickle with probably no choice but to prevent gzip on all responses which is a bummer with large XML responses coming out of WCF, and also harder to control than you might think via a web host. In summary, I think there are 2 IE bugs in play: 1. gzipped and cached responses cannot be read by IE 2. SSL responses with "Do not save encrypted files to disk" unchecked and no caching These both looks very similar. I still cannot understand why #2 started happening on multiple computers all of a sudden when no changes were made to the application. No changes were made to the computers either except via windows update. I'm not sure if Microsoft is aware of both bugs because they refuse to acknowledge formally what bug this forum thread represents or what the recommended workarounds are.
03-19-2009 12:04 PM |
I finally think I have a workaround. I've posted details at http://otoole.wordpress.com/2009/03/10/18/ --Pete
07-16-2009 2:18 AM |
FYI: I confirmed that this bug "disappears" with SL3. I even works if your app was compiled with SL2 but running in quirks mode with the SL3 runtime. Woohoo!
07-16-2009 11:57 AM |
And here we thought no one would notice :)
The bug is indeed fixed in Silverlight v3. Thanks for everyone's feedback and patience on this thread. This bug took a lot of moving parts on our side to figure out and fix in a reliable manner.
07-16-2009 12:03 PM |
Thanks for all the hard work on this, Microsoft guys. This was a huge headache for many of us and it's great to put this behind us. Silverlight 3 is really a big step up.
Silverlight 2 RTW not working with IE6