c# - error - no puedo agregar referencia en visual studio

Visual Studio 2010: no se pudo resolver mscorlib para el marco de destino ''.NETFramework, Version=v4.0'' (18)

Actualmente estamos migrando todas nuestras soluciones de 2005 a 2010 (¡correcto, nos salteamos 2008!). También estamos cambiando nuestra estructura de archivos para que tenga más sentido (algunos proyectos comunes se anidarán en proyectos específicos, etc.).

¡Esto significa que todas las referencias deben ser cambiadas! Además de eso, también los estamos configurando todos en .NET 4.0. Para lograr esto, hemos creado una solución temporal "DIOS" con los 117 proyectos en la misma solución.

Estoy haciendo esto con un compañero de trabajo y hasta hace aproximadamente 2 horas todo iba según lo previsto. Sin embargo, nos encontramos con un problema con uno de los 117 proyectos. Este proyecto se niega a "mostrar" sus pestañas de referencias, recursos, servicios y configuraciones dentro de las Propiedades del proyecto.

Recibo el siguiente mensaje exacto:

No se pudo resolver mscorlib para el marco de destino ''.NETFramework, Version = v4.0''. Esto puede suceder si el marco de destino no está instalado o si el moniker del marco está mal formateado.

Ahora esto es molesto pero empeora. Mi compañero de trabajo, al obtener la misma solución de subversión, PUEDE realmente ver y cambiar las referencias y cosas. De hecho, actualmente el proyecto realmente se CONSTRUYE en su máquina. Él cometió los cambios, pero no puedo construir este proyecto específico ni ver las referencias.

Lo que me lleva a la conclusión simple, algo tiene que ser diferente en mi cliente, lo que está causando problemas. Las sugerencias en línea que he visto son las siguientes:

Múltiples versiones .NET4.0 instaladas (este no es el caso en mi cliente)
.NET v3.5 no está instalado; v4.0 está tratando de compilar v3.5 (3.5 está instalado en mi cliente)
La clave de registro: OnlyUseLatestCLR está configurado y está arruinando las cosas. (escaneé mi registro, ¡esta clave no está presente en ninguna parte!)

Ver: http://connect.microsoft.com/VisualStudio/feedback/details/542789/

Lo único que aún no he probado es reparar .NET 4.0, aunque dudo mucho que este sea el problema, ya que tenemos otros 100 proyectos que puedo editar y compilar sin problemas. Tanto C # como VB.NET.

Compruebe que el marco de destino en las propiedades del proyecto esté configurado correctamente; de manera predeterminada, esto es ".NET Framework 4.0 Client": es posible que necesite ".Net Framework 4.0".

ver este hilo que se ve como el mismo problema

También es posible que desee revisar este artículo que se refiere a la depuración de un problema con el mismo síntoma con reflector

Estaba migrando un proyecto de vb.net a VS 2015. También tuve el mismo problema. El problema no está en el framework .Net, ya que pude crear un nuevo proyecto que apunta a las versiones de Framework específicas y tuvo éxito.

En mi caso, el proyecto hacía referencia a FPSpreadADO y algunas otras bibliotecas similares. Funcionó bien una vez que eliminé esas referencias.

Hoy entré en este problema, y resultó ser causado por nombres de archivo demasiado largos en el proyecto.

Esto, a su vez, fue causado por algunas referencias de servicio. Cuando se importa o actualiza una referencia de servicio, Visual Studio genera archivos .datasource, donde el nombre del archivo es el nombre completo. Esto significa nombres realmente largos en algunos casos.

Al buscar en Google, encontré indicios de que era seguro eliminar estos archivos. Mira this o this .

La eliminación de estos archivos .datasource eliminó el problema.

Lo que me sucedió fue que todas mis referencias sobre mi proyecto se perdieron, así que tuve que insertarlas de nuevo.

Me encontré con este problema hoy en Visual Studio 2017 en un proyecto que, aparentemente, había comenzado como una aplicación de plataforma universal de Windows, pero finalmente me decidí por una aplicación de escritorio de Windows Forms.

