I’ve been tearing my hair out for the last couple of days – trying to work out why previous perfectly good apps completely crashed WebView2 using Visual Studio 2022!

Visual Studio 2022 smoothly allows WebView2 to be installed and loaded into the toolbox. But using it kept failing on:
 ‘WebView21_CoreWebView2InitializationCompleted(sender As Object, e As Microsoft.Web.WebView2.Core.CoreWebView2InitializationCompletedEventArgs) Handles WebView21.CoreWebView2InitializationCompleted’
Returning e.IsSuccess = False

With the message:
{“Couldn’t find a compatible Webview2 Runtime installation to host WebViews.”}

I repeatedly tried repairing & reinstalling Webview2 and Microsoft Edge WebView2 Runtime, trying many different versions – none worked.

Microsoft documentation for WebView2 suggests uninstalling Microsoft Edge – even though they also say WebView2 is completely separate (to avoid updates needing to be synchronised)

Yet Microsoft Edge can no longer be removed because it is now an integral part of Windows! But ‘repairing’ it didn’t help either.

My previously saved and packaged ‘release’ software from Visual Studio 2022 ALL still worked as ‘stand-alone’ apps, but copying working runtime files from these into newly created releases still failed.

Eventually I gave up with Visual Studio 2022 and went back to an app created with Visual Studio 2019 – and voila it worked fine, even allowing debugging! This wasn’t really going to solve my problem because all my latest apps use .net 8 which can’t easily be ported back to .net 4.8 Frameword

Nevertheless as an experiment I created a new app to test WebView2 using Visual Studio 2019 with .Net Framework 4.8 and that also worked first time! (after the usual fiddle to get WebView2 to appear in my toolbox)

Yet anything I tried creating in Visual Studio 2022 with .Net 6, 7 or 8 failed miserably.

In creating a new app in Visual Studio 2019 it wanted to use the default directory of:
c:/users/myname/source/repos/appname.

I changed it to where I save all my apps:
d:/myname/documents/VisualStudio2024 and it still worked.

Finally, I thought I would see what happened if I used Visual Studio 2022 to create and save a simple WebView2 app in:
c:/users/myname/source/repos/appname

And guess what – it worked first time!!!

In summary, if you are having problems with Visual Studio 2022 running WebView2 – make sure you work from your user /source/repos folder.

If only I could charge Microsoft for some of my time wasted finding work-arounds for their bugs!
Anyway, hope this sorry tale helps a few other programmers struggling with the same problem.

I’d almost completed a major new Windows graphics application ‘Magic Water Mark’ when I hit a typical Microsoft road-block. My tried and tested routines for saving Image Files all failed to work – creating a System.Exception: “A generic error occurred in GDI+.”. Absolutely no helpful debug information available anywhere.

The problem appeared for an application using Visual Studio 2022 with .Net 8.0
Yet earlier Applications using Visual Studio 2019 with .Net Framework 4.8 still seemed to work fine!

Sods law make it almost impossible to change my latest project back to one able to use Visual Studio 2019 – so I wasted hours looking for solutions in the wrong place.

Google searches about GDI+ errors only produced suggestions for beginners trying to save images.
Hours of frustration were eventually rewarded when I slowly understood the error had nothing to do with GDI+ but instead a single manifested problem caused by Microsofts introduction of “Controlled Folder Access”.

“Controlled Folder Access” was created by Microsoft to prevent unwanted access to a PC’s data files – Documents, Downloads, Music and Pictures.
It can easily be turned On and Off by an administrator from Windows security.

With Controlled Folder Access turned on, only Microsoft Approved applications can write to files within Documents, Downloads, Music and Pictures folders – unless the application has been individually selected to allow it access to these folders.

Later searches into problems associated with Controlled Folder Access suggests it may cause all sorts of unexpected problems with legacy Windows software. There is absolutely no meaningful warning of what is going wrong!

Controlled Folder Access almost certainly eliminates the problem of RansomWare attacks – so I am happy to keep mine turned on.
But I’ve also been going through the older PC applications I use all the time and adding them to the list of Trusted Applications in Windows Security. This prevents them from being blocked by Controlled Folder Access and ensures they don’t end up behaving in weird or unexpected ways or maybe creating errors that I don’t even even notice.

In the process of creating new software and websites, I thought it might be a good idea to improve this site by changing from http to https.
This is what I found I needed to do:

First make sure my hosting account had the necessary security certificate – D9 Hosting were on the ball and made their necessary changes within minutes after I raised a low priority ticket asking for help.

Next I added a few lines of code to the root directory ‘.htaccess’ file:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Not sure whether this was needed or not – but wanted to make sure that all http requests were routed as https secure versions

Firefox and Microsoft Edge still weren’t at all happy – saying website was insecure. So my third step was installing the WordPress plug-in Search and Replace This allowed me to change all instances of ‘http://’ to ‘https://’ for all of my posts and pages. There were hundreds of these – one for each image.

Still not enough – browsers weren’t at all happy yet. So then I installed the String Locator plugin to search for all instances of ‘http:’ This discovered hundreds of instances throughout my theme and installed plugins.

Finally I gave in and decided to remove the plugins and edit each of the theme files one by one (after a FTP download in case things went wrong). Changing each instance of ‘http’ to ‘https’ took surprisingly little time.
Now browsers seem to be quite happy.

Good luck if you need to sort the same problem – and improve your Google rating.