I'm working with two ASP.NET (.NET 4.5, IIS 10.0.17763.1) projects. Both are affected by this problem. There are dozens other projects built using the same technology that are working fine.
When debugging, "e" followed by precisely 2050 "�" symbols are inserted into the output html in seemingly random places. There doesn't seem to be any pattern to where they show up.
How it looks like when I hit "Inspect" in Chrome:
<img id="cphHomeBannerMe���������[...]����������ain_ScrollingBanner1_firstImage"
"View page source":
type="text/css" media="screen" /e [multiline blank space] ><link href=
When I copy the output of "View page source" into notepad, the blank space is removed but "e" remains. So, for the above example it would be
type="text/css" media="screen" /e><link href=
Needless to say, it completely breaks the page layout.
Launching without debugging (ctrl+f5) launches the project normally.
The project is version controlled using TFS and runs well on other PCs.
This is fixed by unchecking Enable Browser Link and reloading the page. The option should be under a menu that has a little refresh icon as it's image - next to the debug dropdown in your toolbar.
If you want to know more, see: https://devblogs.microsoft.com/aspnet/browser-link-feature-in-visual-studio-preview-2013
ImageI am setting up my web application (working) in the Windows Server 2016 Environment which has the IIS role set up. My application outputs the following error when I try to run it: "The page you are requesting cannot be served because of the extension configuration" error.
I have a simple application that has a label and needs to change the text of label on Page Load. My .aspx files work if I don't mention the CodeBehind file .aspx.cs file .
I believe this is a case of .aspx.cs file access. I have a much bigger application and I made this small one for asking this question. My guess is that I cannot access my .aspx.cs file.
I have tried adding "allow fileExtensions=".cs" ....." and this add cs to the list of allowed files. I have also tried using the aspnet_regiis -i to install asp.net which worked correctly.
As for my setup, I have added the IIS role, installed the ASP.NET 4.5 and its Extensible feature and also ASP.
<%# Page Language="C#" AutoEventWireup="true" CodeFile="Intro.aspx.cs" Inherits="Intro" %>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
</head>
<body>
<asp:Label . ...../>
</body>
</html>
UPDATE :Thank you all for your responses. This stackoverflow community is great . As for the solution I enabled .NET 3.5 features , .net 4.5 features, and all features related to a Web Server . A more concrete answer would help but this worked for me. Thank you all .
Web.config
I recently upgraded to IE9-beta. Now, In my .Net (3.5) WinForm application I want to use WebBrowser control.
So my question is, whether the WebBrowser control will exhibit all properties and functions of IE9?
My concern is, I want to render some SVG graphics on it.
WebBrowser control will use whatever version of IE you have installed, but for compatibility reasons it will render pages in IE7 Standards mode by default.
If you want to take advantage of new IE9 features, you should add the meta tag <meta http-equiv="X-UA-Compatible" content="IE=9" > inside the <head> tag of your HTML page.
This meta tag must be added before any links to CSS, JavaScript files etc that are also in your <head> to work properly though (only other <meta> tags or the <title> tag can come before it).
An alternative is to add a registry entry to:
HKLM > SOFTWARE > Microsoft > Internet Explorer > Main > FeatureControl > FEATURE_BROWSER_EMULATION
And in there add 'myApplicationName.exe' with value '9000' to force the WebBrowser control to display pages in IE9 mode. Though there are other values you can use too too, note that these docs aren't entirely accurate as it does not seem possible to get a page to render in IE 8 mode whatever value you use.
Adding the registry key to the same path in HKCU instead of HKLM will also work - this is useful as writing to HKLM requires admin privileges where as HKCU does not.
The IE9 "version" of the WebBrowser control, like the IE8 version, is actually several browsers in one. Unlike the IE8 version, you do have a little more control over the rendering mode inside the page by changing the doctype. Of course, to change the browser mode you have to set your registry like the earlier answer. Here is a reg file fragment for FEATURE_BROWSER_EMULATION:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"contoso.exe"=dword:00002328
Here is the complete set of codes:
9999 (0x270F) - Internet Explorer 9.
Webpages are displayed in IE9
Standards mode, regardless of the
!DOCTYPE directive.
9000 (0x2328) - Internet Explorer 9. Webpages containing standards-based !DOCTYPE
directives are displayed in IE9 mode.
8888 (0x22B8) -Webpages are
displayed in IE8 Standards mode,
regardless of the !DOCTYPE directive.
8000 (0x1F40) - Webpages containing
standards-based !DOCTYPE directives
are displayed in IE8 mode.
7000 (0x1B58) - Webpages containing
standards-based !DOCTYPE directives
are displayed in IE7 Standards mode.
The full docs:
http://msdn.microsoft.com/en-us/library/ee330730%28VS.85%29.aspx#browser_emulation
Thank goodness I found this. The following is extremely important:
<meta http-equiv="X-UA-Compatible" content="IE=9" >
Without this, none of the reports I'd been generating would work post IE9 install despite having worked great in IE8. They would show up properly in a web browser control, but there would be missing letters, jacked up white space, etc, when I called .Print(). They were just basic HTML that should be capable of being rendered even in Mosaic. heh Not sure why the IE7 compatibility mode was going haywire. Notably, you could .Print() the same page 5 times and have it be missing different letters each time. It would even carry over into PDF output, so it's definitely the browser.
A note about 64bit Windows which seems to trip up a few folks.
If your app is running under 64bit Windows, you likely have to set the DWORD under [HKLM\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION] instead.
Just to be complete...
For 32 bit OS you must add a registry entry to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
*******OR*******
For 64 bit OS you must add a registry entry to:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
This entry must be a DWORD, with the name being the name of your executable, that hosts the Webbrowser control; i.e.:
myappname.exe (DON'T USE "Contoso.exe" as in the MSDN web page...it's just a placeholder name)
Then give it a DWORD value, according to the table on:
http://msdn.microsoft.com/en-us/library/ee330730(v=vs.85).aspx#browser_emulation
I changed to 11001 decimal or 0x2AF9 hex --- (IE 11 EMULATION) since that isn't the DEFAULT value (if you have IE 11 installed -- or whatever version).
That MSDN article contains notes on several other Registry changes that affects Internet Explorer web browser behavior.
I know this thread is old and there are already comprehensive answers.
Just in case you don't know this:
<meta http-equiv="X-UA-Compatible" content="IE=edge" >
You don't have to hardcode IE version number as
<meta http-equiv="X-UA-Compatible" content="IE=9" >
I totally agree with the solution provided, but I think a little clarification is important I think, might be necessary.
For each process (read also: vshost.exe, yourWinformApplication.exe.svchost, or the name of your application.exe) that will need to add a DWORD with the value provided, in my case I leave 9000 (in decimal) in application name and running smoothly and error-free script.
the most common mistake is to believe that it is necessary to add "contoso.exe" AS IS and think it all work!
Yes, WebBrowser control uses whatever version of IE you have installed. This means of course that if you run your application on a machine with IE 8 then the IE 9 features you depend on will not be available.
I came to this solution and it did not worked for me! Because I was using 64bit I had to replace the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
Instead of the one that everyone talks about:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
I liked the (C#) code in the following which sets the registry settings for your app. Not sure if it will cut it after installation though if permissions are required. For me it solved an issue with WebSocket not being available inside a WebBrowser control in WPF.
C# webbrowser Ajax call
I had the same problem, and the registry answers here didn't work.
I had a browser control in new version of my program that worked fine on XP, failed in Windows 7 (64 bit).
The old version worked on both XP and Windows 7.
The webpage displayed in the browser uses some strange plugin for showing old SVG maps (I think its a Java applet).
Turns out the problem is related to DEP protection in Windows 7.
Old versions of dotnet 2 didn't set the DEP required flag in the exe, but from dotnet 2, SP 1 onwards it did (yep, the compiling behaviour and hence runtime behaviour of exe changed depending on which machine you compiled on, nice ...).
It is documented on a MSDN blog NXCOMPAT and the C# compiler. To quote : This will undoubtedly surprise a few developers...download a framework service pack, recompile, run your app, and you're now getting IP_ON_HEAP exceptions.
Adding the following to the post build in Visual Studio, turns DEP off for the exe, and everything works as expected:
all "$(DevEnvDir)..\tools\vsvars32.bat"
editbin.exe /NXCOMPAT:NO "$(TargetPath)"
Editbin documentation
Dumpbin /headers will display the DEP setting on a exe.
Regarding whitehawk's accepted answer.
I am just trying to add a bit hands on experience. Was just trying to add a comments, but SO complains it's too long.
Basically, without IE 9 installed, the registry switch FEATURE_BROWSER_EMULATION won't work AT ALL.
For example, my own experience today I was trying to get the .net webcontrol to work with IE10 mode because one html I am trying to render won't work with .netControl under VS2012, and not even work when I load the html to IE8 directly, still css won't render properly(even after I say allow blocked content). But I have tested the same html ok with IE10 on a friend's win 8 machine. That's why I am trying to set the .net webControl to IE 10 mode but just keeps failing...
Now I figured this is bcos my win 7 machine only have IE8 installed, so regardless which value I set to the FEATURE_BROWSER_EMULATION switch(value to IE9, IE10 IE11), it just won't work AT ALL !
Then I downloaded and installed IE 10 on my win 7 machine. Still it won't work, then I added the FEATURE_BROWSER_EMULATION, it started working !
Also I noticed regardless which value I set , even set it to value 0 by default, the webControl is still using IE 10 mode which still works for me.
So to summarise,
If you have IE X installed but you want your .Net webControl to work under IE (X+N) N>0 modo, TWO things you need to do:
Go to MS website & download and install IE (X+N) on your machine,
you will need to reboot after installation.
apply whitehawk's answer.
Basically:
To control the value of this feature by using the registry, add the name of your executable file to the following setting and set the value to match the desired setting.
HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)
SOFTWARE
Microsoft
Internet Explorer
Main
FeatureControl
FEATURE_BROWSER_EMULATION
contoso.exe = (DWORD) 00009000
Windows Internet Explorer 8 and later. The FEATURE_BROWSER_EMULATION feature defines the default emulation mode for Internet Explorer and supports the following values.
Value Description
11001 (0x2AF9 Internet Explorer 11. Webpages are displayed in IE11
edge mode, regardless of the !DOCTYPE directive.
11000 (0x2AF8) IE11. Webpages containing standards-based !DOCTYPE
directives are displayed in IE11 edge mode. Default value for IE11.
10001 (0x2711) Internet Explorer 10. Webpages are displayed in IE10
Standards mode, regardless of the !DOCTYPE directive.
10000 (0x02710) Internet Explorer 10. Webpages containing
standards-based !DOCTYPE directives are displayed in IE10 Standards
mode. Default value for Internet Explorer 10.
9999 (0x270F) Windows Internet Explorer 9. Webpages are displayed in
IE9 Standards mode, regardless of the !DOCTYPE directive.
9000 (0x2328) Internet Explorer 9. Webpages containing
standards-based !DOCTYPE directives are displayed in IE9 mode.
Default value for Internet Explorer 9.
Important In Internet Explorer 10, Webpages containing
standards-based !DOCTYPE directives are displayed in IE10 Standards
mode.
8888 (0x22B8) Webpages are displayed in IE8 Standards mode,
regardless of the !DOCTYPE directive.
8000 (0x1F40) Webpages containing standards-based !DOCTYPE directives
are displayed in IE8 mode. Default value for Internet Explorer 8
Important In Internet Explorer 10, Webpages containing
standards-based !DOCTYPE directives are displayed in IE10 Standards
mode.
7000 (0x1B58) Webpages containing standards-based !DOCTYPE directives
are displayed in IE7 Standards mode. Default value for applications
hosting the WebBrowser Control.
Full ref here
I have .NET Framework 2.0 project and AxWebBrowser control runing on Windows 7 with IE9 web browser.
When I put this code to my IE9 web browser:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=9">
</head>
<body>
<script>alert(document.documentMode);</script>
</body>
</html>
I get value 9 - so it's correct.
But when a put the same code to AxWebBrowser in my project, I always get value 8 and my HTML5 code doesn't work properly.
Where is the problem?
You will have to use registry to enable Internet Feature Controls and set the IE version that you would like to use.
Here is a sample registry file:
(Don't forget to replace YOURPROGRAM.EXE with the name of your executable)
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"YOURPROGRAM.EXE"=dword:00002328
This can also be done dynamically from code.
Of course, if IE9 is not installed on the client computer you won't be able to use HTML5, then you can consider using another webbrowser control, there are plenty of them online.
See this page for more details: http://msdn.microsoft.com/en-us/library/ee330730%28VS.85%29.aspx#browser_emulation
I solve the problem. The problem is that there are two FEATURE_BROWSER_EMULATION, one is "Wow6432Node", the other one without "Wow6432Node"
I have a C# .NET windows application that will get HTML files and use them to display data. The HTML files will have javascript in them to help parse/display the data, and one of them uses an activeXObject to display PDF files.
When I install a binary version of the windows application, the PDF file displays properly and is fine.
When I am running from DEBUG mode from VS2008, i get the error:
Failed to load details page. An
exception occurred in the script.
Error name: TypeError. Error message:
Object doesn't support this property
or method
They are both referring to the same HTML page, the only difference is one is a binary install and the other is just my DEBUG build running.
I need to get it working in DEBUG mode so I can test but I'm not sure what's wrong; Any suggestions would definitely be appreciated!
Edit: Sorry here is the HTML Code:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Received Fax Preview Page</title>
</head>
<body>
<object data="myfile.pdf" type="application/pdf" width="800" height="600">SUP</object>
</body>
</html>
And i'm just using the C# web browser to display it.
_webBrowser.DocumentText = htmlDoc;
Finally got it to work by switching to x86 platform in VS (from Any CPU) and building the project. I'm guessing since my machine is x64, in debug mode the application targets all x64 components and IE x64 can't load PDFs, but maybe in the binary (which is x64) it goes to the common IE x86 bit to open the PDF?
Not 100% sure the explanation, but it is working now.