Noah Gilson

That is expected. It should work if you add it to `Directory.Build.props` instead of the .csproj. Try that and let me know how it goes. https://docs.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#publishrelease If there is a...

I agree it's confusing, I'll investigate this. Thanks for taking the time to test it. @baronfel I do believe that was why but there is probably a work around.

I think the main reason this is different is we want it to only take place if we are `publishing` but not if we are `building`. Otherwise PublishRelease will also...

@DamianEdwards I added that and that's how `PublishRelease` currently works. It turns out I was wrong and that's not the issue. That part is fine, though you're right it doesn't...

Thanks for pulling that up, it can work but I agree it's not optimal. Good news, though! @BenVillalobos looked at this with me and it looks like even if `Optimize`...

That is correct, thank you for checking in and pushing for the right changes @DamianEdwards for our customers. I have been working on this amongst other issues due for 7.0.100....

From a standpoint of publishing a solution, this becomes more complicated. For example, if a solution contains a top-level project defining `PublishRelease=true` but depends on a class library who set...

We got this working on `dotnet publish foo.sln` but even with parallelization any approach to get it in for `7.0.100` is too much of a performance regression (roughly +7% for...

We decided to make it work for solutions via opt-in so the performance cost of checking this in a solution is not there by default. If a user tries to...

@DamianEdwards Indeed, I'm expecting it to go in rc.2. The PR has been thoroughly tested and reviewed, just waiting for the final thumbs-up at this point. But we are heavily...