Microsoft.Net.Compilers.Toolset
From Version 4.6.0-2.23166.9 -> To Version 4.6.0-2.23171.5
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
We need to look at feature requests and approve them or reject them as appropriate. This adds a label to ensure we notice it as part of our triage process.
* Clarify what .default means
.default (in MSBuild code) followed an earlier spec that referred to it as <default> and omitted some details. This clarifies the meaning of .default.
* Replace <default> with .default
Today dynamic platform resolution is inconsistent due to the condition being based on `$(BuildingInsideVisualStudio)`, which is obviously only set in VS. Sln-based command-line builds wouldn't have that set though, so dynamic platform resolution would end up running. The comment on `_GetProjectReferencePlatformProperties` implies that sln-provided platforms should be used instead though, so this change switches the condition to check `$(CurrentSolutionConfigurationContents)` instead to make the experience consistent when building a sln in VS or command-line.
It will be removed in .NET 9; doing so should be discouraged.
Note that this does nothing by default, but we can change that in the SDK.
Fixes#8453
Context
BinaryFormatter is deprecated and will be removed in .NET 9. In addition to the possibility of using a modern MSBuild with an older framework, there are apparently ways you can exempt your project, so we are not currently removing it entirely, and this warning (which is off by default) can be disabled even if it is enabled in the SDK.
Changes Made
I deleted using System.Runtime.Serialization.Formatters.Binary; in GenerateResource, then put a warning before the one usage of BinaryFormatter. That isn't necessarily the best way to figure out where it's used, as it would be helpful to know early, so feel free to comment to that effect.
Then I disabled it via a property and will make a separate PR to enable it in the 8.0 SDK.
Testing
Notes
With setplatform negotiation there is no way to force a project to as a certain platform. there is but that will override the feature all together and there is no way to set the platform to be blank. Because of this there is effectively no way to force a dependent project to build as its default value since platform=default will cause overbuilding and does nothing. here is an example
A( building as x64) references project B (Available platforms x86;x64 with default platform x86)
Platform negotiation will negotate to x64 since its available but if we actually wanted to reference b x86 its not possible
because we should leave platform blank if we want to build b as x86 but
and platform= are not valid ways to do this
therefore the only way to build b as x86 is platform=86 but this will lead to overbuilding if b is built once with global props {platform = x86} and once with global props {}
The WPF repo and another Microsoft internal repo both reported problems
with the warning added in #8371. Since new warnings can be breaking
changes, demote the warning to a message.
Fixes#8605.
Customer reported that their app.config is not occasionaly getting updated in output folder.
Turns out to be a real issue specific to usage of AutoGenerateBindingRedirects.
Fixes AB#1741178.
Previously, when we saw the Item was empty, we'd jump out early. Fortunately, we already special-cased Count, and it turns out we can do the same with AnyHaveMetadataValue. Fixes#5113.
Update dependencies from https://github.com/dotnet/arcade build 20230221.1
Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.XUnitExtensions
From Version 6.0.0-beta.23114.5 -> To Version 6.0.0-beta.23121.1
For `msbuild -restore` scenarios `ProjectRootElementCache` cache used to be cleared for restore could have modified or added some project files (like *.directory.props etc...).
We can optimize it by keeping ProjectRootElements from immutable locations (like SDK) in that cache as those will be used by build following that restore.
This updates the bot that currently posts whenever any action is taken on a PR targeting 17.4 (i.e., opened, closed, reopened, commented on, etc.) to only post when the action is to open or reopen a PR. It also extends the branches for which this takes effect to include a number of vs* branches, including some that don't currently exist.
I think this is the final or penultimate iteration. Specifically, I don't think it will fire if you target main, then retarget to vs* without closing and reopening it...unfortunately, retargeting isn't something fabric bot understands. We can add "label added:Servicing-approved" to the list of options as a proxy. That isn't perfect, but it would make it slightly more robust and slightly noisier. I'm open to doing that or not doing that.
Fixes#6751
This change combines the solution configuration xml parsing which the project caching code and the tasks code uses. I did not add `SolutionProjectGenerator.AddPropertyGroupForSolutionConfiguration` into the mix as that's a write scenario and the other two are read scenarios. Maybe at some point the object model could be made more robust and support both the read and write scenarios, but whatever, this is incrementally better.
Note that the main motivation here is that the graph construction code currently does not support the sln-defined configurations, ie what the `AssignProjectConfiguration` target does, so I'll be working on a follow-up change for that. And instead of creating a third copy of this parsing logic, I thought I'd send this PR to consolidate the logic first.
Basically, `SolutionConfiguration.cs` is just ripped directly from `ResolveProjectBase.cs`, and then `ProjectCacheService` just uses `SolutionConfiguration` instead of parsing itself.
Ladi Prosek
dotnet-maestro[bot]
Rainer Sigwald
Forgind
Roman Konecny
David Federman
Michael Shea
Jan Krivanek
Marcin Krystianc
Jenny Bai