Tengo dos proyectos web ASP.NET (ProjectA y ProjectB). Cuando la clase en ProjectA está instanciando una clase de ProjectB que usa un archivo de recursos Blah.resx, obtengo este error:
Se produjo una excepción del tipo 'System.Resources.MissingManifestResourceException' en mscorlib.dll pero no se manejó en el código de usuario.
No se pudieron encontrar recursos apropiados para la cultura especificada o la cultura neutral. Asegúrese de que "Resources.Blah.resources" esté correctamente incrustado o vinculado en el ensamblado "App_GlobalResources.sn_flri6" en el momento de la compilación, o que todos los ensambles de satélite necesarios se puedan cargar y estén totalmente firmados.
¿Qué está causando esto?
Hay un artículo en el sitio de Microsoft sobre este http://support.microsoft.com/kb/318603 que sugiere:
Para resolver este problema, mueva todas las demás definiciones de clase para que aparezcan después de la definición de clase del formulario.
Esta es una solución para el proyecto de Windows Forms, no estoy seguro de si eso también se aplica a los proyectos web.
fuente
To resolve this problem, move all of the other class definitions so that they appear after the form's class definition.
Esto resolvió mi problema.GetGlobalResourceObject
Respuestas:
Acabo de llegar a esta misma excepción en un proyecto WPF. El problema ocurrió dentro de un ensamblaje que recientemente movimos a otro espacio de nombres (
ProblemAssembly.Support
aProblemAssembly.Controls
). La excepción ocurría al intentar acceder a los recursos desde un segundo archivo de recursos que existe en el ensamblado.Resulta que el archivo de recursos adicionales no movió correctamente las referencias del antiguo nombre de espacio de nombres al nuevo nombre de espacio de nombres.
En el archivo designer.cs para el archivo de recursos, hay una propiedad estática para obtener el ResourceManager. Dentro de ese captador, la cadena todavía se refería al antiguo espacio de nombres. Una vez que lo corrigió al nuevo espacio de nombres, el problema se resolvió:
debería haber sido:
Espero que esto ayude a la próxima persona.
fuente
Resolví el problema así:
Funciona perfectamente
fuente
Cuando intenté compartir un archivo resource.resx de un proyecto C # con otro proyecto C #, obtuve este problema. La sugerencia de mover la clase Form al comienzo de su archivo no era apropiada. Así es como lo resolví. Básicamente, utiliza un enlace del segundo proyecto al primero, luego habilita la regeneración del
resource.designer.cs
archivo.Properties/Resources.resx
archivo del segundo proyectoProperties/Resources.resx
archivo del primer proyecto como un ENLACE a la carpeta Propiedades en el segundo proyecto. No lo agregue al nivel raíz del proyecto.Properties/Resources.designer.cs
!Resources.resx
, agregueResXFileCodeGenerator
como CustomToolResources.resx
y seleccione "Ejecutar herramienta personalizada". Esto generará un nuevo archivo designer.cs.Nota: Evitaría editar el archivo resource.designer.cs, ya que esto se genera automáticamente.
fuente
En mi caso, una serie de reemplazos de texto global mal pensados había cambiado inadvertidamente esta línea en el archivo cs del diseñador de recursos.
Como el espacio de nombres en ese argumento ya no coincidía con el espacio de nombres de la clase, la aplicación se confundió en el tiempo de ejecución.
Verifique que el espacio de nombres del diseñador coincida con el argumento de cadena en esa línea.
fuente
Sucede porque
*.resх
está excluido de la migración.fuente
Descubrí que eliminar el archivo designer.cs, excluir el archivo resx del proyecto y luego volver a incluirlo a menudo soluciona este tipo de problema, luego de una refactorización del espacio de nombres (según la respuesta de CFinck)
fuente
Nadie parece haber mencionado esta solución. Obvio realmente, pero me hizo tropezar por un momento ...
El modificador de acceso predeterminado para un nuevo archivo de recursos es
Internal
(oFriend
en VB.Net.) Asegúrese de cambiar esto aPublic
(en el diseñador de resx hay un menú desplegable en la parte superior para el modificador de acceso)
fuente
La respuesta de Sibi Elangos por sí sola no fue suficiente para mí, así que tuve que
Esto generará un App_GlobalResources en su
/bin
carpeta, ahora copie esa carpeta también en la raíz de la aplicación webfuente
En mi caso, el problema causado por definir la clase de la manera incorrecta:
Después de reasignar
BackendObject
hasta el final (mejor separar el archivo), hacer la limpieza del proyecto + reconstruir resolvió el problema.fuente
Resolví esto yendo al proyecto donde se guardó mi archivo de recursos, desplazándome hacia abajo a su ItemGroup y agregando un nombre lógico que correspondía a la ruta que esperaba el compilador.
Mi EmbeddedResource se veía así:
Ahora se ve así
fuente
En lo que respecta a este caso, verifique si el ensamblado que contiene recursos tiene el espacio de nombres predeterminado establecido en el mismo texto (Proyecto-> Propiedades-> Espacio de nombres predeterminado; en VS) Compruebe también si el archivo resx tiene una propiedad BuildAction establecida en "Embedded recurso "Disfruta ...;)
fuente
Assembly localisationAssembly = Assembly.Load("xxx"); ResourceManager resourceManager = new ResourceManager("xxx", localisationAssembly);
Un enfoque sería colocar las clases / recursos compartidos en un proyecto de biblioteca de clases por separado y referirlos a ambos sitios web.
fuente
Gracias @CFinck! Solo para agregar un consejo a los demás: cambié la línea ResourceManager con esto:
Estoy en vb.net pero creo que en C # la única diferencia sería + en lugar de & para concatenar cadenas.
De esta manera, puedo usar los mismos archivos de ensamblaje vinculados en dos proyectos similares que comparten los recursos.
fuente
Dotfuscation también genera este error, ya que un archivo de diseñador resx se basa en la reflexión. Si está utilizando Dotfuscator, romperá sus archivos resx. Siempre debe agregarlos como una exclusión del proceso de ofuscación.
fuente
Cuando estábamos usando
Generaría ese error a menos que envuelvamos esa llamada dentro de una declaración try / catch.
fuente
Tengo una aplicación WinForms con un solo proyecto en la solución.
Orientación
.NET Framework 4.0
utilizando
SharpDevelop 4.3
como mi IDESuena tonto, pero resultó que tenía la
Logical Name
propiedad establecida"Resources"
en mi"Resources.resx"
archivo. Una vez que despejé esa propiedad, todo funciona hunky-dory.Normalmente, cuando agrega archivos aleatorios como
EmbeddedResource
, generalmente desea establecerLogical Name
algo razonable, por alguna razón, hice lo mismo en elResources.resx
archivo y eso lo arruinó todo ...Espero que esto ayude a alguien.
fuente
Para mí, el problema era copiar archivos .resx y archivos .cs asociados de un proyecto a otro. Ambos proyectos tenían el mismo espacio de nombres, así que ese no era el problema.
Finalmente lo resolví cuando noté en el Explorador de soluciones que en el proyecto original los archivos .resx dependían de los archivos .cs:
Mientras que en el proyecto copiado, los archivos .cs dependían de los archivos .resx:
Resultó que en el segundo proyecto de alguna manera los archivos .resx se habían configurado para generar automáticamente los archivos .cs. Los archivos .cs generados automáticamente sobrescribían los archivos .cs copiados del proyecto original.
Para solucionar el problema, edite las propiedades de cada archivo .resx en el proyecto copiado. La propiedad Herramienta personalizada se establecerá en algo como ResXFileCodeGenerator . Borre la propiedad Herramienta personalizada del archivo .resx. Deberá volver a copiar el archivo .cs del proyecto original, ya que el archivo generado automáticamente lo ha sobrescrito.
fuente
En mi caso, había colocado una nueva clase encima de un formulario de Windows, dentro del mismo archivo.
Mover la clase recién agregada fuera de ese archivo solucionó el problema.
Ver aquí: http://i.stack.imgur.com/wVu6c.png
fuente
Esto puede ser causado por espacios de nombres no coincidentes. El segundo de la respuesta principal (Sibi Elango) dice que haga clic derecho en el archivo resx y cambie la opción de compilación a EmbeddedResource, pero ya lo había hecho y todavía tenía el error. La respuesta principal (CFinck) señala una forma de solucionar esto mediante la edición manual de archivos, sin embargo, tuve este problema en MonoDevelop y tuve que establecer el espacio de nombres predeterminado al mismo que el archivo cs que estaba solicitando el recurso (el archivo que código contenido como el código a continuación) ...
Después de configurar el espacio de nombres predeterminado a través de la GUI, la línea anterior ya no causó una excepción.
fuente
Solo otro caso. Copié una solución con dos proyectos y los renombré parcialmente en el explorador de Windows (nombres de carpeta, nombres de archivo .sln y .csproj) y parcialmente con una acción masiva de Buscar y reemplazar en Visual Studio (espacios de nombres, etc.). Sin embargo, la excepción declarada por el OP todavía ocurrió. Descubrí que los nombres de la Asamblea y el Espacio de nombres todavía eran viejos.
Aunque el proyecto y todo lo demás que ya fue nombrado OfficeStyle el
Assembly name
yDefault namespace
todavía fueron nombrados Linckus .Después de esta corrección, todo volvió a funcionar, compilar y ejecutar :)
fuente
En mi caso, estas líneas de código añadidas
Web.config
ayudaron mucho:Junto con la acción de construcción:
Embedded Resource
y la herramienta de medida:PublicResXFileCodeGenerator
.fuente
Haga doble clic en las propiedades en la sección Aplicación, verifique que el nombre del ensamblaje y el espacio de nombres predeterminado sean iguales
fuente
También estaba enfrentando el mismo problema, probé todas las soluciones mencionadas en la respuesta, pero ninguna parecía funcionar. Resultó que durante el registro de código a TFS. TFS no registró el archivo Resx, solo lo hizo en el archivo del diseñador. Por lo tanto, todos los demás desarrolladores se enfrentaron a este problema mientras se ejecutaban en sus máquinas. El registro en el archivo resx manualmente hizo el truco
fuente
Esto también puede ocurrir cuando se coloca una clase por encima de la clase winform principal (Form1, por ejemplo). Puede ver esto cuando observa el diseño, ya que no se representa.
fuente
Otra causa más: si su espacio de nombres tiene un guión ("-"), se generará y ejecutará correctamente, pero el recurso no será accesible. Se supone que los espacios de nombres (identificadores) no tienen guiones, pero parece que esto no se aplica en ninguna parte excepto en la carga de recursos. Esto me ha quemado dos veces durante la década.
fuente
Otra cosa que debe verificar es si tiene LogicalName o ManifestResourceName definido en EmbeddedResource. Asegúrese de que estén definidos adecuadamente si su archivo de proyecto los está utilizando, ya que pueden hacer que los recursos vivan bajo un nombre que no espera.
fuente
Me enfrenté a este problema para ejecutar el comando de migración.
Update-Database
en la consola de Package Manager.La respuesta aceptada no resolvió mi problema.
Tuve que cambiar Build Action de
Compile
aEmbedded Resource
y funcionó para mí.Puede hacer lo mismo con los pasos a continuación:
fuente
Para los usuarios que enfrentan este problema en .NET Core 3.0, esto podría estar relacionado con un cambio importante que se realizó en .NET Core 3.0, para resolverlo, simplemente
EmbeddedResourceUseDependentUponConvention
configúrelo como falso en su proyecto csproj:fuente
Haga clic derecho en los recursos y seleccione
Run Custom Tool
Esto arreglará al diseñador
fuente
El hecho de que haga referencia a la DLL del Proyecto B no significa que el Administrador de recursos del Proyecto A conozca el directorio App_GlobalResources del Proyecto B.
¿Está utilizando proyectos de sitios web o proyectos de aplicaciones web? En el último, Visual Studio debería permitirle vincular archivos de código fuente (no estoy seguro sobre el primero, nunca los he usado). Esta es una característica poco conocida pero útil, que se describe aquí . De esa manera, puede vincular los archivos de recursos del Proyecto B al Proyecto A.
fuente