Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Common Flat Build Output via Directory.Build.props/.targets #7300

Open
nietras opened this issue Jan 15, 2022 · 3 comments
Open

Common Flat Build Output via Directory.Build.props/.targets #7300

nietras opened this issue Jan 15, 2022 · 3 comments
Labels

Comments

@nietras
Copy link

nietras commented Jan 15, 2022

In Common Flat Build Output I thought I'd finally found a clean solution to a long search for getting flat build output from msbuild for .NET. Unfortunately, this approach has a serious flaw as reported in F12 not working across C# projects in solution perhaps due to customized output paths in VS22. I then tweeted a bit about trying to fix the issue in https://twitter.com/nietras1/status/1462885254755147780 but I cannot find a good solution for it that does not require changing csproj files.

The premise is that I want to change the build output fully by only changing the Directory.Build.props/.targets in a common parent directory, and not have to do any changes to csproj for this since that is very cumbersome for a solution with hundreds or thousands of projects. One of the problems here then seems to be that e.g. TargetFramework is not defined at the point of Directory.Build.props. The same issue btw relates to Configuration and Platform and this has been a long standing issue since many then try to use these but they are often not defined at the point when Directory.Build.props is imported. Import order is somewhat covered in #2767 (comment) as far as I can tell.

Source code from blog post with the go to definition issue:
CommonFlatBuild.zip

For a MSBuild novice like me I would think we are missing a set of extension points that complement the "outermost" Directory.Build.props/.targets so we perhaps instead could have something like:

Directory.Build.props
<LOTS OF IMPORTS ETC. props>
Directory.Project.props
<Project File>
Directory.Project.targets
<LOTS OF IMPORTS ETC. targets>
Directory.Build.targets

that is we would add "innermost" complements to Directory.Build.* in the form of say Directory.Project.*. This should cover more use cases.

However, perhaps there is another way of doing what I want that I just can't find.

cc: @KirillOsenkov @sharwell

@nietras nietras added the needs-triage Have yet to determine what bucket this goes in. label Jan 15, 2022
@sharwell
Copy link
Member

I'm guessing a custom SDK would resolve this with minimal modification of the projects. I haven't created one of those before so I'm not sure the process.

@nietras
Copy link
Author

nietras commented Jan 23, 2022

I don't know how to that either or if that's a simple viable path. However, @Stefan75 appears to have found a possible solution as mentioned in nietras/nietras.github.io#21 using:

<PropertyGroup>		 
<BeforeTargetFrameworkInferenceTargets>$(MSBuildThisFileDirectory)BeforeTargetFrameworkInference.targets</BeforeTargetFrameworkInferenceTargets>
</PropertyGroup>

If there could be issues with that it would be great to know.

@benvillalobos benvillalobos removed the needs-triage Have yet to determine what bucket this goes in. label Feb 10, 2022
@psollberger
Copy link

I'm a bit late but perhaps this is useful to someone.

CustomBeforeMicrosoftCommonProps, CustomBeforeMicrosoftCommonTargets, CustomAfterMicrosoftCommonProps and CustomAfterMicrosoftCommonTargets can be of good use as well.

See: https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2022#customize-all-net-builds

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants