Somethings not lining up right

[buzzrad01]

Here's how the latest Build 2022-01-31T21:14:32.0000000Z looks on my windows 10 pc.

Any ideas?

Thanks .

[erfg12]

It's been a slow process upgrading to .NET 6 but it's finally complete. https://github.com/erfg12/AOL_4.0_Emu/commit/d980c264826a7eeda5d3c3bd2dc02e5a80f2ddb9

Try the latest build please, I think it should be complete anyways lol.

[buzzrad01]

browser isn't working, can't get on the web. Got this error when I clicked the home button.

[erfg12]

Check out the first answer on https://stackoverflow.com/questions/42365731/cefsharp-could-not-load-file-or-assembly-cefsharp-core-dll-or-one-of-its-dep Try that, let me know if that fixes it for you.

[amaitland]

Here's how the latest Build 2022-01-31T21:14:32.0000000Z looks on my windows 10 pc.

This is generally caused by running on a display with a DPI > 100% when the app isn't DPI Aware. Quick look through the source and it doesn't look like the app is DPI Aware. Task Manager suggests it's system DPI aware.

https://docs.microsoft.com/en-us/dotnet/desktop/winforms/high-dpi-support-in-windows-forms?view=netframeworkdesktop-4.8

If the app isn't ready to be DPI aware then using the disable-gpu-compositing command line arg should fix the issue.

Try the latest build please, I think it should be complete anyways lol.

Out of curiosity I downloaded https://github.com/erfg12/AOL_4.0_Emu/releases/download/42421072/Build_x64.zip (name suggests it's an x64 build). There is runtime assets every OS and x64, x86 and arm64 included (check the runtimes folder)

Doesn't look like it was published as win-x64 see https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish#options

I also couldn't find libcef.dll and the other native CEF runtime assets. So unless I'm missing something the build it never going to work.

[erfg12]

@amaitland You're saying the latest build doesn't fix this? I added stretching images so that if you use a high DPI it should stretch the images accordingly.

The -x64 suffix is from AppVeyor. There's a YML that specifies the purpose of that. artifact: Build_%PLATFORM%.zip

[amaitland]

@erfg12 have you tested with a DPI greater than 100%? Doesn't look like your application is DPI aware.

The -x64 suffix is from AppVeyor

Is your intention to ship an x64 build? Your build isn't published for a specific architecture from what I can tell, has all sorts of unnessicary files.

Have you tested one of your new .Net 6 builds? They don't appear to include all the relevant files.

[amaitland]

Rather than zip the debug output I'd suggest publishing for a specific runtime identifier then compressing that

Publish should look something like this

dotnet publish yoursolution.sln -f net6.0-windows -r win-x64   --self-contained false

[erfg12]

https://ci.appveyor.com/project/erfg12/aol-4-0-emu refer to the build details here.

[amaitland]

https://ci.appveyor.com/project/erfg12/aol-4-0-emu#L1045

Your distributing a debug build, this might have been ok with .Net 4.x. publish a build instead.

Have you downloaded and tried running your latest build?

[amaitland]

See https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish#description

[erfg12]

Appveyor builds with CefSharp dlls now work. @buzzrad01 https://github.com/erfg12/AOL_4.0_Emu/commit/e680d0892cb864bcc6d8cda86dcbef4cb08619c9

[amaitland]

Did you make the application DPI aware?

[erfg12]

I believe it has always been there: https://github.com/erfg12/AOL_4.0_Emu/blob/master/aol_4/Program.cs#L18

Task Manager under details shows AOL.exe DPI Awareness: System

[amaitland]

CefSharp defaults to using PerMonitor which can result in problems like the one viewed above if your application doesn't match this (I'd suggest PerMonitorV2).

PerMonitorV2 | 3 | Similar to PerMonitor, but enables child window DPI change notification, improved scaling of comctl32 controls, and dialog scaling.

Chromium uses comctrl32 internally so using PerMonitorV2 gives the best result.