web-dev-qa-db-fra.com

Comment puis-je utiliser une seule solution Visual Studio pour créer à la fois x86 et x64?

J'ai une solution Visual Studio x86 avec de nombreux fichiers de projet. Certains des fichiers DLL sont conçus pour fonctionner en tant que plug-ins pour d'autres applications sur le système d'un utilisateur.

Nous développons certains des fichiers DLL pour pouvoir prendre en charge les applications 64 bits. J'aimerais configurer la solution/les projets de manière à ce que le simple fait de frapper "Build" construira les versions x86 et x64 de ces fichiers DLL. La solution contient des projets C++ et C #.

Je me rends compte que "Batch Build" est capable de construire les deux, mais il serait plus pratique si les développeurs pouvaient simplement cliquer sur le même bouton que précédemment et avoir tous les fichiers de sortie DLL générés.

Voici quelques modifications que j'ai essayées sur un projet de test, mais que je n'ai pas pu travailler:

J'ai essayé de modifier le <Target Name="AfterBuild"> essayer:

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

Mais cela se traduit par l'erreur suivante:

C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets (565,5): erreur MSB4006: il existe une dépendance circulaire dans le graphique de dépendance cible impliquant la cible "Build".

Je pense que mes conditions empêcheront une récursion infinie, mais je comprends comment MSBuild ne pouvait pas le voir de cette façon.

J'ai aussi essayé:

<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>

Mais mon DefaultTargets semble être ignoré à partir de l'IDE de Visual Studio.

Enfin, j'ai essayé de créer un projet distinct qui importe le premier projet:

<?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>

Et cela jusqu'à présent s'est révélé le plus prometteur. Toutefois, Visual Studio semble ignorer mon paramètre OutputPath de ce nouveau projet et génère à la place le fichier EXE/DLL vers le chemin d'accès spécifié dans le projet d'origine. Il n'y a aucun bloc PropertyGroup que je puisse voir qui est en cours d'exécution dans le projet d'origine pour remplacer cela, donc je ne suis pas sûr de ce qui se passe.

35
PeteVasi

Nous faisons quelque chose de similaire pour construire des assemblages de base pour . NET Compact Framework .

Essaye ça:

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

L'importation d'un projet de cette manière fonctionne pour moi dans 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 a deux configurations définies à l'intérieur: Release | x86 et Release | x64. Comme vous pouvez le voir, TestProject64.vcxproj n'a que la configuration Release | x64. La définition d'au moins une configuration dans TestProject64.vcxproj est nécessaire, sinon Visual Studio ne pourra pas ajouter TestProject64.vcxproj à une solution.

Il est maintenant possible d'inclure TestProject.vcxproj et TestProject64.vcxproj dans la même solution et de construire Release | x86 et Release | x64 en même temps.

6
bogser

Pour C++, et s'il s'agit d'un projet dont les fichiers/paramètres ne changent pas souvent, une façon de le faire est de créer deux projets dans la solution, les deux projets faisant référence aux mêmes fichiers source. Ensuite, dans les versions x64, définissez un projet pour générer 64 bits et l'autre 32 bits. (Dans les versions x86, définissez l'une sur 32 bits et désactivez l'autre.)

Nous utilisons cela depuis un moment et cela fonctionne très bien.

Bien sûr, vous devez faire attention à ce que toutes les modifications que vous apportez à l'une soient également apportées à sa copie. c'est-à-dire que si vous ajoutez/supprimez un fichier ou modifiez son paramètre de construction, vous devez le faire à deux endroits. Les modifications du code source ne doivent encore être effectuées qu'une seule fois, car il n'y a toujours qu'une seule copie de chaque fichier source.

Et, bien sûr, vous pouvez décider que cela est plus complexe/risqué que de ne plus utiliser l'IDE. Dans notre cas, cela a très bien fonctionné.

4
Leo Davidson

Je pense que la meilleure façon de procéder consiste à appeler MSBuild à partir de la ligne de commande. Il ne devrait pas avoir besoin de modifier les fichiers MSBuild. Il suffit de courir

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

Je suppose que si un développeur utilise Visual Studio, il ne générera que les fichiers DLL afin qu'il puisse déboguer avec eux, et que vous ayez un processus de génération distinct si vous déployez réellement les fichiers DLL.

4
the_mandrill

Vous n'allez pas pouvoir faire cela avec l'interface utilisateur de Visual Studio. Pour cela, vous devrez pirater les fichiers MSBuild.

Essayez ce lien à partir de MSDN pour MSBuild Overview

0
Pieter Breed

Je suggérerais de créer un projet de Makefile C++ factice, puis d'appeler MSBuild deux fois à partir de celui-ci:

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

msbuild myproj.sln /p:Configuration="Debug|x64"
0
Paul B.

J'ai peut-être manqué le but de cette discussion.

À l'aide de Visual Studio, accédez au menu BuildConfiguration Manager. Dans la liste déroulante Active Solution Platform, sélectionnez "Nouveau ..." et une boîte de dialogue New Solution Platform apparaît. Sélectionnez x64 et acceptez la valeur par défaut Copier de. Fermez la boîte de dialogue et Configuration Manager.

Maintenant, ouvrez le menu BuildBatch Build. Cochez les configurations que vous souhaitez créer et construisez-les. Vous trouverez les exécutables de build x64 séparés des fichiers exécutables Win32.

Vous pouvez vérifier que ce sont bien ce que vous vouliez en cliquant avec le bouton droit sur les fichiers exécutables, en sélectionnant Propriétés, puis en sélectionnant l'onglet Compatibilité. Dans la fenêtre déroulante, vous pouvez vérifier dans quels systèmes d'exploitation le fichier exécutable peut être exécuté.

Évidemment, il peut y avoir d'autres ajustements que vous pourriez avoir à faire pour obtenir tous les fichiers de sortie à leurs emplacements appropriés, mais cette méthode semble un peu plus simple que de tromper avec la construction que celles décrites ci-dessus.

0
Mike Pliam