visual studio net microsoft descargar code caracteristicas .net visual-studio

.net - net - visual studio code



¿Cómo soluciono el error de compilación de Visual Studio, "desajuste entre la arquitectura del procesador"? (18)

Soy nuevo en la configuración de proyectos en Visual Studio 2010, pero he research poco y todavía no puedo resolver este problema. Tengo una solución de Visual Studio con una DLL de C ++ que hace referencia a la DLL de C #. La DLL de C # hace referencia a algunas otras DLL, algunas dentro de mi proyecto y otras externas. Cuando intento compilar la DLL de C ++, recibo esta advertencia:

advertencia MSB3270: Hubo una discrepancia entre la arquitectura del procesador del proyecto que se está construyendo "MSIL" y la arquitectura del procesador de la referencia "[dll interno C]", "x86".

Me dice que vaya a Configuration Manager para alinear mis arquitecturas. La DLL de C # está configurada con la plataforma objetivo x86. Si trato de cambiar esto a otra cosa, como Cualquier CPU, se queja porque una de las DLL externas de las que depende tiene una plataforma objetivo x86.

Cuando veo el Administrador de configuración, muestra la Plataforma para mi DLL C # como x86 y para mi proyecto C ++ como Win32. Esto parece ser la configuración correcta; seguramente no quiero que el proyecto para mi proyecto de C ++ tenga la plataforma configurada en x64, que es la única otra opción presentada.

¿Qué estoy haciendo mal aquí?

La DLL de C # está configurada con plataforma objetivo x86

¿Cuál es el tipo de problema? Una DLL no llega a elegir cuál será el bit del proceso. Eso está completamente determinado por el proyecto EXE, ese es el primer ensamblaje que se carga, por lo que su configuración de destino de Plataforma es la que cuenta y establece el bitness para el proceso.

Las DLL no tienen opción, necesitan ser compatibles con el bitness del proceso. Si no lo son, obtendrás un gran Kaboom con una excepción BadImageFormatException cuando tu código intente usarlos.

Así que una buena selección para las DLL es AnyCPU para que funcionen de cualquier manera. Eso tiene mucho sentido para las DLL de C #, funcionan de cualquier manera. Pero claro, no su DLL de modo mixto de C ++ / CLI, contiene código no administrado que solo puede funcionar bien cuando el proceso se ejecuta en modo de 32 bits. Puede obtener el sistema de compilación para generar advertencias sobre eso. Que es exactamente lo que tienes. Sólo advertencias, todavía se construye correctamente.

Apenas despeje el problema. Establezca el objetivo de la plataforma del proyecto EXE en x86, no funcionará con ninguna otra configuración. Y mantén todos los proyectos de DLL en AnyCPU.

Además de la respuesta de David Sacks, es posible que también deba ir a la pestaña Build de las Project Properties del Project Properties y establecer el Platform Target en x86 para el proyecto que le está dando estas advertencias. Aunque puede esperar que lo sea, esta configuración no parece estar perfectamente sincronizada con la configuración en el administrador de configuración.

Debería haber una manera de hacer un .NET EXE / DLL AnyCPU, y cualquier DLL no administrado depende de compilado tanto con x86 como con x64, ambos agrupados tal vez con diferentes nombres de archivo y luego el módulo .NET carga dinámicamente el correcto en función de su tiempo de ejecución arquitectura del procesador Eso haría a AnyCPU poderoso. Si la DLL de C ++ solo admite x86 o x64, AnyCPU por supuesto no tiene sentido. Pero la idea de agrupación que tengo que ver aún está implementada, ya que el administrador de configuración ni siquiera proporciona un medio para construir el mismo proyecto dos veces con una configuración / plataforma diferente para la agrupación múltiple, permitiendo que AnyCPU o incluso otros conceptos como cualquier configuración sean posibles.

Esta advertencia parece haberse introducido con el nuevo Visual Studio 11 Beta y .NET 4.5, aunque supongo que podría haber sido posible antes.

Primero, es solo una advertencia. No debería dañar nada si solo estás tratando con dependencias x86. Microsoft solo intenta advertirle cuando declara que su proyecto es compatible con "Cualquier CPU", pero tiene una dependencia en un proyecto o un ensamblado .dll que es x86 o x64. Debido a que tiene una dependencia x86, técnicamente su proyecto no es compatible con "Cualquier CPU". Para que desaparezca la advertencia, debe cambiar su proyecto de "Cualquier CPU" a "x86". Esto es muy fácil de hacer, aquí están los pasos.

  1. Vaya al elemento de menú Crear | Administrador de configuración.
  2. Encuentra tu proyecto en la lista, debajo de Plataforma dirá "Cualquier CPU"
  3. Seleccione la opción "Cualquier CPU" en el menú desplegable y luego seleccione <New..>
  4. Desde ese cuadro de diálogo, seleccione x86 en el menú desplegable "Nueva plataforma" y asegúrese de que "Cualquier CPU" esté seleccionada en el menú desplegable "Copiar configuración de".
  5. Pulsa OK
  6. Querrá seleccionar x86 para las configuraciones de Depuración y Liberación.

