I've published a half dozen apps written in C# using Visual Studio and ClickOnce to IIS running on my development PC but with one solution, which has a VB.NET main project and C# class library, I'm getting an error message: Invalid URI: The hostname could not be parsed.
The app is being launched via the launch link in the publish.htm file. Edge asks if I want to open it. I click the OPEN button and the app is downloaded and the progress bar finishes and then there's the popup error message saying that the URL could not be parsed.
When I check the IIS logs it looks like this:
https://mypc/apps/foo/publish.htm 404 0 2 1
But if I paste the URL https://mypc/apps/foo/publish.htm into the Edge browser's address box, the page is opened in the browser without any issue:
So I don't understand the 404 error. The other apps, all of which can be launched without issue from their publish.htm page, are published in identical manner, to the same website location in sibling folders:
https://mypc/apps/foo2/publish.htm
The structural differences between this solution and the others are
the EXE project of this problem solution is written in VB.NET and there is another project in the solution written in C# that produces a class library and
in the problem solution on the EXE's Properties->Application tab, there are two buttons: Assembly Information and View Windows Settings whereas on all the other working apps there is no View Windows Settings button on that tab and
on the working applications there is a Manifest option on the Application tab, where one of the choices is "embed manifest with default settings" whereas on the VB project's Application tab there is no such Manifest dropdown visible.
I hope there is some clue in these details. What am I missing and how to proceed to troubleshoot this?
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 made a simple BHO using C# as per the below link :
http://www.codeproject.com/Articles/19971/How-to-attach-to-Browser-Helper-Object-BHO-with-C
BHO gets loaded when I open IE as Administrator(by right click on it and click Run as admin)
But same BHO is not getting loaded by IE when I open it in non admin mode.
Please advise.
You need to create and deploy both a x86 and x64 versions of your BHO if it is for public web sites, otherwise EPM is disabled by default for the IE Intranet zone.
Compare your IE Security zone settings on the Admin and user accounts.... you should be accepting the defaults set by your system administrators.
I have an application built in silverlight and it has a functionality that uploads an excel file and an image file on individual button clicks.
When I open the app on windows (Internet Explorer, Safari, Chrome) - it works smoothly.
When I open the same application on Mac, this functionality (image and excel upload) fails.
Button_1 to Upload Image - I do get the file dialog box, I select the file, but when I say Ok, I do not get any errors, but the image upload does not work (I do not see the image uploaded)
Button_2 to Upload Excel - I do get the file dialog box, I select the file but when I say Ok (Error message: Excel is already open but I have checked numerous times... Excel is closed)
This error I am getting is only on Mac Machines... On all windows machines, it works smoothly
Silverlight Version - 5.1.302, Mac - 10.7.5, Browser - Safari - 6.1.1
Any clues?
I have found solution for this. We need to make some security changes in the Safari settings. Following are the steps I tried and things working fine. 1. Open Safari
2. Open desired application where you have issue
3. Click Safari from Top Menu Go to Preferences Security Internet Plug-ins ( Click on Manage Website Settings )
4. Left Window locate Silverlight and select it.
5. After selecting Silverlight On right side window You will see “website you have opened” and a dropdown From Dropdown Select Allow Always and Run in Unsafe Mode
6. You will be prompted with some warning message – so that is ok… Say Ok and then click Done.
Close Safari completely – Make sure Safari browser is closed completely.
Open New Safari browser instance and launch application. Since I am running application in secure network - running application in unsafe mode do not cause any security level issues.
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.