De alguna manera, ya sea por un error de bifurcación o un problema de confirmación en el control de fuente, algunos de los archivos UWP XAML obsoletos / descartados, junto con un archivo "project.json" terminaron en la carpeta de mi proyecto. VS ya no crearía o lanzaría mi aplicación Windows Forms con un error similar al informado por otros (por ejemplo, "No se pudo resolver mscorlib para el marco de destino" .NETFramework, Version = v4.7 ''").

Después de eliminar toda la basura UWP obsoleta (incluyendo "project.json", todos los archivos XAML y cualquier otra tontería relacionada) fuera de la carpeta del proyecto y volver a cargar la solución, los errores desaparecieron y el proyecto se creó y se inició correctamente.

Espero que esto ayude.

Me sucedió en el Editor de recursos.

Causa: estaba importando un archivo .Targets, que definía una propiedad llamada AppConfigFile, que probablemente sobreescribió alguna propiedad interna del mismo nombre:

<PropertyGroup> <AppConfigFile>...</AppConfigFile> </PropertyGroup>

Solución: propiedad renombrada a algún otro nombre, y el problema desapareció.

Microsoft Visual Basic para Aplicaciones Extensibilidad 5.3 (VBIDE) es el nombre del diablo !!!

Aparentemente esta es una referencia que mi compañero de trabajo tenía de alguna manera, pero no lo hice y debido a esta referencia, TODO murió. Descubrimos esto porque si marca "Mostrar todos los archivos" en el proyecto específico (que es un proyecto de VB.NET) obtendrá la dulce carpeta de Referencias, que normalmente no está ahí para el proyecto de VB.Net, parece. Cuando la Pestaña nos falló, la carpeta nos mostró una referencia con una advertencia. Aparentemente, esto es algo que el compilador o VS2010 no pudo decirme, pero fue exactamente lo que lo estaba estropeando.

Por lo tanto, si obtiene este error al trabajar en un proyecto, "Mostrar todos los archivos" para que pueda ver la carpeta de Referencias y averiguar qué referencia podría estar causando sus problemas.

¡Me alegro de que haya encontrado esto, después de más de 3 horas! >. <

Podría ser que el camino a su solución sea demasiado largo:

Sentido:
C: / MyProject / Folder / SubFolder ...
debe estar debajo de "256 caracteres".

http://wcfvs.blogspot.com/2011/04/could-not-resolve-mscorlib-for-target.html

Encontré este hilo cuando tuve el mismo problema pero no tuve problemas de referencia. Encontré el enlace de arriba y resolvió mi problema. Espero que esto ayude a alguien más que viene aquí con el mismo problema.

Recibí este mensaje de error justo esta mañana. Acabo de ir a Rebuild Project, luego cerré Visual Studio, lo volví a abrir y el error desapareció.

También recibí este error. ("No se pudo resolver mscorlib para el marco de destino ''.NetFramework 4.5.1''. Esto puede suceder si el marco de destino no está instalado o si el moniker del marco está mal formateado.").

Esto sucedió cuando cambié el marco de 3.5 a 4.5.1 en un proyecto de VB 2013. La solución consistía en eliminar todas las referencias en el archivo .vbproj: todas las referencias denominadas Referencia y ComReferencia de grupos.

Por supuesto, justo después de hacer esto, aparecieron otros tipos de errores en el proyecto.

Luego comencé a copiarlos uno por uno en el mismo lugar, copiando desde una copia de seguridad para identificar cuáles eran los problemáticos (copié los que estaban relacionados con los nuevos errores que obtuve para arreglarlos). ), actualizando el proyecto cada vez hasta que la ventana afectada se visualice correctamente.

Resultó que eran algunas referencias de bibliotecas personalizadas que crearon este problema. Espero que esto pueda ayudar a alguien. ¡Aclamaciones!

Un desarrollador.

Tuve el mismo problema con una referencia de servicio (web) en mi proyecto. Tanto " Actualizar la referencia del servicio " como " Configurar la referencia de servicio " ya no funcionaban.

Bueno, solo arrojemos la referencia de servicio (web) y créela nuevamente. ¡No vayas! El mismo mensaje de error.

Solución: Edite el archivo del proyecto y elimine todo lo que tenga que ver con las referencias del servicio.

Instrucciones:

Vaya al Explorador de soluciones y haga clic con el botón derecho en el nombre del proyecto y seleccione "Descargar proyecto".
Vaya al Explorador de soluciones y haga clic con el botón derecho en el nombre del proyecto y seleccione "Editar su nombre de proyecto.proj"
Eliminar cada elemento tiene algo que ver con sus referencias de servicio (web). (Normalmente contiene texto "referencias de servicio")
Vaya al Explorador de soluciones y haga clic con el botón derecho en el nombre del proyecto y seleccione "Recargar proyecto".
Ahora agregue sus referencias de servicio (web) nuevamente.

Problema resuelto (bueno, fue en mi caso).

Supongo que podría haber pasado: cambié una clase en algún lugar de mi servicio web. La interfaz no se modificó y Visual Studio de alguna manera no ve los cambios. La configuración (en caché?) Ya no coincide y la configuración / reconstrucción / eliminación del servicio (web) falla.

