Runtime-specific build fails for projects with P2P references #696
Comments
|
Jus repro'd it with csproj files compatible with the new implicit items: This currently prevents creating self-contained applications that reference a library project. |
|
Is this the same as #527? @nguerrera |
|
I attempted an upgrade to RC3 on my project and ran into this issue. Is a short term fix anticipated or should I roll back until later? |
|
The problem seems to be that when @AlgorithmsAreCool Since I don't know a simple way to unset properties (is there any?), the only way I could make this work is by using and intermediate property: |
|
Interesting. @DustinCampbell was talking about this issue as well. I suspect the fix needs to be a mix of CLI and SDK similar to what you've done. The CLI should set /p:RequestedRuntimeIdentifier or some such property and have the SDK apply it to a project only if it's "applicable". We'll need the same thing for -f as well. @piotrpMSFT @livarcocc thoughts? |
|
Yes, we need to fix this. Per our hallway conversation, we should do the same thing for TargetFramework as well. This becomes a significant problem when trying |
|
Yes, setting a property at the command line overrides all projects that build in that invocation. Having an |
|
@rainersigwald: I you recall, this is the thing you and I chatted about last Friday. I don't think it's actually another concept. From the user perspective, MSBuild will do the thing it's always done. If you set RuntimeIdentifier or TargetFramework globally, it's applied globally. However, from the perspective of the CLI, setting the "--framework" or "--runtime" properties during "dotnet build" can be a bit smarter and do what the user very likely expects to happen. |
|
Yeah, it makes sense once you know the details--but understanding that If we had more time I might recommend renaming the inner per-project property to be a bit more esoteric and renaming the outer "overall requested" property to more closely match the CLI command line param . . . but that's a nit. |
|
So, what I would expect to happen: It should be possible to reference RID-specific and RID-agnostic projects that way.
@rainersigwald Since this will (and should) probably stick around for at least a decade or two, I'd like there to be a proper naming strategy ❤️ |
|
@srivatsn @piotrpMSFT Since this issue is separate from the other RID issues on my plate and time is of the essence could someone else drive this into CLI + SDK? |
That's fair, but people probably shouldn't be thinking of |
|
I was able to work around my issue with by making the |
|
@piotrpMSFT has graciously offered to help out with this. Assigning to Peter. |
|
I'm also hitting this when trying to upgrade foundatio: https://github.com/exceptionless/foundatio/tree/feature/dotnet |
|
@niemyjski are you specifying an RID when you build or publish? If so have you tried adding a |
|
Starting to take a look at this. Per @DustinCampbell's point, we want to address both:
Having looked at the SDK a bit, I'm less convinced now that the solution to these problems will be unified. This issue may end up being split into two, where we will want to fix both. More info to come. |
|
odd. I just tried @dasMulli's repro on CLI 1.0.0-rc4-004748 on osx with |
|
@piotrpMSFT really odd.. it repros with both |
|
Another workaround that works is to reference the library with: This would be easier to do with an update item from the SDK but I haven't explored what the effects are - probably loosing RID-specific items from projects. (did this ever work in project.json? RID-specific libraries?) |
|
@AlgorithmsAreCool Nope, no rids at all. |
Re-enable when dotnet/sdk#696 is resolved
Re-enable when dotnet/sdk#696 is resolved
|
Just thought I'd share that PR #828 should address the RID issue and does not introduce any new user gestures or concepts. We were able to keep the alternate property name as an internal contract between Referring projects and Referenced projects. I'm trying a similar approach with the |
|
No, it's not merged yet. I hope to have a CLI that exhibits this behavior available this week, however. Since The change impacts a lot of repos, so merging it will be a full-day dance I'm afraid. |
|
Fixed with #836 |
…0190606.7 (dotnet#696) - Microsoft.AspNetCore.Mvc.Api.Analyzers - 3.0.0-preview7.19306.7 - Microsoft.AspNetCore.Mvc.Analyzers - 3.0.0-preview7.19306.7
[ Moved from dotnet/cli#4992 ]
Steps to reproduce
test_app.zip
in test_app\App:
dotnet restoredotnet build -r win10-x64Expected behavior
build succeeds
Actual behavior
build fails with output:
Environment data
dotnet --infooutput:The text was updated successfully, but these errors were encountered: