Open natemcmaster opened 7 years ago
cc @AndyGerlicher @mlorbetske
This should be forbidden but I didn't have time to build a nice error message for it for RC2.
Although actually that failure is an SDK bug that arises when the project extension is neither .csproj
nor .vbproj
.
Rename main.proj
-> main.csproj
and you'll at least get a different error!
This should be forbidden
Can you explain why it should be? Is there some reason it could not be made to work?
I think it's really confusing to reason about where the implicit imports should be from imported files: do they unify, as other attributes like DefaultTargets
do, and thus get imported at the top/bottom of the initial proj file, or do they just bracket the contents of the imported file (that's the current behavior, since there's no error message).
We built the Sdk attribute to simplify end-user project files. If you're writing build logic to be imported, you should use an explicit import.
bracket the contents of the imported file
Seems most reasonable. The Sdk attribute is intended only for the scope of the file where its defined.
If you're writing build logic to be imported, you should use an explicit import.
For context, I'm writing a command line tool which needs to find property values in a csproj without using MSBuild APIs directly (because of https://github.com/Microsoft/msbuild/issues/1097) and without requiring an additional PackageReference
to work.
Seems most reasonable. The Sdk attribute is intended only for the scope of the file where its defined.
See, I'd go the other way and say if it were supported it should be unified. So I think it should just be banned, to avoid the confusion.
Importing a project that has the Sdk attribute causes Import to fail.
Repro:
Run
dotnet msbuild main.proj
Error: