C# 4.0 Compile time error, fails to resolve overload when wrong overload contains parameter types defined in .NET components that are not referenced
Here's simple code for a C# 4.0 console program:

    using System.DirectoryServices.Protocols;
    namespace OverloadTest
    {
      class Program
      {
        static void Main(string[] args)
        {
          var request = new SearchRequest("", "", SearchScope.Base, null);
        }
      }
    }

SearchRequest has [3 constructors](http://msdn.microsoft.com/en-us/library/affxh0t4.aspx); only the two which take 4 parameters matter for this example:

Between these two constructors, they have identically typed and named parameters for their first, third and forth parameters. Only the second parameters differ: <b>string ldapFilter</b> versus <b>XmlDocument filter</b>.

The above code is, obviously-to-me, calling the constructor which has its second parameter declared as: <b>string ldapFilter</b>.

But if the project that this code is in does NOT have a reference to <b>System.XML</b> then a compile results in the following error:<br/><i>The type 'System.Xml.XmlDocument' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'</i>

Apparently the compiler can't evaluate which overload to use because the wrong overload has a parameter of a type that is not understood due to the lack of reference to the declaring component. Sure, the compiler has to find a 'best method' to match my code, but as my second passed parameter is a <b>string</b> why does the compiler need to bother worrying about matching my code to the <b>XmlDocument</b> overload? Or alternatively, as System.DirectoryServices.Protocols.SearchRequest is using the XmlDocument type (as a constructor parameter type); why doesn't the compiler already know enough enough about what an XmlDocument is to determine that a string is not one and thus be able to choose the correct overload?

I've already got two work-arounds that compile without error:

1) Add a reference to System.XML in the project.

2) Name the 2nd parameter (and thus the 3rd and 4th too by necessity), like so:

    var request = new SearchRequest("", ldapFilter: "", searchScope: SearchScope.Base, attributeList: null);
  For my particular case, this works because the two overloads' second parameters differ not just in type but also in name (ldapFilter versus filter).

It'd be nice though if neither work-around was needed.
C# 4.0 Compile time error, fails to resolve overload when wrong overload contains parameter types defined in .NET components that are not referenced
===

Here's simple code for a C# 4.0 console program:

    using System.DirectoryServices.Protocols;
    namespace OverloadTest
    {
      class Program
      {
        static void Main(string[] args)
        {
          var request = new SearchRequest("", "", SearchScope.Base, null);
        }
      }
    }

SearchRequest has [3 constructors](http://msdn.microsoft.com/en-us/library/affxh0t4.aspx); only the two which take 4 parameters matter for this example:

Between these two constructors, they have identically typed and named parameters for their first, third and forth parameters. Only the second parameters differ: <b>string ldapFilter</b> versus <b>XmlDocument filter</b>.

The above code is, obviously-to-me, calling the constructor which has its second parameter declared as: <b>string ldapFilter</b>.

But if the project that this code is in does NOT have a reference to <b>System.XML</b> then a compile results in the following error:<br/><i>The type 'System.Xml.XmlDocument' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'</i>

Apparently the compiler can't evaluate which overload to use because the wrong overload has a parameter of a type that is not understood due to the lack of reference to the declaring component. Sure, the compiler has to find a 'best method' to match my code, but as my second passed parameter is a <b>string</b> why does the compiler need to bother worrying about matching my code to the <b>XmlDocument</b> overload? Or alternatively, as System.DirectoryServices.Protocols.SearchRequest is using the XmlDocument type (as a constructor parameter type); why doesn't the compiler already know enough enough about what an XmlDocument is to determine that a string is not one and thus be able to choose the correct overload?

I've already got two work-arounds that compile without error:

1) Add a reference to System.XML in the project.

2) Name the 2nd parameter (and thus the 3rd and 4th too by necessity), like so:

    var request = new SearchRequest("", ldapFilter: "", searchScope: SearchScope.Base, attributeList: null);
  For my particular case, this works because the two overloads' second parameters differ not just in type but also in name (ldapFilter versus filter).

It'd be nice though if neither work-around was needed.