Compilation error

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); 
        
           }

Fixes compilation error

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.

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

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

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.

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?

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

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.

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.

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

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.

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

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.

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

@kant2002

dotnet/docs#25436

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

Navigation Menu

Repository navigation

Compilation error #55855

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	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);
	}
	}

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

Compilation error #55855

Description

Activity

stephentoub commented on Jul 16, 2021

jkotas commented on Jul 16, 2021

kant2002 commented on Jul 18, 2021

kant2002 commented on Jul 20, 2021

MichalStrehovsky commented on Jul 20, 2021

kant2002 commented on Jul 20, 2021

MichalStrehovsky commented on Jul 20, 2021

RussKie commented on Aug 3, 2021

MichalStrehovsky commented on Aug 3, 2021

RussKie commented on Aug 3, 2021

MichalStrehovsky commented on Aug 3, 2021

RussKie commented on Aug 3, 2021

MichalStrehovsky commented on Aug 3, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions