I have this problem where the web application that I have created in my development environment, displays differently after I upload it to the web server.
I am using the same browser and the same machine to view the pages. The only thing different, is the "server". I am using .net 3.5 and on my development environment the pages are served using the ASP.net Development Server. On the web server, the pages are served using IIS 6.0.
I have only a single CSS file that is contained within the "App_Themes/Default" folder that is used to control all the CSS in my application.
Here are some of the things that don't display the same:
1) I have a collapsible panel control that when expanded is supposed to show on top of all the other page elements. On the dev environment, it behaves correctly. On the web server, the panel slides underneath the other elements.
2) I have my element defined with a background and a certain font size. When displayed on my development environment, the text displays on one line. However, on the web server, the text is wrapped even though the text is the same size. It's as if the containing div is somehow rendered "smaller".
3) The width of buttons that do not have a fixed width (so the width is determined by the button text) is different between the development environment and the web server. The bottons on the server are always wider.
I checked to make sure there are no references to other CSS elements in the machine.config and global web.config on the server and on my development environment.
I know the server is reading from the CSS because in general, it looks similar (same colors, backgrounds, font style, etc). It's just that the sizes seems to be off and the layering of the divs.
Has anyone run in to this problem before? Any ideas of what I could look for?
Looks like you are comparing them in Internet Explorer 8. Microsoft introduced different rendering modes for local and Internet servers so that web developers would break down in tears.
If there’s no X-UA-Compatible value and site is in
Local Intranet security zone, it will be rendered
in EmulateIE7 mode by default.
Add X-UA-Compatible header or META to force full IE8 standards mode.
See also http://sharovatov.wordpress.com/2009/05/18/ie8-rendering-modes-theory-and-practice/
We were having an issue with compatibility modes too, so I ended up just adding:
<meta http-equiv="X-UA-Compatible" content="IE=Edge">
Since I knew it worked fine in IE7, 8, and 9.
I had the same problem in Google Chrome. Apparently media queries get messed up if the page is zoomed in or out. Make sure your zoom level is 100% for both sites.
This at least sounds like that the production server added a xml declaration to the HTML or changed the doctype which caused the page being rendered in non-standards-compliant mode. This is also known as quirks mode, you see this very good back in MSIE. The symptoms which you described are recognizeable as box model bug in MSIE.
Rightclick the pages and check the HTML source. Are they both exactly the same? (including meta tags, xml declaration, whitespace, etc)
If you're FTP'ing from Windows to Linux, please ensure that you're transferring in binary mode to ensure that the whitespace (spaces, linebreaks) remain unchanged. Also ensure that you're saving documents as UTF-8 (or at least ISO-8859-1) and NOT as MS-proprietary encoding such as CP1252.
For those of you that are having this problem in an Intranet site setting the meta tag won't fix the problem if "Display intranet sites in Compatibility View" is checked on (which it is in a lot of cases)
You have to send the HTTP response header at the server level, see here
The CSS that is coming from the server may be a older cached version - try refreshing the page using Ctrl+F5 so it get re-requested.
For me, Internet Explorer's Compatibility View Settings was the issue:
After the check-boxes were un-set, the CSS renders perfectly
We had the same issue, fixed on IE9 & IE11 with this:
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge"/>
</head>
Juste add this to your web.config file :
<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name="X-UA-Compatible" value="IE=8" />
</customHeaders>
</httpProtocol>
</system.webServer>
I had the same issue. Our network uses Win7 with IE11 throughout. For me the solution was to, on my local machine adding "localhost" to the list in IE's compatibility settings > "Websites you've added to compatibility View". IE > Tools > Compatibilty View settings.
BTW our NA has every machine setting IE11 to "Display intranet sites in Compatibility View" automatically checked by a group policy.
This often happens to me when the 'server' version is cached somehow. Refreshing did the trick. Throwing away 'temporary internet files' does it, too.
I just had this problem. I'd changed my style sheet and HTML code. It looked great on locally but didn't work on the server. I found that in Visual Studio the CSS file's "Copy to Output Directory" was set to "Do not copy". So my CSS updates were not getting deployed. Sometimes the problem is just user error.
Can be caused by minification, e.g. on dev machine you have
<span>AAA</span>
<span>BBB</span>
but on remote server it becomes
<span>AAA</span><span>BBB</span>
and a space between them gets lost.
try this,.
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />
Related
I have a web page that calls a .Net assembly. Everything works fine in Windows XP and IE7. The relevant parts:
<html>
<head>
<script language="javascript" type="text/javascript">
function doScript() {
myControl1.Go("value1","value2");
}
</script>
</head>
<body onload="javascript:doScript();">
<object id="myControl1" name="myControl1"
codebase="../cabs/myassembly.dll"
classid="../cabs/myassembly.dll#MyNs.MyClass"
width="1" height="1"></object>
</body>
</html>
I cannot get this to work in Windows 7 with IE8. Some notes:
The assembly is strong named.
I am hosting this on localhost right now.
On the machine that is working (VirtualBox-hosted WinXP, IE7), it is using an IP address to my local machine (http://1.2.3.4/...) and that IP is in the "Trusted Sites" of IE.
On the machine that is not working (Windows 7, IE8), it is using http://localhost/... and localhost is in the "Trusted Sites" of IE.
The assembly is being served from http://localhost/cabs/myassembly.dll.
The error message is a javascript error, "Object doesn't support this property or method"
Fiddler shows a 200 OK response when the file is requested, however, it does not appear that the dll is making it to the temporary internet files location.
The site is running in "IE 7 compatibility" mode.
I have dropped all IE permissions to the most insecure it will let you in all zones, and the behavior is exactly the same.
Does anyone have any ideas to try to get this to work or troubleshoot where the problem is at?
Disclaimer: Yes, I realize it is 2012, and the world has moved past IE7, IE8, ActiveX, etc. Let's just say we're a little bit behind technologically. This is the problem I have to solve; upgrading to modern solutions isn't going to be an option.
UPDATE: I did get it to work in a Windows XP VirtualBox running IE8. So it appears the problem is specific to Windows 7. It fails both on my local machine and a VirtualBox running Windows 7, IE8.
This was solved by adding the registry key answered on "Loading .NET UserControls in IE with .NET 4.0" (even though this was a 2.0 control)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"EnableIEHosting"=dword:00000001
I'm not sure that this will help, but I have had a similar issue and this has usually fixed it. Try these steps on the machine where it's not working.
Assign the domain of the url where the dll is located to the Trusted sites zone.
Open the Security tab in Internet Options and click Trusted sites
Click Default level and make sure that it selects Medium. If not, manually set it to Medium.
Apply
For good measure, close all IE windows and then relaunch and test if it works.
The key issue is the one that was discussed in the page that rene linked to in his second comment. As of IE8 and onwards, there is a security setting that does not have it's own UI in the Custom level list of options. The only way to affect it is by setting the Level - Medium or lower sets it to Enable while Medium-high higher sets it to Disable.
Now this might very well not be your problem, since usually the default level for Trusted sites is Medium which would enable the setting. But it's worth trying at least (maybe you have some Group Policy or something that has changed the default level of Trusted Sites).
Don't use .dll file. Use .cab instead.
I have installed Chrome Frame and it works on some sites but not on mine. I have the correct code from the Chrome tag site
<meta http-equiv="X-UA-Compatible" content="chrome=1" />
<!--[if IE]><script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"></script><![endif]-->
WHAT AM I DOING WRONG?????????
I haven't seen this behaviour before, but I will take a guess:
IE has a config setting which tells it to turn on compatibility mode for local intranet sites (that is, sites on your local network, which would include if you're running your site on your PC for testing). This setting is often defaulted to being switched on, without the user realising it.
The setting triggers IE to override any X-UA-Compatible tags in the site, and always force the site into compatibility mode.
This may be causing it to also override your Chrome Frame mode.
So check your browser settings, and if you have this flag switched on, turn it off and try again.
Bear in mind that if your site is for use on an internal network, then this flag may be set for most or all your users. (and if it's for an external site, then bear in mind that most users won't have Chrome Frame installed!)
Is this meta tag within the 1024 first bytes in the document?
So, I have an application that I test on my VS2010 virtual ASP.NET server, when I open it in IE on my local environment, everything renders fine, but whenever I deploy it to the external server, it starts to screw stuff up in IE (CSS and some jQuery problems). I have the same code everywhere, how is it possible to be rendering it differently? (I test them in the same IE version), everything works fine in other browsers.
It sounds like a compatibility-mode issue. In some cases, IE will jump into compatibility mode unexpectedly. This is often related to browser configuration.
Easiest way to preven this is to add the following meta tag to your HTML code:
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
This will force IE to always use the best available rendering engine, and prevent it jumping into compatibility mode, regardless of the browser config.
Hope that helps.
I have googled around for the answer to this question, but haven't come up with anything. Maybe the search terms I used were too generic... Anyway, here goes:
I am discovering the joys of web design and ASP.NET, and the nightmare of trying to get things to display in the same way in IE and all the other browsers.
I am working in VS2010 and debugging my website using IE8. What I really don't get is why the website once I publish it looks different in IE from the way it looks in debug mode... I mean small things only, like border in gridviews disappearing in the published site, simple html horizontal rules aren't the same either.
It also messed up my list menu pretty bad, but I managed to fix that with the *display: inline; hack. The weird thing is that it doesn't need it in debug mode, but needs it for the published website.
I am hosting the site on my own machine, running Win XP Pro and hosting through IIS with .NET 4.0... Could the issue be IIS related?
Any help would be much appreciated, because those differences are just ridiculous and are driving me to desperation. I wish everyone over here would use Chrome or Safari, but unfortunately IE still rules in Japan...
This works for me, overrides the setting in ie
META Tag in HEAD element of your web page (or better in master page)
<meta http-equiv=“X-UA-Compatible” content=“IE=8” />
link here to info
http://blogs.msdn.com/b/askie/archive/2009/03/23/understanding-compatibility-modes-in-internet-explorer-8.aspx
I find it better to override compatibility in the HTTP Reponse Headers in IIS, adding header:
X-UA-Compatible: IE=Edge
The IE=Edge part will set compatibility to use the highest mode available, will apply to all users, and also apply to all pages in the site whilst only having to put the header in one place.
I've seen similar behavior related to trusted sites/intranet sites/internet sites security settings. When you run in debug mode is the URL you are using different from when you publish it? I've seen sometimes when I debug using a URL like http://localhost/xxx and when I access the same site straight from IIS using a URL like http://machinename.domain.com/xxx that one resolves to a trusted site or local intranet and the other to internet and it changes the appearance based on the IE settings.
For those using ASP.NET MVC, you can add kgp4death's
<meta http-equiv=“X-UA-Compatible” content=“IE=8” />
to the head element in your _Layout.cshtml.
I think you did not have given the correct path in the <script src="path">. Please check your path and also check the related file u must place this file in the project folder
I hope this suggestion solve your problem
We have two servers, a development/test server (Win Server 2008) and a live server (Win Server 2003 SP2). Same ASP.NET code base deployed to both, everything works fine Except when printing on IE 8 using the live server.
The live server prints the content shifted to the right in a larger font size.
I just don't get it! It is worth noting that we are using a specific css file for printing:
<link href="/css/print.css" type="text/css" rel="stylesheet" media="print" />
Both servers are producing identical HTML source. I am not even sure where to start looking for trouble.
If the HTML is the same then it's probably the HTTP headers that differ. Check them. It may be a MIME-type issue or something like that.
I once had a web browser ignore my CSS file because the server was sending the wrong MIME type for the CSS file.
Check what mode IE8 is using in each case. You can do this using IE8's developer tools (Press F12, it's in the menu bar at the top).
If they are different, this is likely caused byt HTTP headers, as Artelius says.
It turns out, a body element's width was not set explicitly and for some reasons that triggered the original issue, until I figured that out I have forced IE7 emulation from IIS using http headers.