[bug] Possible issue with property sheet generation

[RudolfNetzel]

Recently, after an update from conan v1.34 to v1.39, I encountered an error regarding generated property sheets for Visual Studio. Here, property sheets could not be found since they were not generated and Visual Studio is trying to load them. Just like before the update, I only add ‘conandeps.props’ which will then load all other ‘.props’.

I tested it using a simple example in which the conenfile.py only has one requirement:
self.requires("PACK_A/2.7.0 ")

PACK_A also has some requirements:
self.requires("PACK_B/1.0.0 ", private=False)
self.requires("PACK_C/2.1.0 ", private=True)
self.requires("PACK_D/6.2.0 ", private= True)
self.requires("PACK_E/6.0.0 ", private=True)

We use the following command to trigger the generation of the ‘.props’ files:
conan install . -if "Implementation\Props" -g MSBuildDeps -pr:b common\windows%%x -pr:h common\windows%%x -s build_type=Debug

For PACK_A and PACK_B three ‘.props’ files are generated: .props, debug_x64.props, and vars_debug_x64.probs. For PACK_C to PACK_E no ‘.props’ files are generated.

The conan_PACK_A_debug_x64.props now contains the following conditional includes:
Import Condition="'$(conan_PACK_B_props_imported)' != 'True'" Project="conan_PACK_B.props"
Import Condition="'$(conan_PACK_C_props_imported)' != 'True'" Project="conan_PACK_C.props"
Import Condition="'$(conan_PACK_D_props_imported)' != 'True'" Project="conan_PACK_B.props"
Import Condition="'$(conan_PACK_E_props_imported)' != 'True'" Project="conan_PACK_E.props"

Visual Studio now somehow evaluates the import conditions of PACK_C to PACK_E too TRUE.
My question is, if this is a bug of the generation? Should the conditional imports also not be generated for transitive requirements with private=True like the ‘.props’ files? Or is there in error on my side and I forgot some option or something else important.

Environment Details (include every applicable attribute)

• Win10
• Visuals Studio 2019 (v142)
• Conan version: 1.39
• Python version: 3.6.0

[memsharded]

The conditional includes are not showing on your issue above, could you please check it?

We have been changing the internals of MSBuildDeps and other generators, it is possible that this is a bug.

[memsharded]

Trying to reproduce with the following test:

def test_private_transitive():
    # https://github.com/conan-io/conan/issues/9514
    client = TestClient()
    client.save({"dep/conanfile.py": GenConanfile(),
                 "pkg/conanfile.py": GenConanfile().with_require("dep/0.1", private=True),
                 "consumer/conanfile.py": GenConanfile().with_requires("pkg/0.1")
                                                        .with_settings("os", "build_type", "arch")})
    client.run("create dep dep/0.1@")
    client.run("create pkg pkg/0.1@")
    client.run("install consumer -g MSBuildDeps")
    assert "dep/0.1:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Skip" in client.out
    deps_props = client.load("conandeps.props")
    assert "conan_pkg.props" in deps_props
    assert "dep" not in deps_props

The private dependencies are not added to the conandeps.props file, seems to be working fine here.

[RudolfNetzel]

In our case the conandeps.props looks also fine, there is only one expected import condition:
Import Condition="'$(conan_PACK_A_props_imported)' != 'True'" Project="conan_PACK_A.props"

I think the problem is within the conan_PACK_A_debug_x64.props.
The conan_PACK_A_debug_x64.props now contains the following conditional includes:
Import Condition="'$(conan_PACK_B_props_imported)' != 'True'" Project="conan_PACK_B.props"
Import Condition="'$(conan_PACK_C_props_imported)' != 'True'" Project="conan_PACK_C.props"
Import Condition="'$(conan_PACK_D_props_imported)' != 'True'" Project="conan_PACK_B.props"
Import Condition="'$(conan_PACK_E_props_imported)' != 'True'" Project="conan_PACK_E.props"

[memsharded]

Ok, that makes sense. Yes it is a bug, private dependencies are not being fully managed yet by the new generators like MSBuildDeps.

I have proposed a fix for 1.40 in #9517, to be released hopefully next Monday, thanks for reporting!