-
Notifications
You must be signed in to change notification settings - Fork 29
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
Assembly (project) conventions should support Directory.Build.Props & Directory.Build.Targets #88
Comments
Ironically, |
Good spotting @flakey-bit. Fixing this would be reasonably straight-forward. I'll either get to it eventually, or someone can pick it up, I've labelled it a good first issue if someone happens to come by and wants to contribute. |
@andrewabest do you have some thoughts in mind as to how we could address this? |
I was thinking you would essentially have to replicate what MSBuild does - for any project, locate the directory.build.props file closest to it, and consider its values in applying the convention (docs) It can get a bit complex, but we could support the simpler version of it: don't support multiple props files, just support the nearest one per project. |
I think you're suggesting that we should fully evaluate the project XML and pass the "composed" If so, I agree 👍 It would be neat if we could do so by leveraging MSBuild, rather than reimplementing it. If we can find a way to do that I guess we'd get full support (multiple props files etc) "for free". |
Yup, strong agree there. I know dotnet-affected uses MsBuild internally (example), so it is very possible that that is a doable thing. |
MSBuild allows templating / "meta-programming" of
csproj
files viaDirectory.Build.Props
&Directory.Build.Targets
- see this page for more background but basicallyDirectory.Build.Props
allows setting default property values across all projects in the directory (recursively)Directory.Build.Targets
allows setting dependant property values (i.e. incorporating customizations from individual projects)At least that's my understanding - haven't used
Directory.Build.Targets
myself.Existing conventions like
MustNotReferenceDllsFromTransientOrSdkDirectoriesConventionSpecification
that parse the project XML are unaware of this functionality and are arguably broken as a result.For example, a
Directory.Build.Props
file could add an (assembly) Reference w/ a HintPath to all projects in the directory, whichMustNotReferenceDllsFromTransientOrSdkDirectoriesConventionSpecification
would be unaware of when examing the project XML, leading to false-negative.The text was updated successfully, but these errors were encountered: