Skip to content

Validate historical hacks for test projects that may be harmful for MTP projects #49063

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Youssef1313 opened this issue May 19, 2025 · 2 comments · May be fixed by #49085
Open

Validate historical hacks for test projects that may be harmful for MTP projects #49063

Youssef1313 opened this issue May 19, 2025 · 2 comments · May be fixed by #49085
Labels
untriaged Request triage from a team member

Comments

@Youssef1313
Copy link
Member

We need to revise usages of IsTestProject in SDK. For example:

<PropertyGroup Condition="'$(IsTestProject)' == 'true' And '$(ValidateExecutableReferencesMatchSelfContained)' == ''">
<!-- Don't generate an error if a test project references a self-contained Exe. Test projects
use an OutputType of Exe but will usually call APIs in a referenced Exe rather than try
to run it. -->
<ValidateExecutableReferencesMatchSelfContained>false</ValidateExecutableReferencesMatchSelfContained>
</PropertyGroup>
<PropertyGroup Condition="'$(IsTestProject)' == 'true'">
<!-- Don't generate an error if an Exe project references a test project. -->
<ShouldBeValidatedAsExecutableReference>false</ShouldBeValidatedAsExecutableReference>
</PropertyGroup>

With VSTest, test projects may have been special and requiring special hacks in SDK. For MTP though, it's just as any other typical console app and doesn't need any special handling, and the above may be actually hiding actual issues. In that case, we will need to make the special casing specific to VSTest via '$(IsTestProject)' == 'true' AND '$(IsTestingPlatformApplication)' != 'true'

There is also

<!-- Set the IsRidAgnostic property if this project should NOT accept global RuntimeIdentifier and SelfContained
property values from referencing projects. -->
<PropertyGroup Condition="'$(IsRidAgnostic)' == ''">
<IsRidAgnostic Condition="('$(_IsExecutable)' == 'true' And '$(IsTestProject)' != 'true') Or
'$(RuntimeIdentifier)' != '' Or
'$(RuntimeIdentifiers)' != ''">false</IsRidAgnostic>
<IsRidAgnostic Condition="'$(IsRidAgnostic)' == ''">true</IsRidAgnostic>
</PropertyGroup>
and
'$(_IsExecutable)' == 'true' and '$(IsTestProject)' != 'true' and

@dotnet-policy-service dotnet-policy-service bot added the untriaged Request triage from a team member label May 19, 2025
@Youssef1313
Copy link
Member Author

cc @dsplaisted as you added some of these in #17594.

@dsplaisted
Copy link
Member

Here's the background on why we added this error in the first place:

Basically, if one Exe project references another Exe project, they will both go in the output folder. However, if one is self-contained and the other isn't, then one or both of them will fail to run.

I think with VSTest, test projects were (or could be) Exe projects, but the output wasn't run directly. With MTP projects, the output is actually run.

So, it does seem like it would make sense to re-enable this error for MTP projects. That means that if you're testing a SelfContained project, then your test project will also need to be SelfContained. But generating an error telling you the problem would be better than a weird hostfxr failure which may say it can't find the shared framework or something.

@Youssef1313 Youssef1313 linked a pull request May 21, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
untriaged Request triage from a team member
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants