.Net 6p5, Trimming apps versus Windows Forms

Description

I am currently building a very basic application using Windows Forms.

My initial code looks like this (unchanged from template):

using System;
using System.Windows.Forms;

namespace WinFormsApp
{
	static class Program
	{
		/// <summary>
		///  The main entry point for the application.
		/// </summary>
		[STAThread]
		static void Main()
		{
			Application.SetHighDpiMode(HighDpiMode.SystemAware);
			Application.EnableVisualStyles();
			Application.SetCompatibleTextRenderingDefault(false);
			Application.Run(new MainView());
		}
	}
}

Whenver I try to run it, while trimming (regardless of trimming mode) is activated in the .csproj, my Debugger will instantly run into an unhandled exception when hitting the last line of code:

System.NotSupportedException
  HResult=0x80131515
  Message=Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.
  Source=System.Private.CoreLib
  StackTrace:
   at System.StubHelpers.InterfaceMarshaler.ConvertToManaged(IntPtr& ppUnk, IntPtr itfMT, IntPtr classMT, Int32 flags)
   at System.Windows.Forms.UnsafeNativeMethods.CreateStdAccessibleObject(HandleRef hWnd, Int32 objID, Guid& refiid, Object& pAcc)
   at System.Windows.Forms.AccessibleObject.UseStdAccessibleObjects(IntPtr handle, Int32 objid)
   at System.Windows.Forms.Control.ControlAccessibleObject.set_Handle(IntPtr value)
   at System.Windows.Forms.Control.ControlAccessibleObject.InitHandle(Control ownerControl)
   at System.Windows.Forms.Control.ControlAccessibleObject..ctor(Control ownerControl)
   at System.Windows.Forms.TextBoxBase.TextBoxBaseAccessibleObject..ctor(TextBoxBase owner)
   at System.Windows.Forms.TextBoxBase.CreateAccessibilityInstance()
   at System.Windows.Forms.Control.get_AccessibilityObject()
   at System.Windows.Forms.TextBoxBase.SelectInternal(Int32 start, Int32 length, Int32 textLen)
   at System.Windows.Forms.TextBox.SelectInternal(Int32 start, Int32 length, Int32 textLen)
   at System.Windows.Forms.TextBox.OnGotFocus(EventArgs e)
   at System.Windows.Forms.Control.WmSetFocus(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.TextBoxBase.WndProc(Message& m)
   at System.Windows.Forms.TextBox.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, WM msg, IntPtr wparam, IntPtr lparam)

My expectation would have been that Windows Forms is not trimmed (or affected by activating trimming) as it is referenced by a using-statement. After some experimenting, I am only able to get around this unhandled exception by completely disabling trimming on this project. The program starts up and works as expected, once I set trimming to false: <PublishTrimmed>false</PublishTrimmed>

Configuration

• Which version of .NET is the code running on? .Net 6 preview 5 and Visual Studio 2022 Preview (happens in Visual Studio 2019 as well)
• What OS and version, and for Linux, what distro? Windows 10, 21H1 (19043.1055)
• What is the architecture (x64, x86, ARM, ARM64)? x64
• Do you know whether it is specific to that configuration? I’d assume that it is not specific to my setup

[vitek-karas]

This is all super valid feedback. We’ve been discussing that PublishTrimmed should be renamed https://github.com/mono/linker/issues/2085. The main reason being that it affects build and not just publish.

A bit more details:

• PublishTrimmed will disable certain runtime features which are not compatible with trimming - for example the built in COM interop support (but lot of others) list here.
• These features are disabled even when not trimming to provide a consistent experience - we want the app to behave the same with/without trimming (or produce warnings/errors if that’s not the case). We don’t want you to run into issues only when you publish the app into “production” (discussion on feature switches)

For this to work we need to know if trimming is supposed to be used all the time - that’s why declaring PublishTrimmed=true in your project file is actually the right thing to do currently. Unfortunately we haven’t cleaned up all the things around this yet - including possibly renaming the property (or having another one which would do that).

[vitek-karas]

Playing with this a bit more - I agree that we should actually fail the build in this case - since it’s pretty much guaranteed to break the app (simple text box does that). But that means we need to have a way to override the error (or turn it into a warning instead).

Going to move this to the SDK repo where all these changes would take place.