[question] MSBuild helper and conanbuildinfo.props versus conan_build.props

[michaelmaguire]

Apologies for the newb questions (A) through (E) below -- usually I use the cmake generator, but recently I've had to work on a project which uses the visual_studio generator.

(A) Can I confirm the MSBuild Conan helper does not automagically inject the generated conanbuildinfo.props for you?

Older documentation such as https://docs.conan.io/en/1.8/integrations/visual_studio.html provides steps for how to explicitly add the generated conanbuildinfo.props using the Visual Studio GUI, but the latest version https://docs.conan.io/en/latest/integrations/ide/visual_studio.html of the docs no longer shows this.

The documentation in https://docs.conan.io/en/latest/reference/build_helpers/visual_studio.html doesn't seem explicitly clear that I must do this myself.

(B) If I must add conanbuildinfo.props manually to my VS build config, is there a best practice for which kind of file to import conanbuildinfo.props into, e.g. which of .sln, .vcxproj or some associated .props file?

In some cases I've seen stuff like:

  <Import Project="$(ProjectDir)..\conanbuildinfo.props" Condition="exists('$(ProjectDir)..\conanbuildinfo.props')" />

(C) What is the best practice way to reference possible conanbuildinfo.props locations to work with both a mkdir build && cd build && conan install .. && conan build .. local build workflow as well as a conan create . workflow?

It seems like the MSBuild Conan helper does automatically inject conan_build.props into my build:

To inject the flags corresponding to the compiler.runtime, build_type and compiler.cppstd settings, this build helper also generates a properties file (in the build folder) that is passed to :command:MSBuild with :command:/p:ForceImportBeforeCppTargets="conan_build.props".

(D) Why does MSBuild inject conan_build.props but not conanbuildinfo.props?

Finally, (E) can I use something like user_property_file_name to pass in the generated conanbuildinfo.props explicitly in my MSBuild.build() command, instead of modifying my VS config files?

• I've read the CONTRIBUTING guide.

[Minimonium]

HI, Michael.

A) The information about the Visual Studio integration was moved: https://docs.conan.io/en/latest/integrations/build_system/msbuild.html#msbuild-integration
The second link you put is about the BuildHelper (usually in-cache variable injection) which is a different concern from Generators (providing dependency information).
B) You probably want to use SolutionDir (I don't recall the exact name), since you'd like to invoke Conan only once for a solution instead of a per-project generation.
C) Last time I worked with MSBuild generators was more than a year ago, so I don't recall the exact workflow - but there was an issue with relational property file placement and in-cache generation, you should watch out for that. In-cache builds generate into the root, which doesn't work with manually added property files without adding logic to move them in the build step.
D) I don't know the reason, my assumption would be - because generators are orthogonal to BuildHelpers, any other one could be used, so such explicit bindings between them should be forbidden.
E) Yes, as per documentation. But note that it'll not allow to properly utilize Conan for out-of-cache builds - conan install . -if=build.

[michaelmaguire]

Thanks for your responses!

The second link you put is about the BuildHelper (usually in-cache variable injection) which is a different concern from Generators (providing dependency information).

generators are orthogonal to BuildHelpers

I know they're separate, but I guess I assumed there might be a little integration, e.g. if I use the visual_studio generator I wouldn't have been surprised if the MSBuild BuildHelper did a little automagic detection of a conanbuildinfo.props file. Now I know it doesn't. Thank you.

E) Yes, as per documentation. But note that it'll not allow to properly utilize Conan for out-of-cache builds - conan install . -if=build.

Is there no way to use something like:

    def build(self):
        msbuild = MSBuild(self)
        msbuild.build("MyProject.sln", user_property_file_name=os.path.join(self.build_folder, "conanbuildinfo.props"))

to properly utilize Conan for both in- and out-of-cache builds?

[Minimonium]

Note that I consider conan build more of an in-cache, than out of cache. It'd work with conan build which you already mentioned, but there is no way to inject these props if you never invoke the method (say you open the solution itself and want to build it from inside, you need your dependencies!).

[michaelmaguire]

say you open the solution itself and want to build it from inside, you need your dependencies!)

Ah, good point.

Strangely, it turns out user_property_file_name doesn't seem to even work for me even in the conan build and conan create cases. Here's the error for conan build:

C:\dev\src\nx\platform\build>conan build ..

[...]

----Running------
> call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC/vcvarsall.bat" amd64 && msbuild "C:\dev\src\nx\platform\Platform.sln" /p:Configuration="Debug" /p:UseEnv=true /p:Platform="x64" /m:8 /p:PlatformToolset="v140" /verbosity:normal /p:ForceImportBeforeCppTargets="C:\dev\src\nx\platform\build\conan_build.props;C:\dev\src\nx\platform\build\conanbuildinfo.props"
-----------------
Microsoft (R) Build Engine version 14.0.25420.1

[...]

   20>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Current.targets(14,11): error MSB4115: The "exists" function only accepts a scalar value, but its argument "$(ForceImportBeforeCppTargets)" evaluates to "C:\dev\src\nx\platform\build\conan_build.props;C:\dev\src\nx\platform\build\conanbuildinfo.props" which is not a scalar value. [C:\dev\src\nx\platform\SolutionPlatformCommonTasks\SolutionPlatformCommonTasks.vcxproj]

and here's the error for conan create:

C:\dev\src\nx\platform>conan create . PORT/stable

[...]

----Running------
> call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC/vcvarsall.bat" amd64 && msbuild "C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\Platform.sln" /p:Configuration="Debug" /p:UseEnv=true /p:Platform="x64" /m:8 /p:PlatformToolset="v140" /verbosity:normal /p:ForceImportBeforeCppTargets="C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\conan_build.props;C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\conanbuildinfo.props"
-----------------
Microsoft (R) Build Engine version 14.0.25420.1

[...]

    20>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Current.targets(14,11): error MSB4115: The "exists" function only accepts a scalar value, but its argument "$(ForceImportBeforeCppTargets)" evaluates to "C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\conan_build.props;C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\conanbuildinfo.props" which is not a scalar value. [C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\SolutionPlatformCommonTasks\SolutionPlatformCommonTasks.vcxproj]

In both cases I can confirm it's setting the right directory for conanbuildinfo.props, but doesn't seem to like a semi-colon separated list of items for $(ForceImportBeforeCppTargets). Maybe a vs2015 issue?

[Minimonium]

Very well could be. Unfortunately, right now I can't try to reproduce the behaviour on different VS versions. If the behaviour doesn't work on older versions of Visual Studio - Conan at the very least should detect it and print a better error.

[memsharded]

Closing this ticket as outdated, this MSBuild integration is legacy, has been replaced for new ones in from conan.tools Please update and report if necessary, thanks!