[API Proposal]: Allow thread attributes in CoreLib to be applied at the assembly level.

[AraHaan]

Background and motivation

From dotnet/designs#223 (comment) all the way down to the last comment, currently RussKie is considering to do dotnet/designs#223 (comment) which is stated by @jkotas and others as being not pretty and not efficient as then the COM would then be initialized as MTA, then uninitialized, then initialized again as STA. The issue with this stems from the updated code where now you can use top level statements and skip making the Program class and the Main function yourself (where those statements would be inserted inside of an compiler generated Main function. However the compiler does not set any thread apartment attributes by default due to issues that @jkotas also stated in a reply to me about why it cant be generated by the compiler for the Main functions it generates for top level statements for all types of applications as stated here dotnet/designs#223 (comment).

API Proposal

namespace System
{
-   [AttributeUsage(AttributeTargets.Method)]
+   [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Method)]
    public sealed class STAThreadAttribute : Attribute
    {
        public STAThreadAttribute()
        {
        }
    }

-   [AttributeUsage(AttributeTargets.Method)]
+   [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Method)]
    public sealed class MTAThreadAttribute : Attribute
    {
        public MTAThreadAttribute()
        {
        }
    }
}

API Usage

As for their usage, they can be source generated by the .NET SDK:

For example the normal .NET SDK's (UseWinForms, and UseWPF is not set or set to false) it would generate:

[assembly: MTAThread]

However when one of those properties are set the .NET SDK can instead generate:

[assembly: STAThread]

Risks

The risk should be minimal as the .NET SDK would use this change to generate code that uses the attributes at the assembly level for the user. However it is needed in .NET 6 with those Windows Forms design changes that was merged in. This is to avoid those inefficient workarounds that would then be struck in the LTS release and it would produce more problems than good to just do this change to avoid said hacks for the UI frameworks (WPF and WinForms) to use COM properly.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jkotas]

I have also said: The argument for solving the problem using a language feature has been that there are other attributes that one may want to apply to Main method.

When we had an offline discussion about the right way to address this, we have been leaning towards the language feature since it is more general solution.

[jkoritzinsky]

Triaging this at 7.0.0 for now since we want to have a conversation with the C# team about a possible language-level solution to this problem.

[jkotas]

Created dotnet/csharplang#5045 for the language feature proposal.