Add explicit app manifest to desktop project#7088
Merged
peppy merged 1 commit intoppy:masterfrom Dec 8, 2019
Merged
Conversation
After the .NET Core bump to version 3.0 in the 2019.1011.0 release, reports popped up of the game not starting any more on some computers using Intel graphics cards (HD 3000 in particular). After investigation the auto-generated application manifest changed in .NET Core 3.0. In particular this seems to be a root cause for the failed start-ups on Intel cards, due to a Windows version compatibility section appearing. The section in turn affects some WinAPI calls like GetVersionEx, which will return major version 10 instead of 6 if compatibility with Windows 10 is declared. This combined with a broken check in the Intel OpenGL driver caused the crashes. To resolve this without having to patch binaries, add an explicit application manifest to the desktop project with the compatibility section removed.
Member
|
Seems good. For references, here's what we use for <?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity version="1.0.0.0" name="osu!" />
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!-- UAC Manifest Options
If you want to change the Windows User Account Control level replace the
requestedExecutionLevel node with one of the following.
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
If you want to utilize File and Registry Virtualization for backward
compatibility then delete the requestedExecutionLevel node.
-->
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
<applicationRequestMinimum>
<defaultAssemblyRequest permissionSetReference="Custom" />
<PermissionSet class="System.Security.PermissionSet" version="1" Unrestricted="true" ID="Custom" SameSite="site" />
</applicationRequestMinimum>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
* <!-- Windows 8.1 -->
* <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!-- Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!-- Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!-- Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
</application>
</compatibility>
<asmv3:application>
<legacyCorruptedStateExceptionsPolicy enabled="true"/>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</asmv1:assembly> |
peppy
approved these changes
Dec 8, 2019
frenzibyte
pushed a commit
to frenzibyte/osu-framework
that referenced
this pull request
Dec 30, 2019
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #6496.
Summary
After the .NET Core bump to version 3.0 in the 2019.1011.0 release, reports popped up of the game not starting any more on some computers using older Intel graphics cards (HD 3000 in particular).
After investigation the auto-generated application manifest changed in .NET Core 3.0. In particular this seems to be a root cause for the failed start-ups on Intel cards, due to a Windows version compatibility section appearing. The section in turn affects some WinAPI calls like
GetVersionEx, which will return major version 10 instead of 6 if compatibility with Windows 10 is declared. This combined with a broken check in the Intel OpenGL driver caused the crashes.To resolve this without having to patch binaries, add an explicit application manifest to the desktop project with the compatibility section removed.
Remarks
Due to not having the hardware required to test on hand I can't with 100% certainty declare that this will resolve the problem, however at least one user owning an affected card has confirmed that this does indeed fix it.
Since the manifest lands in the binary verbatim as ASCII, the results of this PR can be verified empirically by inspecting the
osu!.exebinary with a hex editor or usingstringsor similar tools.It's worth noting that the manifest will only take effect when running through the app host (
osu!.exe) and not through passing the DLL path todotnet(source).For reference, here are the previous manifest contents:
I've based the version in the PR on the newer one, but removed the
<compatibility>entries, and also the declaration of theMicrosoft.Windows.Common-Controlsassembly (from what I can tell, it's used to enable visual styles in Windows Forms applications, so it's not necessary here). I'm not really sure what the new<applicationRequestMinimum>entry is all about and MSDN isn't helping, so I left it in, but I can also remove it.