Skip to content

Conversation

Youssef1313
Copy link
Member

Closes #5787

Related to #1285

@Evangelink Evangelink merged commit 5278358 into dev/v4 Jun 23, 2025
6 of 8 checks passed
@Evangelink Evangelink deleted the dev/ygerges/remove-attributes branch June 23, 2025 18:51
@Youssef1313 Youssef1313 added this to the 4.0.0 milestone Jun 25, 2025
@avivanoff
Copy link

avivanoff commented Jul 10, 2025

@Youssef1313, @Evangelink, we actually heavily use description attributes to provide detailed information about the tests.

@Evangelink
Copy link
Member

Thanks for the comment @avivanoff . Does it appear somewhere? If so then it might be worth for us switching to picking up the attribute from System Component Model

@avivanoff
Copy link

@Evangelink, at a minimum it is part of TRX schema, see %VSINSTALLDIR%\Xml\Schemas\vstst.xsd.

@Youssef1313
Copy link
Member Author

@avivanoff Thanks for bringing this up. It's indeed specified in the TRX schema, but it seems like VSTest never included this info in TRX before?

There was a feature request here microsoft/vstest#98 but it was closed and not implemented. So far, I don't see anything we are losing with the removal of the attribute. To me, this sounds like it will be a new feature to implement on MTP TrxReport, and support it in MSTest and VSTestBridge. And then we can reuse System.ComponentModel.DescriptionAttribute.

@avivanoff
Copy link

@Youssef1313, I really see a value in the attribute. How else would you specify what unit test does?

We have tens of thousands of unit tests that use description attribute. We would have to touch thousands of files when upgrading to MSTest 4. If I am reading you right, we should switch to System.ComponentModel.DescriptionAttribute and file a feature request to support it.

@Youssef1313
Copy link
Member Author

We would have to touch thousands of files when upgrading to MSTest 4.

To make it easier, you can add a global using for System.ComponentModel so that you don't have to touch thousands of files.

If I am reading you right, we should switch to System.ComponentModel.DescriptionAttribute and file a feature request to support it.

Yes. I think DescriptionAttribute was never supported properly before as it doesn't end up being written in TRX today already.

@avivanoff
Copy link

@Youssef1313, not everyone is lucky enough to be on C# 10 or later, our products still support .NET Framework 4.8.

@nohwnd
Copy link
Member

nohwnd commented Jul 14, 2025

You can set <LangVersion>default</LangVersion> property in your project, and get the language version depending on the compiler, rather than the project TFM to use the latest C# features (that are not library dependent) in .NET Framework 4.8. Including global usings.

@Youssef1313
Copy link
Member Author

@nohwnd You meant latest not default?

@nohwnd
Copy link
Member

nohwnd commented Jul 14, 2025

I did not. However I too find that naming confusing.

Docs say that using latest is discouraged ( see warning in the first section https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version )

And that default means "default of the compiler", but not "default of the TFM". In other words not setting the value, is not the same as setting it to default. ( see note on the bottom https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-versioning#c-language-version-reference )

@nohwnd
Copy link
Member

nohwnd commented Jul 14, 2025

(and we do use Latest in our projects, with mostly success, but we also might be more used to having our projects not build after update, and that might not be what OP wants)

@avivanoff
Copy link

@nohwnd, everything I find online about using LangVersion=default warns that it might lead to runtime errors.

@nohwnd
Copy link
Member

nohwnd commented Jul 14, 2025

do you have some examples? :) From experience we do use Latest in our projects (which should be even more dangerous). And I only rarely get errors on my computer that others don't get. But I also install lot of random latest builds of .net 10, and so on.

Default should be safer than Latest. But it is your project of course, so you do you. I just don't think it is necessary to limit yourself to the version of C# that comes with the TFM by default.

If my anecdotal evidence is not enough, here is Mads telling you to do what the docs tell you to not do...

https://www.youtube.com/watch?v=dLAgn_vljqA 😁

@avivanoff
Copy link

avivanoff commented Jul 15, 2025

We do not have the luxury to rely on YouTube videos, we need a clear statement in Microsoft's documentation.

Anyways, this conversation went off track. My point was that removal/replacement of these attributes should be done properly via deprecation first.

@Youssef1313
Copy link
Member Author

@avivanoff We will add back DescriptionAttribute, and potentially support it in MTP TRX.
For CssIterationAttribute and CssProjectStructureAttribute, I think they are not widely used. We are obsoleting them in 3.10 #5981.

@nohwnd
Copy link
Member

nohwnd commented Jul 15, 2025

We do not have the luxury to rely on YouTube videos, we need a clear statement in Microsoft's documentation.

Can you please tell me where the documentation says that you should not use default? Because in my original response I was trying to find the best way to do this, according to the documentation, rather than relying on my experience.

@avivanoff
Copy link

@nohwnd, see https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version#c-language-version-reference:

Using a C# language version newer than the version associated with your target TFM is unsupported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[MSTest v4] Consider removing CssIterationAttribute, CssProjectStructureAttribute, and DescriptionAttribute
4 participants