2009-10-15 14 views
31

Tengo una solución x86 Visual Studio con muchos archivos de proyecto. Algunos de los archivos DLL están diseñados para funcionar como complementos para otras aplicaciones en el sistema de un usuario. Estamos ampliando algunas de las DLL para poder admitir aplicaciones de 64 bits. Lo que me gustaría hacer es configurar la solución/proyectos para que solo presionando "Build" compile las versiones x86 y x64 de esas DLL. La solución contiene proyectos C++ y C#. Me doy cuenta de que "Batch Build" es capaz de construir ambos, aunque sería más conveniente si los desarrolladores pudieran simplemente hacer clic en el mismo botón que tenían anteriormente y tener todos los archivos DLL de salida generados.¿Usa una sola solución de Visual Studio para compilar tanto x86 como x64 al mismo tiempo?

Aquí hay un par de las modificaciones que he tratado de un proyecto de prueba, pero no han llegado a trabajar:

He intentado modificar el <Target Name="AfterBuild"> intentar:

<Target Name="AfterBuild" Condition=" '$(Platform)' == 'x86' "> 
    <PropertyGroup> 
    <Platform>x64</Platform> 
    <PlatformTarget>x64</PlatformTarget> 
    </PropertyGroup> 
    <CallTarget Targets="Build"/> 
</Target> 

pero que se traduce en el siguiente error:

C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(565,5): error MSB4006: There is a circular dependency in the target dependency graph involving target "Build".

creo que mis condiciones impedirán la recursividad infinita, pero yo entiendo como MSBuild no podía verlo de esa manera.

También he intentado:

<Project DefaultTargets="MyBuild86;MyBuild64" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5"> 
... 
<Target Name="MyBuild86"> 
    <PropertyGroup> 
    <Platform>x86</Platform> 
    <PlatformTarget>x86</PlatformTarget> 
    </PropertyGroup> 
    <CallTarget Targets="Build"/> 
</Target> 
<Target Name="MyBuild64"> 
    <PropertyGroup> 
    <Platform>x64</Platform> 
    <PlatformTarget>x64</PlatformTarget> 
    </PropertyGroup> 
    <CallTarget Targets="Build"/> 
</Target> 

pero mi DefaultTargets parece ser ignorado desde el IDE de Visual Studio.

pasado, he intentado crear un proyecto independiente que importe el primer proyecto:

<?xml version="1.0" encoding="utf-8"?> 
<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <PropertyGroup> 
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> 
    <Platform>x64</Platform> 
    <PlatformTarget>x64</PlatformTarget> 
    <ProductVersion>9.0.30729</ProductVersion> 
    <SchemaVersion>2.0</SchemaVersion> 
    <OutputPath>..\$(Configuration)\x64\</OutputPath> 
    <ProjectGuid>{A885CAC3-2BBE-4808-B470-5B8D482CFF0A}</ProjectGuid> 
    </PropertyGroup> 
    <Import Project="BuildTest.csproj" /> 
</Project> 

y esto hasta ahora ha mostrado el más prometedor. Sin embargo, Visual Studio parece ignorar mi configuración OutputPath de este nuevo proyecto y en su lugar emite el exe/dll a la ruta especificada en el proyecto original. No hay ningún bloque PropertyGroup que pueda ver que se está ejecutando en el proyecto original para anularlo, así que no estoy seguro de lo que está pasando.

Respuesta

26

Hacemos algo similar para construir conjuntos de núcleos para .NET CF. Prueba esto:

<Target Name="AfterBuild"> 
    <MSBuild Condition=" '$(Platform)' == 'x86' " Projects="$(MSBuildProjectFile)" Properties="Platform=x64;PlatFormTarget=x64" RunEachTargetSeparately="true" /> 
</Target> 
+0

Parece que funciona bastante bien, gracias. Ahora para descubrir algo similar para los proyectos C++ ... – PeteVasi

+2

Funcionó bien para el proyecto C++. Cambié la plataforma de destino en condición de 'x86' a 'Win32' – Woodman

+0

YMMV, pero para mí, las referencias del proyecto C++ no se volvieron a cargar y las bibliotecas estáticas que vinculaban objetivos relacionados no se volvieron a ejecutar y, por lo tanto, los enlaces se rompieron. Por desgracia, creo que volveré con el equivalente de la llamada dual 'msbuild'. – crazysim

0

No podrá hacer esto con la interfaz de usuario de Visual Studio. Para esto, tendrás que hackear los archivos de MSBuild.

Try this link from MSDN for MSBuild Overview

+0

Sí, he estado trabajando con los archivos de MSBuild (edición manual del * .csproj de todos modos). Todavía no he podido hacer que funcione. – PeteVasi

4

Creo que la mejor forma de hacer esto es invocar msbuild desde la línea de comandos. No debería ser necesario edición de archivos msbuild, basta con ejecutar

msbuild myproj.sln /p:Configuration="Debug|Win32" 
msbuild myproj.sln /p:Configuration="Debug|x64" 

