Displayed Windows Forms Controls Differ in Single File Deployment

[ab-tools]

Description

Steps to reproduce:

1. Load this simple example project: WindowsFormsApp6.zip
2. Publish it with profile "Self-Contained" and run it - it will look like this on Windows 10 64 Bit:
   
3. Publish it with profile "Self-Contained-Single-File" and run it - it will look like this on Windows 10 64 Bit:
   

Expected Behavior:

No matter if published as single file or not the Windows Forms controls should be displayed the same when executed in the same Windows environment.

Configuration

• .NET Version 5.0 RC1
• Windows 10.0.18363 64 Bit

[ghost]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

[vitek-karas]

Thanks for reporting!

Workaround is to add a manifest to your app and add the "enable themes for common controls" section:

  <!-- Enable themes for Windows common controls and dialogs (Windows XP and later) -->
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
          type="win32"
          name="Microsoft.Windows.Common-Controls"
          version="6.0.0.0"
          processorArchitecture="*"
          publicKeyToken="6595b64144ccf1df"
          language="*"
        />
    </dependentAssembly>
  </dependency>

Then it works in both cases the same.
I don't really know why it fails to work without the manifest @AaronRobinsonMSFT any idea - maybe something to do with app contexts?

[jkotas]

Related to dotnet/sdk#12904 ?

[vitek-karas]

Thanks @jkotas - definitely related, but there's something else going on here:

• publishing the app as self-contained (non-single-file) -> works without the custom manifest
• publishing the app as self-contained single-file -> doesn't work without the custom manifest
• publishing the app as framework dependent (non-single-file) -> works
• publishing the app as framework dependent single-file -> works

So the only difference I can think of is that the failing case is using singlefilehost, while all the other cases are using apphost. But I don't see a difference in the two which would cause this...

[AaronRobinsonMSFT]

@vitek-karas Agreed on this issue being related to Windows 10 support. If memory serves the Windows 10 styling is included when support is indicated in the manifest. Do we know the manifest situation in the apphost vs singlefilehost?

[vitek-karas]

I looked at the manifests of apphost and singlefilehost as produced by the repro - and they are identical (baring any mistakes I might have made). That's what's really weird - as far as I can tell the two binaries look the same.

[jkotas]

This: https://github.com/dotnet/winforms/blob/02089e92406b3f508c05060ee0ee7857a8ba3c11/src/System.Windows.Forms/src/System/Windows/Forms/Application.cs#L824

[AaronRobinsonMSFT]

@jkotas Boo. That is unfortunate. We should also check out WPF I guess.

[vitek-karas]

WPF at least by default should be OK as it does all of its rendering, unlike WinForms which relies on the OS. But there definitely could be some other problems.

This is basically "WinForms is currently not fully compatible with single-file" - unfortunately. Not sure what the fix is though - I can't find a way to create activation context without a file on disk in Win32 APIs. We would have to make this a resource of the singlefilehost - which is definitely doable.

[AaronRobinsonMSFT]

We would have to make this a resource of the singlefilehost - which is definitely doable.

Yep. That is a requirement for the activation context - at least my understanding. I used an Activation Context in CoreRun.

runtime/src/coreclr/src/hosts/corerun/corerun.cpp

Lines 415 to 445 in a986fe1

	ActivationContext(Logger &logger, _In_z_ const WCHAR *assemblyPath)
	: _logger{ logger }
	, _actCxt{ INVALID_HANDLE_VALUE }
	, _actCookie{}
	{
	ACTCTX cxt{};
	cxt.cbSize = sizeof(cxt);
	cxt.dwFlags = (ACTCTX_FLAG_APPLICATION_NAME_VALID | ACTCTX_FLAG_RESOURCE_NAME_VALID);
	cxt.lpSource = assemblyPath;
	cxt.lpResourceName = MAKEINTRESOURCEW(1); // The CreateProcess manifest which contains the context details
	_actCxt = ::CreateActCtxW(&cxt);
	if (_actCxt == INVALID_HANDLE_VALUE)
	{
	DWORD err = ::GetLastError();
	if (err == ERROR_RESOURCE_TYPE_NOT_FOUND)
	{
	_logger << W("Assembly does not contain a manifest for activation") << Logger::endl;
	}
	else
	{
	_logger << W("Activation Context creation failed. Error Code: ") << Logger::hresult << err << Logger::endl;
	}
	}
	else
	{
	BOOL res = ::ActivateActCtx(_actCxt, &_actCookie);
	if (res == FALSE)
	_logger << W("Failed to activate Activation Context. Error Code: ") << Logger::hresult << ::GetLastError() << Logger::endl;
	}
	}

[ab-tools]

Just retested this again with Visual Studio 16.9.0 Preview 3 and .NET SDK 5.0.200.preview.20614.14 and looks like things got worse:
Now the Windows Forms application crashes upon application start when published using single file deployment as soon as System.Windows.Forms.Application.EnableVisualStyles() gets called:

System.IO.FileNotFoundException: The system cannot find the file specified. (0x80070002)
   at System.Reflection.RuntimeModule.GetFullyQualifiedName()
   at System.Reflection.RuntimeModule.get_Name()
   at System.Windows.Forms.Application.EnableVisualStyles()

This happens with or without the manifest mentioned above.

[vitek-karas]

The underlying problem is #40103.
Just to prove it - you can try running the app from the Visual Studio Developer Command Prompt - it works for me (and fails without that).

The fix in progress here: #47437

[vitek-karas]

With #47464 the behavior should be consistent no matter the environment - meaning it should always fail. We think this regression happened because those who tested it happen to run in an environment where it worked.