Hi,

I am not sure if I understand your scenario correctly. ASP.NET Razor is a server technology. So Razor code must first be processed by the ASP.NET Web Server. This would translate Razor code to standard HTML code. This HTML code is then sent from the Web server to the client side. The Web Browser runs on the client side then load, parse and display this HTML code.

Note that here "server" and "client" are logical entities, not physical entities. So you can run an ASP.NET Server and EO.WebBrowser all in your own application (you can search online on how to host an ASP.NET Web Server in your application). The key here is you can't feed the input meant for the ASP.NET Web Server directly to EO.WebBrowser. Razor code must first go to the server first. You would then access the server pages through Urls, this Url is then passed to EO.WebBrowser.

Hope this helps. Please let us know if you still have any questions.

Thanks!

Hi,

You can feed the WebView valid HTML. However a Razor file "looks like" HTML but it is not valid HTML. It is like a HTML "template" file that contains specific instructions for the Razor engine, which will interprets these instructions and finally output the real valid HTML through an Url request. Only ASP.NET Razor engine understand Razor instructions. A web browser does not understand Razor instructions. There are numerous server side technologies that works in similar way. For example, a php file also looks like a HTML file but it contains php code. Java Server page looks like HTML but it contains Java code. All those pages must be processed by their corresponding server side platform and "transformed" into standard HTML first. A Web Browser does not understand server side languages such as php or Java.

From the WebView point of view, with a few exception, eventually it will always need the HTML. You can either provide such HTML directly (for example, by calling WebView.LoadHtml), or provide the WebView something that it can get the HTML from (for example, a file name, a valid Url, etc). So the main different between provide the WebView a Url and providing HTML directly is when you provide the WebView an Url, it has to do the extra step of fetching the HTML from that Url. You could write your own code to fetch the HTML and then pass the result HTML to the WebView and you could have the same result.

In real life scenarios, stick with Url is the easiest because there are implications when you use HTML directly, primarily because very often the browser engine needs to know where that HTML comes from (for example, for security purposes). When you load an Url into the WebView the browser engine will have this "origin" information. When you load HTML directly to the WebView, it doesn't have such "origin" information.

Hope this helps.

Thanks