Skip to content
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

DisableImplicitNamespaceImports=false doesn't disable DisableImplicitNamespaceImports_DotNet. #19465

Closed
safern opened this issue Aug 2, 2021 · 6 comments
Assignees
Labels
Area-ImplicitUsings Area-NetSDK untriaged Request triage from a team member

Comments

@safern
Copy link
Member

safern commented Aug 2, 2021

When settings DisableImplicitNamespaceImports=false, DisableImplicitNamespaceImports_DotNet is not set to any value:

<DisableImplicitNamespaceImports_DotNet Condition="'$(DisableImplicitNamespaceImports_DotNet)' == '' and '$(DisableImplicitNamespaceImports)' != 'true'">false</DisableImplicitNamespaceImports_DotNet>

So this condition '$(DisableImplicitNamespaceImports_DotNet)'!='true' in

<ItemGroup Condition=" '$(DisableImplicitNamespaceImports_DotNet)' != 'true'
is true and the implicit namespaces are still generated. So the only way to disable them is to set both properties to true explicitly.

cc: @dsplaisted @JunTaoLuo

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-NetSDK untriaged Request triage from a team member labels Aug 2, 2021
@safern
Copy link
Member Author

safern commented Aug 2, 2021

I think this applies to all DisableImplicitNamespaceImports_* variations.

@JunTaoLuo
Copy link
Contributor

That's strange, DisableImplicitNamespaceImports controls the entire target:

Condition="'$(DisableImplicitNamespaceImports)' != 'true'" />
.

The individual conditions do not control whether the target runs or not, they only control whether the namespaces are added to the item group that's used by the target.

In effect, DisableImplicitNamespaceImports controls whether the entire feature is turned on or off and DisableImplicitNamespaceImports_DotNet is used to include subsets of namespaces. Is this not the behaviour?

@safern
Copy link
Member Author

safern commented Aug 2, 2021

I see, this behavior happens with a VB project, the reason for that seems like the vb task uses an item call Import to define the global Imports so that is why we are seeing this in dotnet/runtime when building a vbproj even though the feature is disabled.

@safern
Copy link
Member Author

safern commented Aug 2, 2021

This is what is causing that behavior:

<!-- Implicit imports -->
<ItemGroup Condition=" '$(DisableImplicitNamespaceImports_DotNet)' != 'true'
and '$(TargetFrameworkIdentifier)' == '.NETCoreApp'
and $([MSBuild]::VersionGreaterThanOrEquals($(_TargetFrameworkVersionWithoutV), '6.0'))">
<!-- Imports already defined as VB implicit imports are conditioned to not be added twice -->
<Import Include="System" Condition="'$(Language)' != 'VB'" />
<Import Include="System.Collections.Generic" Condition="'$(Language)' != 'VB'" />
<Import Include="System.IO" />
<Import Include="System.Linq" Condition="'$(Language)' != 'VB'" />
<Import Include="System.Net.Http" />
<Import Include="System.Threading" />
<Import Include="System.Threading.Tasks" Condition="'$(Language)' != 'VB'" />
</ItemGroup>

Should the ones that are imported for VB be conditioned to not be included if DisableImplicitNamespaceImports=true?

@dougbu
Copy link
Member

dougbu commented Oct 6, 2021

Reassigning to you @rafikiassumani-msft to ensure this is handled appropriately.

@safern @DamianEdwards is this issue still applicable❔

@DamianEdwards
Copy link
Member

As part of the changes in rc.1 the sub-level properties were removed so this doesn't apply anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-ImplicitUsings Area-NetSDK untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

6 participants