Me pregunto por qué esta situación no da como resultado una referencia ambigua entre tipos, una clase dentro de nuestra biblioteca y una estructura externa. Considera lo siguiente-
Estructura externa-
namespace External.Models { public struct ProxyUser { public string Username { get; set; } public string Password { get; set; } } }Nuestra clase-
namespace MyApp.Configuration { public class ProxyUser { public string Username { get; set; } public string Password { get; set; } } }Entonces el código de llamada se aproxima-
using External.Models; namespace MyApp.Configuration.Factories { sealed class Factory { public async Task<T> BuildConfiguration<T>() { var proxy = new ProxyUser { Username = username, Password = password }; // I would expect this to be ambiguous, but it references out class } } }Esta es una biblioteca NetStandard 2.0 si eso hace la diferencia. El comportamiento es el mismo si hago de nuestra clase una estructura. ¿Por qué no es esto ambiguo?
EDITAR : la clase está sellada, nuevamente si eso hace la diferencia ...
RESPONDER
Como mencionó @Sinatr, parece estar relacionado con esta pregunta: https://stackoverflow.com/a/25437586/14872099
Esta es una demostración de los diferentes comportamientos que observé.
Esto se resuelve en nuestro MyApp.Configuration.ProxyUser -
using External.Models; namespace MyApp.Configuration.Factories { sealed class Factory { public async Task<T> BuildConfiguration<T>() { var proxy = new ProxyUser { Username = username, Password = password }; // resolves to our class } } }Esto se resuelve en la estructura externa.
namespace MyApp.Configuration.Factories { using External.Models; sealed class Factory { public async Task<T> BuildConfiguration<T>() { var proxy = new ProxyUser { Username = username, Password = password }; // resolves to external struct } } }Mover nuestra clase a otro espacio de nombres crea ambigüedad.
using External.Models; using MyApp.Configuration.Models; // moved our class to this namespace namespace MyApp.Configuration.Factories { sealed class Factory { public async Task<T> BuildConfiguration<T>() { var proxy = new ProxyUser { Username = username, Password = password }; // this is ambiguous } } }Los espacios de nombres internos (es decir, dentro de los corchetes de namespace de nombres) tienen prioridad sobre los espacios de nombres externos (es decir, using declaraciones antes del bloque de namespace de nombres).
Nota: "interno" y "externo" no son definiciones oficiales aquí, solo las uso para distinguirlas fácilmente.
Debido a la anidación, su bloque namespace MyApp.Configuration.Factories inherentemente también mira a los ancestros directos ( MyApp.Configuration y MyApp ), pero no a los espacios de nombres hermanos (por ejemplo MyApp.Configuration.Services ).
Cuando se encuentra una referencia no ambigua en los espacios de nombres internos, el sistema nunca se molesta en verificar los espacios de nombres externos y, por lo tanto, no encuentra ningún conflicto. Solo encontraría un conflicto si:
MyApp.Configuration.ProxyUser y MyApp.Configuration.Factories.ProxyUserExternal.Models.ProxyUser y Another.Namespace.ProxyUser (suponiendo que se haga referencia a ambos con instrucciones de using en este archivo).