Add command line options to manipulate imports

[yatli]

msbuild implicitly import files during various stages. there is no (obvious) way to inspect or modify what is imported, at the moment.

for example (dotnet/sdk#887), sometimes we find overriding a property with /p flag is too late, but the only chance of early import relies on heuristics in finding Directory.Build.props -- a wildcard that might be "too greedy" (#762).

can we get command line options to manipulate such behaviors? e.g. if specified, overrides the above heuristic and use a given file instead, or list the files imported, etc.

Also see #3166 and https://github.com/dotnet/roslyn/blob/master/src/Workspaces/CoreTestUtilities/Resources/Directory.Build.props

[dasMulli]

In theory, -p:DirectoryBuildPropsPath=/path/to/some.props should already work.

Would be interesting to change _DirectoryBuildPropsFile to a public property to allow changing the file name.
Currently -p:_DirectoryBuildPropsFile=foo.props should already work and change the file name from Directory.Build.props to foo.props while maintaining the hierarchy search logic.
Is that what you are looking for?

[dasMulli]

There's also a ImportDirectoryBuildProps one could set to false

[yatli]

hi @dasMulli!

Yeah, that property would solve my problem.
I remember seeing this somewhere, but was too afraid that a /p flag will come in too late. Will give it a try.
Also, we could figure out what's imported via /pp and look through the import comments. It's just not that obvious. :)

btw, will it still look up the hierarchy until root if I override the DirectoryBuildPropsPath with a custom name? from your example, intuitively, it won't do this because an absolute path is given.

[dasMulli]

No, DirectoryBuildPropsPath is the full path, _DirectoryBuildPropsFile would do the lookup but it's not really a public property (hence the underscore).
It would be interesting if MSBuild maintainers would be accepting a change to make this property public (remove the underscore).
Personally, I'd rather not and require users to always use Directory.Build.props for consistency. In there, build authors can add additional logic to search for other files or import other known files.

/p(-p) sets global properties which are present from the beginning and can't be overwritten by the static portion of project files (with an exception involving <Project TreatAsLocalProperty="…">) so you don't need to worry about it applying too late.

[yatli]

overriding DirectoryBuildPropsPath works for me, thanks @dasMulli !

I too would rather not let users create arbitrary recursive lookups. Directory.Build.props at least looks like a build system-related file, while arbitrary .props file may be everywhere in the filesystem.

I'm still not very sure about /p flag (also discussed here: #1603)

If I specify /p:BaseIntermediateOutputPath= at command line, I get inconsistent result -- the intermediate path indeed moved to the desired location, but project.json etc. remained in the obj folder, hence my concern about "too late". :)

[dasMulli]

The BaseIntermediateOutputPath trouble isn't/wasn't related to the order of definitions but rather NuGet and MSBuild using different properties for essentially the same concerns.
If you still have troubles with it, I'd suggest logging a fresh issue somewhere to discuss implications. The most difficult part about it is making sure that restore runs and builds have the same global properties set via CLI parameters. I believe Directory.Build.props may be the best option here to ensure a consistent experience.

Directory.Build.props at least looks like a build system-related file

It is also more in-line with Directory.Build.rsp which is not implemented in MSBuild files (common props/targets) but in MSBuild itself, thus the name can't really be changed in a "good/consistent/compatible" way.

[dasMulli]

ad BaseIntermediateOutputPath: also see #3695.
TL;DR don't set it for solutions.
But I think it should work for stand-alone projects. Or not using a rooted property / common location.

[yatli]

The issue #3695 describes a problem very similar to mine. Even if I both override BaseIntermediateOutputPath and then specify /p during a dotnet restore proj_path, it simply ignores the settings and writes project.assets.json and the friends to proj/obj/.

[yatli]

I think this issue can be closed now -- recommend documenting DirectoryBuildPropsPath somewhere though. Thanks @dasMulli for clarifying everything!

[yatli]

btw I'm rolling a cmake-dotnet integration module, FYI:

Z3Prover/z3#1423

https://github.com/Microsoft/GraphEngine/blob/master/cmake/FindDotnet.cmake

[yatli]

@dasMulli some new findings here, even if I override DirectoryBuildPropsPath, during package restore, Directory.Build.props is choosen and my custom props file is ignored.

This brings complexity to parameterized package reference, e.g. <PackageReference Include="..." Version="$(SOME_DEP_VERSION)" /> -- as our package version is refreshed on build, we have to update the root Directory.Build.props also on build -- and this breaks the out-of-tree building principle.

(edited)

[dasMulli]

@yatli that sounds more like a caching issue.. do you use -restore to restore and build during the build or -t:Restore;Build? (which doesn't work if you change xml content in between)
Do you have a sample project that reproduces this behaviour?

[yatli]

@dasMulli I use dotnet restore /p:.....

looks like DirectoryBuildPropsPath expects a full path, and it correctly picks up the custom props when I give it a proper path.

[dasMulli]

yeah if it isn't a full path, it will be relative to the project directory. And if you do it on a solution, it will be relative to each project individually..