que asumir que si un desarrollador está utilizando Visual entonces que sólo va a estar generando los archivos DLL para que puedan depurar con ellos de estudio, y que tiene una proceso de compilación por separado si en realidad está implementando los dlls?

+0

Sí, hay un proceso de compilación independiente cuando se implementan las DLL que pueden manejar cualquier bondad y paquete de línea de comandos que necesitemos. Pero quiero que las máquinas de desarrollo que ejecutan solo Visual Studio puedan acceder fácilmente a "Crear" y luego puedan probar los complementos x86 y x64. (También es ligeramente relevante, no todo en la solución necesita una versión x64. La aplicación de configuración puede permanecer solo en 32 bits). – PeteVasi

+0

Para ese caso de uso en particular, no puedo pensar en otra forma de hacerlo que configurar una configuración personalizada. regla de compilación que llama a msbuild para construir la otra arquitectura. –

+0

He estado jugando con varias reglas de compilación personalizadas para intentar hacer que esto funcione, pero aún no he llegado del todo. Modifiqué mi pregunta original para incluir todos mis intentos. – PeteVasi

4

para C++, y si se trata de un proyecto cuyos archivos/parámetros no cambian a menudo, una forma de hacerlo es crear dos proyectos dentro de la solución, con los dos proyectos en referencia a la misma fuente archivos. Luego, en las compilaciones x64, configure un proyecto para compilar 64 bits y el otro de 32 bits. (En versiones x86, configure una como de 32 bits y apague la otra.)

Hemos estado usando esto por un tiempo y funciona bien.

Por supuesto, debe tener cuidado de que los cambios que realice en uno también se realicen en su copia. es decir, si agrega/elimina un archivo o cambia su configuración de compilación, debe hacerlo en dos lugares. Los cambios en el código fuente solo deben hacerse una vez porque todavía hay una sola copia de cada archivo fuente.

Y, por supuesto, puede decidir que hacer esto es más complejo/riesgoso que dejar de usar el IDE. En nuestro caso, funcionó muy bien, sin embargo.

-2

Me encontré con este problema con un proyecto que se ejecuta en VS2008 XP (32 bits) y también VS2010 7 (64 bits). La solución que utilicé fue usar la variable $ (PROGRAMFILES). Se resolvió correctamente en ambas máquinas.

4

proyecto de Importación es tal manera que funciona para mí en Visual Studio 2010:

TestProject64.vcxproj

<?xml version="1.0" encoding="utf-8"?> 
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <Import Project="TestProject.vcxproj" /> 
    <ItemGroup Label="ProjectConfigurations"> 
    <ProjectConfiguration Include="Release|x64"> 
     <Configuration>Release</Configuration> 
     <Platform>x64</Platform> 
    </ProjectConfiguration> 
    </ItemGroup> 
    <PropertyGroup Label="Globals"> 
    <ProjectGuid>{B7D61F1C-B413-4768-8BDB-31FD464AD053}</ProjectGuid> 
    </PropertyGroup> 
</Project> 

TestProject64.vcxproj.filters

<?xml version="1.0" encoding="utf-8"?> 
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <Import Project="TestProject.vcxproj.filters" /> 
</Project> 

TestProject.vcxproj ha definido dos configuraciones dentro: Release | x86 y Release | x64. Como puede ver, TestProject64.vcxproj solo tiene la configuración de Release | x64. Es necesario definir al menos una configuración en TestProject64.vcxproj; de lo contrario, Visual Studio no podrá agregar TestProject64.vcxproj a una solución.

Ahora es posible incluir tanto TestProject.vcxproj como TestProject64.vcxproj en la misma solución y compilar Release | x86 y Release | x64 al mismo tiempo.

0

Quizás me he perdido el objetivo de esta discusión. Con Visual Studio, vaya a Build/Configuration Manager. En la lista desplegable de la Plataforma de solución activa, seleccione "nuevo ...", aparece un cuadro de diálogo Nueva plataforma de solución. Seleccione x64 y acepte la copia predeterminada de. Cierre el cuadro de diálogo y el Administrador de configuración. Ahora abra Build/Batch Build. Compruebe las configuraciones que desea construir y compilar. Encontrará los ejecutables de compilación x64 separados de los ejecutables de Win32. Puede verificar que esto sea lo que se pretendía haciendo clic derecho en los ejecutivos y seleccionando Propiedades, seleccione la pestaña Compatibilidad. En la ventana desplegable puede verificar para ver en qué sistemas operativos se puede ejecutar el ejecutivo. Obviamente, puede haber algún otro ajuste que deba hacer para obtener todos los archivos de salida en su lugar correcto, pero este método parece algo más simple que engañando con la construcción que los descritos anteriormente.

0

que sugeriría para crear un proyecto de C++ Makefile simulada y luego invocar MSBuild el doble de ella:

msbuild myproj.sln /p:Configuration="Debug|Win32" 

msbuild myproj.sln /p:Configuration="Debug|x64" 
Cuestiones relacionadas