Esto hará que la advertencia desaparezca y también indicará que su ensamblaje o proyecto ya no es compatible con "Cualquier CPU", sino que ahora es específico para x86. Esto también es aplicable si está construyendo un proyecto de 64 bits que tiene una dependencia x64; simplemente seleccionarías x64 en su lugar.

Otra nota, los proyectos pueden ser compatibles con "Cualquier CPU" generalmente si son proyectos .NET puros. Este problema solo se presenta si introduce una dependencia (dll de terceros o su propio proyecto administrado de C ++) que apunta a una arquitectura de procesador específica.

Esta es una advertencia muy terca y, si bien es una advertencia válida, hay algunos casos en los que no se puede resolver debido al uso de componentes de terceros y otras razones. Tengo un problema similar, excepto que la advertencia es porque mi plataforma de proyectos es AnyCPU y estoy haciendo referencia a una biblioteca de MS creada para AMD64. Esto está en Visual Studio 2010, por cierto, y parece que se introdujo al instalar VS2012 y .Net 4.5.

Como no puedo cambiar la biblioteca de MS a la que hago referencia, y como sé que mi entorno de implementación de destino solo será de 64 bits, puedo ignorar este problema de forma segura.

¿Qué pasa con la advertencia? Microsoft publicó en respuesta a un informe de Connect que una opción es deshabilitar esa advertencia. Solo debe hacer esto si está muy al tanto de la arquitectura de su solución y entiende completamente su objetivo de implementación y sabe que no es realmente un problema fuera del entorno de desarrollo.

Puede editar su archivo de proyecto y agregar este grupo de propiedades y la configuración para deshabilitar la advertencia:

<PropertyGroup> <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch> </PropertyGroup>

Estaba recibiendo la misma advertencia que hice esto:

  1. descargar proyecto
  2. editar propiedades del proyecto es decir .csproj

  3. añadir la siguiente etiqueta:

    <PropertyGroup> <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch> None </ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch> </PropertyGroup>

  4. Recargar el proyecto

He tenido un problema similar antes, específicamente al agregar una solución de prueba a una solución x64 existente, como SharePoint. En mi caso, parece tener que ver con el hecho de que ciertas plantillas de proyectos se agregan como ciertas plataformas de forma predeterminada.

Aquí está la solución que a menudo funciona para mí: configúrelo todo en la plataforma correcta en el Administrador de configuración (el menú desplegable de configuración activa, que normalmente dice Debug, es una buena forma de llegar a ella) y la plataforma del proyecto (en las propiedades del proyecto), luego construir, a continuación, vuelva a establecer todo en AnyCPU. A veces tengo que eliminar y volver a agregar algunas dependencias (DLL en cada una de las propiedades del proyecto) y, a veces, se debe cambiar "Ejecutar pruebas en un proceso de 32 o 64 bits" (haga doble clic en Local.testsettings y vaya a Hosts).

Me parece que esto es solo configurar algo y luego restablecerlo, pero probablemente haya más cosas detrás de la escena que no estoy viendo. Sin embargo, ha funcionado bastante consistentemente para mí en el pasado.

Para los proyectos de C #, el objetivo de x86 hace lo que parece. Dice que este montaje solo soporta arquitecturas x86. Igualmente para x64. Cualquier CPU, por otra parte, dice que no me importa qué arquitectura, soy compatible con ambas. Entonces, las siguientes 2 preguntas son (1) ¿Cuál es la configuración del ejecutable que usa estos archivos DLL? y (2) ¿cuál es el bitness de su sistema operativo / computadora? La razón por la que pregunto es porque si su ejecutable está compilado para ejecutarse en 64 bits, entonces NECESITA todas las dependencias para poder ejecutarse también en modo de 64 bits. El ensamblaje de Cualquier CPU debe poder cargarse, pero quizás se refiere a alguna otra dependencia que solo es capaz de ejecutar en la configuración x86. Verifique todas las dependencias y dependencias de dependencias para asegurarse de que todo sea "Cualquier CPU" o "x64" si planea ejecutar el ejecutable en modo de 64 bits. De lo contrario, tendrás problemas.

En muchas formas, Visual Studio no facilita la compilación de una combinación de Cualquier CPU y varios ensamblajes dependientes de la arquitectura. Es factible, pero a menudo requiere que un ensamblaje que de otra manera sería "Cualquier CPU" se compile por separado para x86 y x64 porque alguna dependencia de dependencia en algún lugar tiene dos versiones.

