Communication between .NET WebView2 client and web page using JavaScript PostMessages

When embedding a web page in your Windows desktop or mobile application usually one requires to have some kind of communication between them.  

In the old Internet Explorer days, the WebBrowser component was the way to go and a web page could send a message by writing  it on the status bar. The application would then read the status bar content and this simple mechanism allowed some kind of communication.
These days Internet Explorer and the status bar are pretty much dead and there are different ways to communicate.

The WebView2 is the current way to go (get it from NuGet) and even it it is a far more complete and complex component, upgrade is not really that hard for the basic stuff such as getting the event of document complete or location has changed.

WebView embraces new ways for interoperability between the application and the web page.
One simple way to replace the status bar messages mechanism is to use the ExecuteScriptAsync to execute JavaScript code to read information from your page. For instance, using the old hidden field trick as a message store.

But new and more powerful ways are available to have better communication.
While researching on this topic, I found a post that describes multiple ways to reach this goal, like using "postMessage" and "hostObject": Chromium WebView2 Control and .NET to JavaScript Interop - Part 2 

Microsoft also has tutorials on this:

• Get started with WebView2 in WinForms apps (check Step 10 if you know the basics)
• Interop of native-side and web-side code

./M6

Setting up C# development environment in Linux

Recently I got curious in  .Net development on Linux environment.

I am aware of the Mono Project, but wanted to keep it as "pure" as it could be, meaning that I wanted to be, as much as possible, a Microsoft development environment.

I'm a long time Kubuntu user when it comes to Linux desktop, and I'm also a Visual Studio Code user for quite sometime.

 

.Net SDK

Starting with the basics, and already having VS Code installed, I started by installing .Net (Kubuntu is not mentions, just use Ubuntu as the reference) simply using 

sudo apt update
sudo apt install -y dotnet-sdk-7.0

That pretty much takes care of having .Net SDK installed.

VS Code IDE

Next step was to set up VS Code as the IDE.
This was achieved by installing the following VS Code extensions:

• C# (ms-dotnettools.csharp)
  
• C# Dev Kit (ms-dotnettools.csdevkit)

As a hint, pressing CTRL+SHIF+X on VS Code and searching for ms-dotnettools  on the extensions marketplace will list a lot of useful things.

Hello World

Once the basic was in place, it was time to try it out.
On a terminal, I typed the following commands to set up a Hello World console application:

mkdir HelloWorld
cd HelloWorld
dotnet new console

And a new console application was created printing "Hello, World!" into the terminal.
As a hint, type "dotnet help" for a list of available commands. Try also "dotnet new list" for a list of available templates.

Open the HelloWorld folder with VS Code, CTRL+K CTRL+O, and you can see generated code in the Program.cs file.

To build and run the application, just press CTRL+SHIFT+D and you'll be on the Run and Debug menu options. Having the ".Net Core Launch (console)" option selected and using "Start Debugging (F5)" will bring up the Debug Console and you'll be able to see the application execution.

Bonus | Desktop and Game Development

Don't get disappointed because it is not possible to develop desktop applications using Forms in Linux using C#.
It is possible to develop cross-platform games for desktop, or other kind of graphical applications, using SDL2 and OpenGL.
For that, and as Microsoft refers, it is possible to use MonoGame, just check the DesktopGL, template mgdesktopgl.
Keep in mind that packaging  and distribution is available, start coding and have fun.

To package and distribute, you can .

./M6

How to setup VSCode launch.json for Xdebug version 2

I had to make some maintenance on a web application using Yii 1.1.4 framework running on PHP 7 and for that, I set up an Ububtu 18.04 LTS Desktop on a virtual machine. 

After the usual bunch of "apt-get install" commands and a few configurations, I got the new development environment up and running having Visual Studio Code as my IDE.

But, almost as soon as I got it running, I got the need to step debug it. For that, I went to Xdebug, I installed it via "apt-get" and configured it, but it was not working as expected.
I check the configuration parameters and give it another try. No go. Xdebug was installed, PHP was recognizing it on both cli and web, but it was still not working.
After a few seconds, I spotted the issue: it was a Xdebug version 2!

A lot has changed between version 2 and 3 of Xdebug.

The thing was that I wanted to keep version 2, and for that I had to configure "launch.json" file and Xdebug in the appropriate way.

On PHP configuration file:

zend_extension=xdebug.so
xdebug.idekey=XDEBUG_VC
xdebug.remote_port=9003
xdebug.remote_enable = 1
xdebug.remote_autostart = 1

 

And on "launch.json":

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
       
        {
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "port": 9003
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 0,
            "runtimeArgs": [
                "-dxdebug.remote_autostart=yes"
            ],
            "env": {
                "XDEBUG_MODE": "debug,develop",
                "XDEBUG_CONFIG": "client_port=${port}"
            }
        },
        {
            "name": "Launch Built-in web server",
            "type": "php",
            "request": "launch",
            "runtimeArgs": [
                "-dxdebug.mode=debug",
                "-dxdebug.remote_autostart=yes",
                "-S",
                "localhost:0"
            ],
            "program": "",
            "cwd": "${workspaceRoot}",
            "port": 9003,
            "serverReadyAction": {
                "pattern": "Development Server \\(http://localhost:([0-9]+)\\) started",
                "uriFormat": "http://localhost:%s",
                "action": "openExternally"
            }
        }
    ]
}

The default port is 9000, but I'm used to have Xdebug on 9003, so I reconfigured it. The remaining parameters are, basically, the version 2 way of activation the debugger on a request.

./M6