Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.XUnitExtensions
From Version 8.0.0-beta.24311.3 -> To Version 8.0.0-beta.24324.1
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
This will help with using these from new code that's nullable-
aware. The biggest helpful bit is the `[NotNull]` ones that let the
compiler know to assume that parameter is non-null in the rest
of the method, which should eliminate the need for some `!`s
after calling `VerifyThrowArgumentNull(whatever)`.
* add BuildCheck.UnitTests to slnf
* add test for replaying binlog of analyzed build
* fixed buf for BuildCheckResultWarning
* changed the test for error case
* fixed bug for BuildCheckResultError
* set RawMessage for BuilCheck results instead of speacial casing in BuildEventArgsWriter
* remove using
* add skip back to the flaky test;
add skip to the new test
These results are uninteresting since drop.app is not something MSBuild ships or
redistributes, and BinSkim is currently breaking the build. Add to the baseline to get the
build working while Arcade is working to update to a new drop.app.
* Add a message for LongPathsEnabled
* refactor LongPathsEnabled logic to a ternary enum
* Elaborate and comment the resource string
* translations
* add state for registry not set
* deduplicate
* Update dependencies from https://github.com/dotnet/roslyn build 20240613.9
Microsoft.Net.Compilers.Toolset
From Version 4.11.0-3.24307.2 -> To Version 4.11.0-3.24313.9
* Update dependencies from https://github.com/nuget/nuget.client build 6.11.0.101
NuGet.Build.Tasks
From Version 6.11.0-rc.87 -> To Version 6.11.0-rc.101
---------
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.XUnitExtensions
From Version 8.0.0-beta.24270.4 -> To Version 8.0.0-beta.24311.3
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Initially, this delegated thread safety to a `SyncTextWriter`, but the
object graph was hard to understand, so it was replaced with a has-a
`SyncTextWriter` relationship, but this lost the timer-based call to
`Flush()` to send the output to the client.
The docs on `MethodImplOptions.Synchronized` also advise that it can be
risky due to locking on the object itself, so manage the syncronization
with an explicit lock object over the underlying `StringWriter` instead.
Fixes#10013.
These resources were added to the ARM64 subfolder in #10023,
but I don't think they're needed: there's no .NET Framework 3.5
for ARM64 and `MSBuildTaskHost.exe` isn't in the ARM64 folder
itself, so I think we can remove these files.
There was also a build race condition involving the .resources.dll
files, which is how I found this. The `Arm64ProjectReference`
wasn't enough to get them built.
---------
Co-authored-by: Jenny Bai <v-jennybai@microsoft.com>
* Localized file check-in by OneLocBuild Task: Build definition ID 9434: Build ID 9736500
* Localized file check-in by OneLocBuild Task: Build definition ID 9434: Build ID 9736500
* Localized file check-in by OneLocBuild Task: Build definition ID 9434: Build ID 9736500
* move LockCheck to Utilities and make it public, update resources
* add doc comments
* refactor windows condition inside LockCheck
* use LockCheck in other Tasks which delete/modify files
* improve method summary
Co-authored-by: Rainer Sigwald <raines@microsoft.com>
---------
* Update dependencies from https://github.com/dotnet/roslyn build 20240607.2
Microsoft.Net.Compilers.Toolset
From Version 4.11.0-3.24301.1 -> To Version 4.11.0-3.24307.2
* Update dependencies from https://github.com/nuget/nuget.client build 6.11.0.87
NuGet.Build.Tasks
From Version 6.11.0-preview.2.76 -> To Version 6.11.0-rc.87
---------
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
* Enable CA2000 in tests
* Fix the process ca2000 error
* disabel the warning CA2000 in StartToolProcess
* Refactor the XmlReader create
* Fix new CA2000 after merge
* Fix the typo error
* Fix the indent
---------
Co-authored-by: Gang Wang <v-gaw@microsoft.com>
Fixes#9881
### Context
We believe there is value in flagging cases where the same file is written by more than one task during a build. https://github.com/dotnet/source-build/issues/4390 is an example of a recent hard-to-diagnose build issue that could have been prevented by this analyzer.
### Changes Made
This PR adds a new built-in analyzer and makes a few supporting changes.
### Testing
- Existing and new unit tests.
- Built a few larger repos with the analyzer enabled.
### Notes
The changes contain a fix/workaround for #10176.
* Update dependencies from https://github.com/dotnet/roslyn build 20240601.1
Microsoft.Net.Compilers.Toolset
From Version 4.11.0-2.24274.2 -> To Version 4.11.0-3.24301.1
* Update dependencies from https://github.com/nuget/nuget.client build 6.11.0.76
NuGet.Build.Tasks
From Version 6.11.0-preview.2.66 -> To Version 6.11.0-preview.2.76
---------
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Fixes#10180
### Context
#10102 made certain batching scenarios fail with a null-ref exception.
### Changes Made
Moved the call to `LogTargetBatchFinished` to make sure that the loop doesn't exit with null `targetLoggingContext`.
### Testing
New unit test with a repro project.
* Update dependencies from https://github.com/dotnet/roslyn build 20240524.2
Microsoft.Net.Compilers.Toolset
From Version 4.10.0-3.24259.10 -> To Version 4.11.0-2.24274.2
* Update dependencies from https://github.com/nuget/nuget.client build 6.11.0.66
NuGet.Build.Tasks
From Version 6.10.0-preview.2.97 -> To Version 6.11.0-preview.2.66
---------
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.XUnitExtensions
From Version 8.0.0-beta.24266.3 -> To Version 8.0.0-beta.24270.4
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Fixes#9915
Context
#9789 added a template for custom analyzer.
In order for that to be usable by our customers - we need to be publishing this to nuget feed along with our other binaries. So we should have the package produced from our repo - ideally as part of our build script
Changes Made
Create a template package project with property <GeneratePackageOnBuild>true</GeneratePackageOnBuild>that pack the templates into a nuget package when build. Add the package project in the msbuild solution in order to build the project.
Testing
https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=9602998&view=artifacts&pathAsName=false&type=publishedArtifacts in the packageArtifacts folder.
image
Localized file check-in by OneLocBuild Task: Build definition ID 9434: Build ID 9634972
This is the pull request automatically created by the OneLocBuild task in the build process to check-in localized files generated based upon translation source files (.lcl files) handed-back from the downstream localization pipeline. If there are issues in translations, visit https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is https://aka.ms/onelocbuild and the localization process in general is documented at https://aka.ms/AllAboutLoc.
Fixes#9662
Context
When we use TL, we save the console output encoding to a variable, change the encoding
to UTF8 for the logging duration and attempt to set it back to the previous value during the Terminal Logger shutdown. It fails in some terminal emulators. It seems to be either a bug of the terminal emulator or Console.OutputEncoding property.
Changes Made
Wrapped the setting of the console output in try-catch block.
Testing
Unit tests
* Initial PR checklist content
Snapshot of the now-current release https://github.com/dotnet/msbuild/issues/9914.
* Uncheck!
* Section headers
* Variables for the releases
* Clarifications and update stale version
* fixup! Variables for the releases
* Clarify ff instructions
* Crispen OptProf
* fixup! Variables for the releases
* More tweaks
### Context
This PR targets the specific scenario of constructing a ProjectInstance object from the evaluation data stored in CPS's evaluation cache, with the goal of saving memory and execution time during Solution Load.
In a previous change (2a789cd8bd), I modified the ProjectInstance logic to rely on virtualized collections that are wrappers around the CPS evaluation cache's collection. The ProjectPropertyInstance, ProjectItemInstance, etc. objects were created ahead of time and associated with the corresponding CPS object, such that only one copy of the collections needed to exist.
In this PR, the goal is to extend that further such that the ProjectPropertyInstance, ProjectItemInstance, etc. values are only created when they're actually needed, and some new logic is introduced for reading Property values and Metadata values that allows avoiding creating the ProjectPropertyInstance and ProjectMetadataInstance when all that's sought is the EscapedValue string.
### Changes Made
The collections for ProjectInstance's _properties, _itemDefinitions, _items, _itemsByEvaluatedInclude, _globalProperties, _targets, _importPaths, and _importPathsincludingDuplicates collections are replaced with specialized virtualizing collections that wrap the associated CPS collection. These collections create the ProjectPropertyInstance et al objects only when a caller requests them. Additionally, the ProjectItemDefinitionInstance's metadata collection, and the ProjectItemInstance's ItemDefinition and Metadata collections are all similarly replaced by a virtualizing collection.
ProjectInstance's _environmentVariableProperties still relies on the ProjectCollection's EnvironmentVariables, but a new SharedReadOnlyEnvironmentProperties collection is introduced that does not hand out copies of the PropertyDictionary, but instead the same PropertyDictionary instance whose backing collection has been made read only.
### Testing
Manual verification of impacted scenarios and performance measurements.
Contributes to #9881
### Context
When `TaskParameterEventArgs` represents an output parameter of a task, it currently does not capture the name of the parameter. This information is generally useful as multiple output parameters can be assigned to the same item, and it's important for the BuildCheck infrastructure to provide a consistent object model to build analyzers.
Additionally, output parameters that are assigned to properties are currently logged as textual log messages `Output Property: {0}={1}` which miss the name of the parameter as well.
### Changes Made
Added two new properties on the `TaskParameterEventArgs` class, including the requisite serialization support. Updated logging to populate the properties with the name of the task parameter and the name of the build property, respectively, and updated BuildCheck infra to expose it to analyzers subscribed to task parameter events.
All task parameters are now logged as the structured `TaskParameterEventArgs` and the kind of parameter (input, output to property, output to item) can be determined by examining the args.
### Testing
- Tweaked existing unit test and updated the relevant BuildCheck test.
- Verified that when using the standard console logger, the resulting textual log is identical.
- Verified that binlog viewer without the corresponding changes displays the forward-compat warning about unknown data.
### Notes
- Complementary binlog viewer PR: https://github.com/KirillOsenkov/MSBuildStructuredLog/pull/780
- The change is behind a changewave because it is technically a breaking change for third party loggers.
Co-authored-by: Rainer Sigwald <raines@microsoft.com>
dotnet-maestro[bot]
Jenny Bai
Farhad Alizada
AR-May
Rainer Sigwald
Surayya Huseyn Zada
Jan Provazník
David Federman
dotnet bot
Jan Krivanek
YuliiaKovalova
Jakub Jareš
Roman Konecny
Ladi Prosek
SGreen
Mariana Dematte