Errors running Asp.net Core website on Plesk on Windows Server 2019

Question

I'm trying to run an Umbraco v12 (.NET Core 7) website on a client's Windows 2019 server, the only interface to which is Plesk control panel.

I've verified that the .NET Core 7 framework is installed on the server (in Plesk under Tools & Settings > Server Components it's showing Microsoft .NET Core 7.0 Runtime 7.0.14).

Also the ASP.NET Core hosting bundle is installed as I can see Plesk under Tools & Settings > Update > Add/Remove Components it's showing "Microsoft ASP.NET Core hosting features" as being installed.

I publish the website locally on my development machine to a folder on the filesystem and then FTP the files to the web server. When I load the web page in a browser it just throws an error:

"This site can’t be reached The web page at https://www.random-site-name.the-server-ip-address.plesk.page/ might be temporarily down or it may have moved permanently to a new web address. ERR_HTTP2_PROTOCOL_ERROR"

If I reload it throws a 503 error as the application pool has stopped. Restarting that results in the same error above, followed by a stopped application pool again on subsequent page refreshes.

I've checked folder permissions and they appear okay.

I don't know if this is a coding issue (works on my machine), a database connection issue, a publishing configuration issue, or a hosting/server issue and I can't seem to find any useful error logs.

Does anybody know what might be causing this or at least how to access relevant error logs?

Many thanks

Answer 1

I've finally managed to resolve it. The crux of it seemed to be that in the Visual Studio publish settings, the target runtime needed to be "Portable" rather than win-x86 (or anything else).

That helped to yield a 503 error, which was resolved by copying the Media folder from my local filesystem onto the server, which is something the publish process didn't seem to do (?!)

That yielded an 'Umbraco failed to boot' message which was resolved by correcting the database connection string.

The above aren't all at fault for the original issue, but all worth noting in case it helps anyone in future with a set-up like this.