2010-06-08 12 views
9

Tengo un control de usuario C que está definido dentro del proyecto P. C está presente como un "Componente .NET Framework" en mi Visual Studio Toolbox. Abro un formulario F (también definido en el proyecto P) y coloco C en F.Visual Studio agrega una referencia circular cuando arrastro y coloco un control de usuario desde Toolbox

Una vez que lo hago, Visual Studio agrega una referencia en P que apunta a la propia DLL de P. Esto es innecesario y causa toneladas de errores de compilación como The call is ambiguous between the following methods or properties... después de lo cual enumera exactamente el mismo método dos veces. Si voy a References y elimino la referencia agregada, se compila correctamente.

¿Puedo evitar que VS agregue esta referencia innecesaria?

Resumen (Por SLaks):
En VS2010, añadiendo un control de usuario a un formulario en el mismo proyecto añade automáticamente una referencia al proyecto en sí, causando problemas.

+0

Este es un nuevo error en VS2010. Iba a hacer esta pregunta esta noche. – SLaks

+1

¿Alguien sabe de algún artículo de Knowledge Base u otra información oficial sobre este defecto? – JoelFan

+0

Hemos estado viendo esto últimamente, también. Como hasta ahora no hay muchos "yo también", creo que nos corresponde a nosotros encontrar el patrón. Aquí es con lo que estoy trabajando. Solución VS2010 convertida de VS2008. Todos los proyectos son C#, originalmente orientados a .NET v3.5, luego modificados para destino .net v4.0. El proyecto de interfaz de usuario es WinForms. El proyecto de UI contiene clases que envuelven los controles de Infragistics. Los controles envueltos se usan en los formularios en lugar de los controles de Infragistics sin procesar. – Mel

Respuesta

1

Hasta donde yo sé, esto ha existido al menos desde visual studio 2008. Intenté encontrar una solución posible en aquel entonces, pero no pude encontrar uno. Lo siento, pero creo que no puedes evitar la referencia innecesaria y debes eliminarla cada vez que lo haga.

1

He tenido síntomas similares, pero creo que la causa fue diferente a la que usted describe. Para mí, seguí implementando una clase con un nombre que chocaba con una clase existente. Esto llevó a una llamada ambigua y a que se desatara otro infierno del compilador.

Un simple cambio de nombre lo aclaró.

Cuestiones relacionadas