At least one person skimmed over the section we wanted to emphasize (`-bl`) and focused on `MSBUILDDEBUGENGINE`, sharing lower-fidelity logs that are harder to understand.
Remove the "Preferred way" callout--it's preferred in that section but not in general. Add a section header for command-line builds. Add some samples there.
Fixes source building under FreeBSD where a symlink has not been made for bash
Context
/bin/bash is standard under OSes that ship with bash installed by default. FreeBSD does not have bash as a default shell.
Changes Made
For portability /usr/bin/env bash is used on the shebang line. This also bring it inline with other dotnet repos.
Testing
none needed?
Notes
env is standard at this point. I have been unable to find a non-historic UNIX-like system that places env in a location exclusively that is not /usr/bin/
Update dependencies from https://github.com/dotnet/arcade build 20230411.7
Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.XUnitExtensions
From Version 6.0.0-beta.22531.5 -> To Version 6.0.0-beta.23211.7
A top comment from the folks who've seen this is that the absolute paths take up a bunch of space and making them relative would be a UX nicety. This is the simplest possible approach for that: string prefix truncation with no path normalization or attempt to construct a relative path.
Summary
The for sln-based builds, the AssignProjectConfiguration task ends up using the Configuration and Platform defined in the sln rather than passing through the global properties from the referencing project or attempting to do dynamic platform negotiation. This change adds equivalent functionality to graph construction.
A concrete scenario this fixes for graph-based builds using an sln file is that most csproj define the "x86" platform while most vcxproj define "Win32". Previously for a graph build, if the csproj referenced the vcxproj, the platform passed to vcxproj would be x86, not Win32. Even worse, the vcxproj would be an entry point anyway, so it would double-build with both x86 AND Win32, which leads to race conditions.
Customer Impact
Microsoft-internal customer using sln-based builds will be able to opt-into graph builds
Regression?
No
Testing
Manual validation in the customer repo, as well as added unit tests
Risk
Low. Graph builds are a less-used feature, and this adds parity to what non-graph builds and VS-based builds do. It's unlikely that any behavioral change would be impactful due to those other scenarios presumably working for customers who may be using graph builds.
Partly Fixes#8391
Context
Ensure all new strings used in the logger are localizable
Changes Made
introduce strings in resx
using such resource strings
modify code to allow better localization (from write(part1); write(part2); write(part3) into str = formastringfromresources(); write(str)
Testing
local
unit tests
Detected while working on #8413
Context
outputIsScreen is always falls on on non-windows OS causing /tl:auto to reject live logger
Changes Made
see files
Testing
locally
Notes
would affect MSB server VT100 output coloring as well.
In recent dogfood VS builds we've gotten many IDE0251 suggestions, some warnings escalated to errors in StringTools. Follow many of those suggestions, but bump the rule down to suggestion always, like the related IDE0250.
Contributes to dotnet/sdk#19506
This fixes an issue where VS design-time builds would fail when reference assemblies could not be found.
By allowing the design-time build to continue, the .NET Project System will the nominate a restore which may bring in a package that provides those reference assemblies.
Without this addition, the task will fail and the build will end early, such that the restore does not occur and progress is not made.
This helps when users do not have targeting packs installed (such as for out-of-support versions of .NET Framework, like v4.5). With this change, a reference assembly package (like Microsoft.NETFramework.ReferenceAssemblies.net45) may be downloaded for the user to compile against.
Tested locally. See discussion in linked issue for further details.
This pull request updates the following dependencies
From https://github.com/dotnet/arcade
Subscription: fc4faec0-9ee6-43b9-bc7a-08da8607f4c7
Build: 20230421.7
Date Produced: April 21, 2023 7:07:19 PM UTC
Commit: 3d9c9a4d3d893e903bb3295fd5b55b8e40699888
Branch: refs/heads/release/6.0
Updates:
Microsoft.DotNet.Arcade.Sdk: from 6.0.0-beta.23167.1 to 6.0.0-beta.23221.7
Microsoft.DotNet.XUnitExtensions: from 6.0.0-beta.23167.1 to 6.0.0-beta.23221.7
NuGet.Build.Tasks
From Version 6.5.0-rc.149 -> To Version 6.7.0-preview.1.16
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Forgind <12969783+Forgind@users.noreply.github.com>
Relates to:
#4795#8405
Context
Documenting some aspect of tailoring behavior of references. Capturing as well resolution/workarounds for the listed comunity reported issues
---------
Co-authored-by: Rainer Sigwald <raines@microsoft.com>
This reverts commit a93882f.
This is a temporary fix for #8684
The current plan is to revert #8275 in 17.6, as it caused some difficulties, and try to bring it back in 17.7 via #8685.
Summary
#8275 fixed a longstanding confusing and unfortunate behavior in MSBuild in which passing the Copy task a symlink as its destination would copy the source file onto the destination of the symlink rather than overwriting the symlink. Unfortunately, it also introduced a new issue in which copying a file onto itself could often just delete the file instead of copying anything. Customers reported this issue.
Customer Impact
Projects that copy a file onto itself using the Copy task without passing identical paths for source and destination instead delete the file without necessarily even logging an error.
Regression?
Yes, from #8275.
Testing
Unit tests and manually tested that the repro described in #8684 no longer works.
Risk
Minimal (straight revert of the commit that caused the bug)
---------
Co-authored-by: Forgind <Forgind@users.noreply.github.com>
Fixes#8579
Context
MetadataElement of an ItemElement doesn't have line&col of Location set despite those are created from known xml.
This way errors referencing the Location from metadata would end up pointing to location (0, 0) in the file.
Reason
This happens only to XmlElementWithLocation (as opposed to XmlAttributeWithLocation) during creating XmlElementWithLocation from scratch (during parsing phase that doesn't have the reader with locations already available) from an existing XmlAttributeWithLocation (that has the proper location intitialized from Load phase). Due to the need to keep the constructors contract (we override existing XmlElement), we cannot pass the additional info in the constructor.
Changes Made
Making the Location property of XmlElementWithLocation writable - so that it can be properly rewritten if constructed from an existing node with available location info.
Testing
Hand testing plus applying the changfe to the other PR: #8581, solved the issue with (0, 0) warnings location
Note
This or #8581 PR (whichever is merged later) should remove the workaround https://github.com/dotnet/msbuild/pull/8581/files#diff-e289ba4ce7fa0e72cf63049cce595eafcad1e7b2034ccb3305cd0f06c2f822b8R196-R197
This failed for me in an unrelated PR and on my dev box and at least on my dev box it was because sometimes my PowerShell profile took longer than 1 second to process.
Pass -NoProfile to avoid that time entirely when it's not necessary.
In addition, save the engine's log to the test log to give some clues if the test fails again.
Context
MSBuild had been added to the code validation pipeline but was missing the tsa config file. Per the instructions here and after talking to Matt, adding this file
Changes Made
Added a tsa config file by copying from SDK
Testing
Not sure how to test this. I pushed an internal build but the checks didn't run as I'm told they run nightly in a separate pipeline.
Notes
Validation pipeline: https://dev.azure.com/dnceng/internal/_build/results?buildId=2157183&view=results
Relates to https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1728887/
Context
ItemSpecFragment.MatchCount result is thrown away when called from ItemExpressionFragment.MatchCount (it just needs to get info about existing match).
The mentioned codepath is on the stack of the detected UI delay. While it might not be the rootcause, it doesn't hurt to improve this behavior.
Thanks @davkean for specific suggestions pointers during ivestigation
* Enable prebuilt detection
- Baseline a 7.0 dependencies until msbuild targets net8.0 and uses an 8.0 arcade and an arcade fix comes in
- Add SBRP dependencies (with subscription) and source build tags
System.Security.Principal.Windows is inbox since net6.0
System.Net.Http is inbox since netcoreapp2.0
System.Reflection.Metadata is inbox since netcoreapp2.0
System.Threading.Tasks.Dataflow is inbox since netcoreapp2.0
Remove System.Net.Http package references which aren't needed as they underlying assembly is inbox on both .NETFramework and .NETCoreApp.
By avoiding the dependencies, we minimize the dependency graph and with that the attack surface.
cc @MichaelSimons (removes netstandard1.x dependencies)
In #8608 I introduced a new string for this, but it's redundant with the one we already had that we only used to log to the console.
Dropping the "log directly to console" approach because we now (18 years later) have deferred messages, the engine API that someone didn't want to add.
In general we want to produce reference assemblies whenever possible, as they improve incremental build performance.
Making them work end-to-end requires support from other components, such as fast up-to-date checks in VS. While support was originally added for SDK-style projects, it was not present for legacy `.csproj` files. Accordingly, `ProduceReferenceAssemblies` was set `true` only when the target framework was `net5.0` or later for C#/VB projects. Similarly, F# added support during `net7.0`, so a similar check was added for F# projects.
VS 17.5 ships support for reference assemblies in the legacy CSPROJ fast up-to-date check, so all C#/VB projects are supported. Similarly, F# has full support. Consequently, it is now safe to enable the production and consumption of reference assemblies across all .NET project types, including .NET Framework, .NET Standard, .NET Core and .NET.
This commit changes the default `ProduceReferenceAssembly` value to `true` for all .NET projects that don't set `ProduceOnlyReferenceAssembly`.
The return value of `ITaskItem.CloneCustomMetadata` is an `IDictionary`,
which is generally (in modern MSBuild) backed by a
`Dictionary<string, string>`, but can be (when given an item from a
net35 taskhost) a `Hashtable`. In the latter situation, casting entries
to `KeyValuePair<,>` fails, because they conform only to
`DictionaryEntry`.
Use that less-well-typed approach--the casts were present in the pre-
bulk-edit version of the code. Fixes#8645.
This is more responsive and keeps the counter on screen
at all times at the cost of giving up any hope of understanding
what's going on within the restore.
I was noticing a bunch of nodes that seemed "stuck" on targets that shouldn't take a long time--turns out they were done with that + idle but never got marked as such so they kept counting up confusingly.
* add LeftShift, RightShift, RightShiftUnsigned intrinsic functions
* Add "fast path" for all bit operator functions; change unit test to use Shouldly because fail messages will show the name of the failing function
* Update to standardize on invoking IntrinsicFunctions methods, and add missing Modulo
* Add IntrinsicFunctions.Unescape
The -preprocess or -targets options are not supported for .sln files and, when these options are supplied, the .sln is built.
With this change the .sln will not be built.
Today the bootstrap doesn't have `NuGet.RestoreEx.targets` (or `NuGet.Build.Tasks.Console.exe` even), so it falls back to the "regular" restore. This change brings in those bits via the `NuGet.Build.Tasks.Console` package.
Rainer Sigwald
Thefrank
dotnet-maestro[bot]
github-actions[bot]
Roman Konecny
David Federman
Drew Noakes
Jan Krivanek
Forgind
Jared Parsons
Marc Paine
Matt Mitchell
Viktor Hofer
Dmitriy Shepelev
Jenny Bai
Ladi Prosek
dotnet bot
Jonathan Dodds
David Federman