Ignoring import conditions

[wuhkuh]

Hey! I'm currently reworking a dependency management tool, and I'm trying to leverage MSBuild in order to prevent hardcoding conventional file names (*.proj, Directory.Packages.props, etcetera). Some projects are highly customized, and conventional dependency management breaks pretty quickly.

The current strategy is to preprocess a project using the -preprocess flag, and then match PackageReference and PackageVersion items in the output.
Finally, the scope is reduced to the relevant files using the provided file paths, which can be found in the comment sections in the output.
Now, this should work great in theory, but this concept falters whenever MSBuild skips an import, because of conditions being evaluated as false (be it in Imports or ImportGroups).

I'm looking for a flag (or something of the likes) which causes MSBuild to ignore import conditions (thus generating the largest possible project). Is this currently possible? Would you consider accepting a pull request, if not?

Thanks!

[rainersigwald]

I don't think this could work because imports can be mutually incompatible. For instance some project type might have

<Import Condition="'$(ProjectSetting)' == 'true'" Project="WithSetting.targets" />
<Import Condition="'$(ProjectSetting)' != 'true'" Project="WithDefaultSettings.targets" />

And importing both could leave you in a highly undefined state.

Also,

The current strategy is to preprocess a project using the -preprocess flag, and then match PackageReference and PackageVersion items in the output.

I would recommend using the MSBuild API (with MSBuildLocator) instead; that will help with things like item Update operations that you might be missing with preprocessing.

[wuhkuh]

Hah, yeah, I hastily put this question together and realized this a couple days later. "Why would a conditional import be any different from any other conditional?" 😅 I will look into using the MSBuild API, and I hadn't even considered destructive operations yet.

These pointers were useful, thank you!