Para mi proyecto, tengo el requisito de poder construir tanto para x86 como para x64. El problema con esto es que cada vez que agrega referencias mientras usa una, entonces se queja cuando construye la otra.

Mi solución es editar manualmente los archivos * .csproj para que líneas como estas:

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=x86"/> <Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=AMD64"/> <Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL"/>

cambiar a esto:

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral"/>

Recibí esta advertencia en Visual Studio 2012 al compilar una tarea de secuencia de comandos de SSIS de SQL Server 2012 SP1, hasta que instalé SP2 de SQL Server 2012.

Resolví esta advertencia cambiando "Configuration Manager" a Release (Plataforma mixta).

Si su DLL de C # tiene dependencias basadas en x86, entonces su DLL tendrá que ser x86. Realmente no veo una manera de evitar eso. VS se queja de cambiarlo (por ejemplo) a x64 porque un ejecutable de 64 bits no puede cargar bibliotecas de 32 bits.

Estoy un poco confundido acerca de la configuración del proyecto C ++. El mensaje de advertencia que se proporcionó para la compilación sugiere que estaba dirigido a AnyCPU, porque informó que la plataforma a la que apuntaba era [MSIL], pero indicó que la configuración del proyecto era en realidad Win32. Una aplicación Win32 nativa no debería incluir la MSIL, aunque es probable que tenga que tener habilitada la compatibilidad con CLR si está interactuando con una biblioteca de C #. Así que creo que hay algunos vacíos en el lado de la información.

¿Podría respetuosamente pedirle que revise y publique un poco más de detalles sobre la configuración exacta de los proyectos y cómo están relacionados entre sí? Estaré encantado de ayudar más si es posible.

También puede recibir esta advertencia para los ensamblajes de MS Fakes que no es tan fácil de resolver ya que el f.csproj se basa en el comando. Por suerte, el xml Fakes te permite agregarlo allí .

Tuve el mismo problema con la conexión de apertura de SQLite, y usar el Nuget e instalar el componente utilizado en el proyecto (SQLite) lo solucionó. Intenta instalar tu componente de esta manera y verifica el resultado.

Tuve este problema hoy y solo mirar las configuraciones de construcción en Visual Studio no me ayudó porque mostró Cualquier CPU tanto para el proyecto que no se estaba construyendo como para el proyecto al que se hace referencia.

Luego miré el csproj del proyecto de referencia y encontré esto:

<PropertyGroup Condition=" ''$(Configuration)|$(Platform)'' == ''Release|AnyCPU'' "> <DebugType>pdbonly</DebugType> <Optimize>true</Optimize> <OutputPath>bin/Release/</OutputPath> <DefineConstants>TRACE</DefineConstants> <ErrorReport>prompt</ErrorReport> <WarningLevel>4</WarningLevel> <PlatformTarget>x64</PlatformTarget>

De alguna manera, este PlatformTarget se agregó en medio de un cambio de configuración y el IDE no pareció verlo.

Eliminar esta línea del proyecto de referencia resolvió mi problema.

Tuve un problema similar fue causado por MS UNIT Test DLL. Mi aplicación WPF se compiló como x86 pero la prueba de unidad DLL (archivo EXE referido) como "Cualquier CPU". Cambié la prueba de unidad DLL para ser compilada para x86 (igual que EXE) y fue resovled.

Tuve una advertencia muy similar en mi versión. Mis proyectos se configuraron para apuntar a .NET 4.5, en el servidor de compilación se instaló el SDK de Windows 8.1 (para .NET 4.5.1). Después de actualizar mis proyectos para apuntar a .NET 4.5.1 (no fue un problema para mí, fue para una aplicación completamente nueva), ya no recibí la advertencia ...

Una buena regla general es "abrir archivos DLL, EXE cerrados", es decir:

  • EXE apunta al sistema operativo, especificando x86 o x64.
  • Las DLL se dejan abiertas (es decir, AnyCPU) para que se puedan crear instancias dentro de un proceso de 32 bits o de 64 bits.

Cuando creas un EXE como AnyCPU, todo lo que estás haciendo es diferir la decisión sobre qué bitness del proceso usar para el sistema operativo, lo que hará que el EXE sea de su agrado. Es decir, un sistema operativo x64 creará un proceso de 64 bits, un sistema operativo x86 creará un proceso de 32 bits.

La creación de DLL como AnyCPU los hace compatibles con cualquiera de los procesos.

Para más información sobre las sutilezas de la carga de ensamblajes, consulte here . El resumen ejecutivo lee algo como:

  • AnyCPU : se carga como un ensamblaje x64 o x86, dependiendo del proceso de invocación
  • x86 - se carga como ensamblaje x86; no se cargará desde un proceso x64
  • x64 - se carga como un ensamblaje x64; no se cargará desde un proceso x86