Tuve el mismo problema cuando el directorio de origen era de solo lectura. Si sincronizo mi espacio de trabajo con nuestro servidor de control de versiones (Perforce), hará que todos los directorios se lean solo de manera predeterminada a menos que seleccione que estoy revisando el directorio para su edición. A veces soy flojo y no hago esto porque soy la única persona que trabaja en algunos de estos proyectos en cualquier momento. Pero este error desaparece, borra la bandera de solo lectura.

Tuve el mismo problema y después de probar la mayoría de los anteriores, incluida la reinstalación de .Net 4.0 y el reinicio aún no desaparecieron.

Eventualmente lo resolví moviendo mi árbol de proyecto más abajo. es decir. más cerca de la raíz de la unidad. Resulta que el directorio y los nombres de archivo eran demasiado largos y creo que las referencias se estaban truncando y, por lo tanto, no se podían resolver.

El problema vino justo de inmediato.

Tuve este problema en Visual Studio 2013 al pasar de .NET 4.5 a .NET 4.6.2. El proyecto problemático fue un proyecto de sitio web.

Visual Studio ejecuta automáticamente una herramienta que genera Reference.svcmap. Reference.cs comienza con:

//------------------------------------------------------------------------------ // <auto-generated> // This code was generated by a tool. // Runtime Version:4.0.30319.42000 // // Changes to this file may cause incorrect behavior and will be lost if // the code is regenerated. // </auto-generated> //------------------------------------------------------------------------------

El solo hecho de elegir la nueva versión .NET provocó que Visual Studio limpiara los archivos generados y no volviera a llenar los contenidos. Intenté todas las soluciones anteriores, pero ninguna funcionó. Finalmente elegí .NET 4.5.1 seguido de .NET 4.6.2 y la herramienta se ejecutó. La diferencia en los archivos era solo el número de versión de la herramienta que estaba en un comentario, por lo que podría haber recuperado los archivos de GIT.

Tuve este problema hoy y la solución fue editar manualmente el archivo Resources.resx manualmente.

Mi archivo Resources.resx se veía así:

<data name="SomeString" xml:space="preserve"> <value>I am a string</value> </data> <assembly alias="System.Windows.Forms" name="System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" /> <data name="MyLogo" type="System.Resources.ResXFileRef, System.Windows.Forms"> <value>../Resources/MyLogo.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value> </data> <data name="Open" type="System.Resources.ResXFileRef, System.Windows.Forms"> <value>../Resources/Open.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value> </data>

Resultó que a Visual Studio no le gustaban los dos elementos <data> después del elemento <assembly> , lo cual es extraño teniendo en cuenta el hecho de que Visual Studio los agregó allí mismo. Mi problema se resolvió después de moverlos antes del elemento <assembly> :

<data name="SomeString" xml:space="preserve"> <value>I am a string</value> </data> <data name="MyLogo" type="System.Resources.ResXFileRef, System.Windows.Forms"> <value>../Resources/MyLogo.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value> </data> <data name="Open" type="System.Resources.ResXFileRef, System.Windows.Forms"> <value>../Resources/Open.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value> </data> <assembly alias="System.Windows.Forms" name="System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

Tuve un error similar en el proyecto PCL de XamarinForms.
Descubrí que el error fue sobre una referencia del proyecto. Actualicé el xamarin.forms a la última versión y, por alguna razón, NuGet no pudo eliminar todas las referencias de la versión anterior del archivo del proyecto (xml).
Entonces, simplemente borré la siguiente línea del archivo del proyecto y ¡funcionó!

<Error Condition="!Exists(''../../packages/Xamarin.Forms.2.3.1.114/build/portable-win+net45+wp80+win81+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10/Xamarin.Forms.targets'')" Text="$([System.String]::Format(''$(ErrorText)'', ''../../packages/Xamarin.Forms.2.3.1.114/build/portable-win+net45+wp80+win81+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10/Xamarin.Forms.targets''))" />

Espero que ayude a alguien ...

para mí, solo establecer Target Framework 4.0 resolvió mi problema. A veces, el marco objetivo está claro de alguna manera. Eso podría causar un problema.

trabajé en mi proyecto, guardé el trabajo y cerré el estudio visual 2010. cuando volví a abrir para trabajar, obtuve este error, cerré el estudio visual nuevamente, copié el archivo donde estaba guardado mi proyecto y lo pegué en otra parte (en un archivo en mi escritorio ) y abrí nuevamente el proyecto con VS2010 y estaba funcionando.