Migrate "[assembly: Parallelize(Scope = ExecutionScope.MethodLevel)]" to SDK project file

[SetTrend]

Current Situation

Currently, when a new MS Test SDK project is being created, an additional C# file is being generated ("MSTestSettings.cs") that's bloating the file list and may accidentally be deleted when using wildcards to delete a number of tests.

Desired Situation

Please provide an SDK project property to have this setting available there and remove the additional C# file from the project template.

[Evangelink]

Not sure why I didn't think of it before but that's a really good suggestion!

[nohwnd]

I second this one. The <AssemblyAttribute> msbuild item is made for this:

https://learn.microsoft.com/en-us/dotnet/standard/assembly/set-attributes-project-file

[Youssef1313]

@Evangelink Do you know if <AssemblyAttribute> works for F#?

[Youssef1313]

Looks like it's using WriteCodeFragment MSBuild task which relies on CodeDom that doesn't support F#?

https://github.com/dotnet/runtime/blob/354ec46a63440608bda18e2203bb5538e2f8eae6/src/libraries/System.CodeDom/src/System/CodeDom/Compiler/CodeDomProvider.cs#L22-L34

[nohwnd]

docs say it works

[Youssef1313]

Investigations summary:

We have two ways to implement this.

Using AssemblyAttribute MSBuild item

This is the easiest and most straightforward way to implement this. However, it comes with two downsides:

1. While it's generally supported by F#, the IsLiteral suffix is not supported by F#'s WriteCodeFragment task, so for now this can't work for F#. We could make the feature C#/VB only though. ( WriteCodeFragment should support IsLiteral suffix for parity with MSBuild dotnet/fsharp#18084 tracks the support for F#)
2. If the user sets GenerateAssemblyInfo to false, then the feature will not work, which makes total sense but may not be what the user expects. This can be a documented limitation of the feature though.

Writing our own task

This is a lot of work that may not be worth it.

[SetTrend]

I'd like to add just a user's comment:

1. Isn't GenerateAssemblyInfo the desired and common approach for all .NET languages?
2. If it's F# that's not supporting this flag, why not create a separate project template for F# that would be using the current, file based approach? Don't you create a separate, specific project template for each of the languages anyway?

[Evangelink]

Isn't GenerateAssemblyInfo the desired and common approach for all .NET languages?

Not sure what you mean by that. This attribute is global to .NET but many projects are disabling it which would result in our handling not working (e.g. let's assume we have <TestRunParallelizationScope>Method</...> we would not be able to emit the assembly attribute call).

If it's F# that's not supporting this flag, why not create a separate project template for F# that would be using the current, file based approach? Don't you create a separate, specific project template for each of the languages anyway?

That's the most likely scenario, so far we just wanted to capture some investigations results because I did tried things related to your request in February and hit some issues and then forgot about my investigations xD

[Youssef1313]

NOTE: I think another possibility is to use the existing WriteLinesToFile task.