Compilation error

[kant2002]

When on .NET SDK 6.0.100-preview.7.21359.1

error CS0121: The call is ambiguous between the following methods or properties: 'System.Linq.Enumerable.Select<TSource, TResult>(System.Collections.Generic.IEnumerable<TSource>, System.Func<TSource, TResult>)' and 'Internal.CommandLine.Enumerable.Select<T, U>(System.Collections.Generic.IEnumerable<T>, System.Func<T, U>)'

This is code from here

runtime/src/coreclr/tools/Common/CommandLine/Enumerable.cs

Lines 21 to 29 in 6b6310b

	public static IEnumerable<U> Select<T, U>(this IEnumerable<T> values, Func<T, U> func)
	{
	Debug.Assert(values != null);
	foreach (T value in values)
	{
	yield return func(value);
	}
	}

and here

runtime/src/coreclr/tools/Common/CommandLine/Enumerable.cs

Lines 42 to 45 in 6b6310b

	public static IEnumerable<T> Concat<T>(this IEnumerable<T> first, IEnumerable<T> second)
	{
	return Linq.Enumerable.Concat(first, second);
	}

[ghost]

Tagging subscribers to this area: @eiriktsarpalis
See info in area-owners.md if you want to be subscribed.

Issue Details

---

When on .NET SDK 6.0.100-preview.7.21359.1

error CS0121: The call is ambiguous between the following methods or properties: 'System.Linq.Enumerable.Select<TSource, TResult>(System.Collections.Generic.IEnumerable<TSource>, System.Func<TSource, TResult>)' and 'Internal.CommandLine.Enumerable.Select<T, U>(System.Collections.Generic.IEnumerable<T>, System.Func<T, U>)'

Author:	kant2002
Assignees:	-
Labels:	area-System.Linq, untriaged
Milestone:	-

[stephentoub]

What is Internal.CommandLine ? It seems like there are two equally valid extension methods, and so the compiler is telling you it doesn't know which to pick. That's by design.

[jkotas]

It is command line parser for crossgen2 tool and other tools.

[kant2002]

I update original issue with locations of the code which was breaking for me.

[kant2002]

Is this happens because of implicit namespace imports?
This is only area which I can guess can differ between .NET 6 Preview 4 and .NET 6 Preview 7.

[MichalStrehovsky]

Oh wow - https://docs.microsoft.com/en-us/dotnet/core/tutorials/top-level-templates#use-the-new-program-style

For console applications, the following directives are implicitly included in every source file in the application:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net.Http;
using System.Net.Http.Json;

🤮

Looks like the docs miss one very important piece of information: how do I tell MSBuild "HELL NO!" to this?

[kant2002]

Yes. I confirm that System.Linq added to ILCompiler.ImplicitNamespaceImports.cs, and that's behavior is by default.

There only 2 places in repo where src/coreclr/tools/Common/CommandLine/Enumerable.cs file included.

runtime/src/coreclr/tools/aot/crossgen2/crossgen2.props

Line 50 in 57bfe47

<Compile Include="..\..\Common\CommandLine\Enumerable.cs" />

and

runtime/src/coreclr/tools/dotnet-pgo/dotnet-pgo.csproj

Line 55 in 57bfe47

<Compile Include="..\Common\CommandLine\Enumerable.cs" Link="CommandLine\Enumerable.cs" />

so I assume I should add <DisableImplicitNamespaceImports>true</DisableImplicitNamespaceImports> in that files instead of removing source code. Then I should add same property to ILC where I discover the issue.

[MichalStrehovsky]

Hm, that disables the support for <Import Include="Blah" /> completely.

I think we'll want <DisableImplicitNamespaceImports_DotNet>true</DisableImplicitNamespaceImports_DotNet> and put that in src\coreclr\tools\Directory.Build.props so that we never have to deal with that in our tools again.

[RussKie]

You could also do <Import Remove="System.Linq" /> in your csproj/props files to exclude specific imports.

[MichalStrehovsky]

You could also do <Import Remove="System.Linq" /> in your csproj/props files to exclude specific imports.

Not a fan of that. dotnet/sdk#18825 is already discussing adding new additional usings that are going to cause more build breaks. E.g. the proposed System.Diagnostics addition is going to break the build for Chocolatey, Microsoft Terminal, azure pipelines agent and countless other projects.

The discussion shouldn't really be about what other namespaces we add by default, but what namespaces should be removed from the defaults.

The only ones that are maybe, maybe, okay are System and System.Collections.Generic. Everything else: I don't want that in my projects. Even the collections might be an overkill.

[RussKie]

My suggestion was to show another way of solving the issue, and not discuss global usings in general.

[MichalStrehovsky]

Understood - I was just trying to point out that solution wouldn't satisfy the "so that we never have to deal with that in our tools again" part.

[RussKie]

Oh wow - docs.microsoft.com/en-us/dotnet/core/tutorials/top-level-templates#use-the-new-program-style
Looks like the docs miss one very important piece of information: how do I tell MSBuild "HELL NO!" to this?

dotnet/docs#25436

[MichalStrehovsky]

dotnet/docs#25436

@kant2002 already has a pull request in flight: dotnet/docs#25232