0

I found this Gem, which would be exactly what I need:

To build one project for multiple configurations when building just a single sln configuration without duplicating the project files:

Importing project is such manner works for me in Visual Studio 2010:

TestProject64.vcxproj <== the wrapper project

<?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" /> *<== the wrapped project*
  <ItemGroup Label="ProjectConfigurations">
    <ProjectConfiguration Include="Release|x64"> *<== just needed by VS*
      <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 has two configurations defined inside: Release|x86 and Release|x64. As you can see TestProject64.vcxproj has only Release|x64 configuration. Defining of at least one configuration in TestProject64.vcxproj is necessary, otherwise Visual Studio will not be able to add TestProject64.vcxproj to a solution.

Now it's possible to include both TestProject.vcxproj and TestProject64.vcxproj to the same solution and build Release|x86 and Release|x64 at the same time.

The question now is whether all Visual Studio Versions 2010 - 2015+ will handle this well:

  • Will VS try to edit/normalize the wrapper project somehow?
  • Will there be any weird behaviour when opening the project properties?
  • Will there be unexpected behaviour when building from the IDE vs. MSBUILD on the command line?

Bottom line: Is this something that can be deployed in a production team without major headaches down the road?

Use case (just anyone is interested):

  • X.sln
    • proj_cpp_dll ... C++ DLL can be built in 64 and 32 bit
    • proj_exe1_x64 ... needs the DLL in the 64bit version
    • proj_exe2_Win32 ... needs the DLL in the 32 bit version

One build pass via Release|Any CPU (or Release|Mixed Platforms) must (should) be enough to build this.

Community
  • 1
  • 1
Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • Seems likely the intellisense/find/navigate to experience will be rather suboptimal since all files occur twice. Anyway whether it works or not, the second answer (or varations to that) to the linked question is imo the better solution: tried, tested, easy to extend and no surprises (answers 'no' to your 3 questions:). If that doesn't hold you back: a simpler solution would be to just add a post-build event to the dll project which just does `` – stijn Feb 27 '16 at 08:37
  • @stijn - which one is the "secnd"? – Martin Ba Feb 28 '16 at 10:24
  • http://stackoverflow.com/a/1575053/128384 – stijn Feb 28 '16 at 10:49

2 Answers2

0

The Import element functionality hasn't changed since the beginning of MSBuild so the short answer to your three concerns is no.

However, it depends who needs to maintain it: if it's under your responsibility, then you can test a couple and rollout the rest. But it may lead others to the garden path if they're unaware of this solution. In this case, a safer and more verbose is using AfterBuild target as mentioned by @stijn

KMoraz
  • 14,004
  • 3
  • 49
  • 82
  • see my [own conclusion](http://stackoverflow.com/a/35867944/321013) - if you know anything, feel free to comment. – Martin Ba Mar 08 '16 at 12:54
0

Preliminary result is that ... this effectively does not work.

The wrapper project loads fine, VS doesn't touch it (at first glance) and the wrapper project also builds fine ... except:

Project references/dependencies are not built correctly.

The x64 wrapper has a dependency on another project. This other project dependency is however defined in the wrapped project.

So when you invoke the Build in the IDE, the x64 wrapper project will be built correctly, but its dependencies will "just" be built in the active solution platform -- which obviously is the wrong one (because otherwise, you woudldn't have needed the wrapper).

Bottom line: Works only if there are no project-dependencies on other projects within the solution -- which effectively means: doesn't work.

Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • You need to create two wrappers, for both x86 and x64, and apply it recursively to the dependencies as well. The wrapped project has no dependency, but the x86 wrapper depends on the x86 dependency wrapper, the x64 on the x64 and so one. – Remus Rusanu Sep 25 '18 at 09:20