[Bug] Method Overloads require unnecessary references.

[TonyValenti]

Let's say you have the following code:

Project1.dll:

public class Project1 { }

Project2.dll (References Project1):

public class Project2 { }

public static class Invoker {
  public static void Execute(Project1 Project) { }
  public static void Execute(Project2 Project) { }
  public static void Execute2(Project2 Project) { }
}

Project3.dll (References Project 2 but not project 1):

....
//This works:
Invoker.Execute2(new Project2());

//This causes a compile error saying I'm missing a reference to Project1.
Invoker.Execute(new Project2());
....

I believe I should be able to call an overloaded method without referencing every assembly for every time in every overload of a method.

[gafter]

Your code is referencing a method group for which some members are not available to the compiler due to missing references. The language specifies overload resolution for the method group, but the compiler needs to have the method group t implement the spec.

[jnm2]

Ohh is that why that happens? I never figured out where that was coming from.

[yaakov-h]

Discussion is here if you're interested: dotnet/roslyn#9370

[DavidArno]

Introducing a breaking change via a new compiler in order to comply with the spec seems an odd decision. Changing the spec to respect how the compiler worked would seem a more sensible course of action to me.

But what is done is done...

[gafter]

@DavidArno the old compiler’s behavior was not fully rational, nor explainable in terms the language spec defines.