msbuild
msbuild copied to clipboard
dotnet
-targets command-line option doesn't work with solution file
Issue Description
-targets command-line option doesn't work when building a solution
Steps to Reproduce
MSBuild.exe -targets SomeSolution.sln
Expected Behavior
List the available targets in each project
Actual Behavior
Builds the solution
Versions & Configurations
Windows 10 MSBuild version 17.3.0-preview-22307-01+bfd80ab16 for .NET Framework
In addition to "working on solutions at all", this should have a blurb about the dynamically-generated solution targets that delegate to all projects.
In addition to "working on solutions at all", this should have a blurb about the dynamically-generated solution targets that delegate to all projects.
Agreed, I had to dig into a metaproj with vs code to understand it more, and even then it wasn't easy to parse.
The -targets and -preprocess switches are both documented as not executing a build process. However, both will exclude a solution file from their respective operations and then incorrectly build the solution file.
It seems like the first pass of a fix would be to not build when either of these two switches are present. If the file is a solution, then the operation isn't performed because it isn't supported but also no build is performed. I have a sense already of how to make this fix.
Should -targets support solutions? I'm not sure that I fully understand the comments from @rainersigwald and @BenVillalobos but it seems the answer is 'Yes'.
Should -preprocess support solutions? Is -preprocess on a solution essentially the same output as setting MSBUILDEMITSOLUTION? Should a separate issue be created for the -preprocess switch with a solution?
Should
-targetssupport solutions?
Yes. In addition to "listing all the targets", I'd like to see a special case for solutions that also says "We'll make up a target for any target name you specify and pass it to all of the projects in the solution, so this isn't an exhaustive list".
Should
-preprocesssupport solutions? Is-preprocesson a solution essentially the same output as setting MSBUILDEMITSOLUTION? Should a separate issue be created for the-preprocessswitch with a solution?
IMO yes, yes, and yes. But this isn't super high pri IMO; I'd be quite happy with "it just errors out and doesn't accidentally build"
@rainersigwald Thanks for the response. Please assign this issue to me.
I wasn't aware that it is now possible to pass a target to the solution that doesn't exist on the solution and that the solution will pass the target to all projects. I have had to work around this in the past. Now I understand the comment about the "dynamically-generated solution targets".
Thanks
It was implemented in https://github.com/dotnet/msbuild/pull/1497, I believe.
Some observations: Given a sol.sln that contains projects a.proj and b.proj;
The ability to pass project name and target to the solution (e.g the following code) is documented.
msbuild sol -target:b:fred
The ability to pass any target to the solution and the solution will invoke the target on each project (e.g the following code) does not appear to be in the documentation.
msbuild sol -target:fred
There is an issue. The build will have an error if any of the projects in the solution don't provide the target. i.e. if 'fred' is a target in b.proj but not in a.proj, then a MSB4057 error will be reported on a.proj. The solution has project specific targets but doesn't know to skip non-existent targets.
@rainersigwald It may be helpful to split a new issue out from this issue:
- [x] Don't build a solution when -preprocess or -targets is passed on the command line (addressed by #8588)
Implementing -targets for solution files would remain with this issue.
Would this command also work with slnf ( solution filter files )?
Sorry for creating a duplicate issue, searching for "target" had way too many hits and I couldn't figure out how to search for what I wanted.
We should make sure it works for .slnf too, yes. I suspect that might happen "for free" when fixing .sln but there might be some more work required.
PR #8588 stops the incorrect behavior of building a solution when either -preprocess or -targets is provided.
Implementing -preprocess and -targets for solutions will be a separate PR on this issue.
Was this closed too soon? The description of https://github.com/dotnet/msbuild/pull/8588 says it fixes this "Partially".
Yes, this issue should be reopened.
The current PR 'fixes' the incorrect behavior of building the solution when a -preprocess or -targets switch is passed, but doesn't implement the switches for solutions.