profile
viewpoint
Ladi Prosek ladipro @Microsoft Brno, Czech Republic Twiddling bits for a living.

ladipro/avisynth_filters 5

Filters for the AviSynth video processing tool

ladipro/rio500 2

Windows software supporting the Diamond Rio 500 MP3 player

bekir-ozturk/insertions-client 1

Tool that inserts .NET Core SDK into VS

ladipro/aspnetcore-tooling 0

Tools for ASP.NET Core apps, such as MSBuild targets, Visual Studio extensions, and command line tools. (Open issues on https://github.com/dotnet/aspnetcore/issues)

ladipro/ipxe-virtio 0

iPXE network bootloader.

ladipro/kvm-guest-drivers-windows 0

Windows paravirtualized

ladipro/linux 0

Linux kernel source tree

ladipro/MessagePack-CSharp 0

Extremely Fast MessagePack Serializer for C#(.NET, .NET Core, Unity, Xamarin). / msgpack.org[C#]

ladipro/msbuild 0

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.

ladipro/MSBuildLocator 0

An API to locate MSBuild assemblies from an installed Visual Studio location. Use this to ensure that calling the MSBuild API will use the same toolset that a build from Visual Studio or msbuild.exe would.

PullRequestReviewEvent

Pull request review commentdotnet/msbuild

Avoid temporary list allocations and specify list capacities in TaskItem

 public bool Equals(TaskItem other)                     return true;                 } -                // Since both sides are this class, we know both sides support ITaskItem2.-                ITaskItem2 thisAsITaskItem2 = this as ITaskItem2;-                ITaskItem2 otherAsITaskItem2 = other as ITaskItem2;+                ITaskItem2 thisAsITaskItem2 = this;+                ITaskItem2 otherAsITaskItem2 = other;                  // This is case-insensitive. See GetHashCode().                 if (!MSBuildNameIgnoreCaseComparer.Default.Equals(thisAsITaskItem2.EvaluatedIncludeEscaped, otherAsITaskItem2.EvaluatedIncludeEscaped))                 {                     return false;                 } -                if (this.CustomMetadataCount != other.CustomMetadataCount)+                var thisNames = new HashSet<string>(MSBuildNameIgnoreCaseComparer.Default);++                if (_itemDefinitions is not null)                 {-                    return false;+                    foreach (ProjectItemDefinitionInstance itemDefinition in _itemDefinitions)+                    {+                        thisNames.UnionWith(itemDefinition.MetadataNames);+                    }+                }++                if (_directMetadata is not null)+                {+                    foreach (ProjectMetadataInstance metadatum in _directMetadata)+                    {+                        thisNames.Add(metadatum.Name);+                    }                 } -                foreach (string name in this.CustomMetadataNames)+                foreach (ProjectMetadataInstance metadatum in other.MetadataCollection)

Would it help to return false here before the loop if the sizes of thisNames and other.MetadataCollection don't match?

drewnoakes

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventladipro/msbuild

Ladi Prosek

commit sha 7722dcad87ebcfa66bde7ae1ed37bbf687b52166

Fix CopyOnReadEnumerable_Tests

view details

Ladi Prosek

commit sha 87b715cc3160ac41f5111140c2d875434cb501a8

Keep original null behavior in ProjectStartedEventArgs

view details

push time in 3 days

PR opened dotnet/msbuild

Eliminate IDeepCloneable<T>

Fixes #6176

TBD

Context

Changes Made

Testing

Notes

+33 -234

0 comment

10 changed files

pr created time in 3 days

create barnchladipro/msbuild

branch : 6176-optimize-corenumerable

created branch time in 3 days

PullRequestReviewEvent

create barnchdotnet/msbuild

branch : exp/multi-threaded-msbuild

created branch time in 6 days

push eventladipro/msbuild

Ladi Prosek

commit sha e0161b4c9419bf988687fcf1fd45d50b6fd9fa8b

Race in TaskExecutionHost and start fixing tasks

view details

push time in 6 days

Pull request review commentdotnet/msbuild

Avoid temporary list allocations and specify list capacities in TaskItem

 public ICollection CustomMetadataNames             /// <summary>             /// Gets the number of custom metadata set on the item.             /// Does not include built-in metadata.-            /// Computed, not necessarily fast.+            /// This is the count of <see cref="MetadataCollection"/>.             /// </summary>             public int CustomMetadataCount             {-                get { return CustomMetadataNames.Count; }+                get+                {+                    int count = 0;++                    // NOTE we walk collections here and exclude null values from counts to maintain parity+                    // with the implementation of CustomMetadata.++                    if (_itemDefinitions is not null)+                    {+                        foreach (ProjectItemDefinitionInstance item in _itemDefinitions)+                        {+                            if (item.Metadata is not null)

That's an awesome observation! I'll also note that grepping for CustomMetadataCount yields no hits in any relevant .NET or VS related repo and there's only one internal use in TaskItem.Equals. So one possible way of addressing may be leaving CustomMetadataCount as is and coming up with a better implementation of Equals.

drewnoakes

comment created time in 7 days

PullRequestReviewEvent

push eventladipro/msbuild

Ladi Prosek

commit sha feeddc5935af8e3ba85750a7daf13bde2831bdb5

Fix races and bugs

view details

push time in 7 days

create barnchladipro/msbuild

branch : multi-threaded-msbuild

created branch time in 9 days

pull request commentdotnet/msbuild

Remove locking and indirection from CopyOnWritePropertyDictionary

Thank you! Would you mind switching the new unit tests to use Shouldly for assertions? It's preferred for new tests.

drewnoakes

comment created time in 10 days

delete branch ladipro/msbuild

delete branch : fix-github-urls

delete time in 10 days

push eventdotnet/msbuild

Ladi Prosek

commit sha a59d7a533c9154e8aa99b823625e7eff199ddf1a

Fix github URLs microsoft/msbuild -> dotnet/msbuild (#7083) ### Context As @Forgind and @drewnoakes pointed out, we still have links to [github.com/microsoft/msbuild](https://github.com/microsoft/msbuild) in the tree. ### Changes Made Replaced [github.com/microsoft/msbuild](https://github.com/microsoft/msbuild) with [github.com/dotnet/msbuild](https://github.com/dotnet/msbuild). Except for the two occurrences fixed in #7055. ### Testing Build, CI

view details

push time in 10 days

PR merged dotnet/msbuild

Fix github URLs microsoft/msbuild -> dotnet/msbuild merge-when-branch-open

Context

As @Forgind and @drewnoakes pointed out, we still have links to github.com/microsoft/msbuild in the tree.

Changes Made

Replaced github.com/microsoft/msbuild with github.com/dotnet/msbuild.

Except for the two occurrences fixed in #7055.

Testing

Build, CI

+293 -293

0 comment

88 changed files

ladipro

pr closed time in 10 days

push eventdotnet/msbuild

Drew Noakes

commit sha d7f71a3828084f6bcac3cbf10397d0d15667a320

Remove unused 'capacity' parameter for COW dictionaries (#7080) ### Context The underlying immutable dictionaries are implemented as trees and as such the concept of 'capacity' does not apply. Removing these parameters and their arguments from call sites can avoid some redundant work. ### Changes Made - Remove `capacity` parameters from constructors. - Resolve conflicts between then-identical constructors. - Update call sites. ### Testing Unit tests.

view details

push time in 10 days

PR merged dotnet/msbuild

Remove unused 'capacity' parameter for COW dictionaries merge-when-branch-open

Context

The underlying immutable dictionaries are implemented as trees and as such the concept of 'capacity' does not apply.

Removing these parameters and their arguments from call sites can avoid some redundant work.

Changes Made

  • Remove capacity parameters from constructors.
  • Resolve conflicts between then-identical constructors.
  • Update call sites.

Testing

Unit tests.

+13 -39

1 comment

7 changed files

drewnoakes

pr closed time in 10 days

push eventdotnet/msbuild

MichalPavlik

commit sha 2e437e9251488620d5ea8d9b316d1a7f66d6114c

Evaluator allocation optimization (#7056) Fixes #6307 ### Context Evaluator sometimes allocates `List<ProjectRootElement>` instances when it's not necessary. ### Changes Made Collection allocation is postponed and null is used to represent empty result. ### Testing I tracked `List<ProjectRootElement>` allocations while building simple solution with two empty C# projects (.NET Framework and Core). Number of allocated instances dropped from 264 to 178.

view details

push time in 10 days

PR merged dotnet/msbuild

Evaluator allocation optimization performance merge-when-branch-open

Fixes #6307

Context

Evaluator sometimes allocates List<ProjectRootElement> instances when it's not necessary.

Changes Made

Collection allocation is postponed and empty Enumerable singleton is used to represent empty result. @drewnoakes I tried to use ImmutableArray, but it produced more allocations - builder is copying underlying array when creating instance of the immutable collection.

Testing

I tracked List<ProjectRootElement> allocations while building simple solution with two empty C# projects (.NET Framework and Core). Number of allocated instances dropped from 264 to 178.

Notes

This optimization looked like good first issue to solve, but complexity of the Evaluator is IMHO high and using out parameters for these collections makes it more difficult to track their flow :)

+37 -18

7 comments

1 changed file

MichalPavlik

pr closed time in 10 days

issue closeddotnet/msbuild

Reduce List<ProjectRootElement> allocations in Evaluator.cs

Evaluator.cs is too liberal allocating List<ProjectRootElement> unnecessarily

closed time in 10 days

KirillOsenkov

push eventdotnet/msbuild

Ben Villalobos

commit sha 5492fe86a6aaeff8d3bc80f549c671b26392def4

Al.exe finds the correct tool based on platform (#7051) Finally puts https://github.com/dotnet/msbuild/issues/5981 to bed. (to trigger an auto-close: fixes https://github.com/dotnet/msbuild/issues/5981) ### Context The underlying problem with the Al issues is that **the Al task finds its own tool based on the current process' architecture**. This means: x86 msbuild.exe -> x86 Al.exe x64 msbuild.exe -> x64 Al.exe Now, if your x86 msbuild.exe is building with `Platform=x64`, the x86 Al.exe gets passed `platform:x64` and logs its own warning because of mismatched platforms. So we fixed that by checking if the platform was x64, then look in the x64 tools directory in common.targets. Now we're hitting problems where the x64 msbuild.exe is calling the x64 Al.exe and being passed `platform:x86`, causing the reverse of the original issue! ### Changes Made The Al task checks the platform that was passed. If it's x86, it will find the 32 bit al.exe. If x64, it will append x64 to the path before finding the tool. This also reverts appending x64 to the tools directory in common.currentversion.targets before calling the Al task. It shouldn't have worked in today's x64 msbuild.exe, but does because of the x86 fallback behavior. Apending x64 before the task is called is no longer required. ### Testing ### Notes I allowed `_ALExeToolPath` to be overridden to account for projects that may be using it today with older msbuild binaries. **A mismatched common.currentversion.targets & microsoft.build.dll can fail**. Old targets & new dll: if platform is x64 it will double append x64, but the fallback will find the x64 al.exe. no fix required. if platform is x86 and x64 is appended to the path: will likely find the x64 tool and log the error. fix: customer should no longer append x64 to the path. new targets & old dll: for platform=x64, `x64` needs to be manually appended. The "source of truth" is setting `AlToolPath` to end in `x64`. for platform=x86, no fix needed.

view details

push time in 11 days

PR merged dotnet/msbuild

Al.exe finds the correct tool based on platform merge-when-branch-open review-by-commit

Finally puts https://github.com/dotnet/msbuild/issues/5981 to bed. (to trigger an auto-close: fixes https://github.com/dotnet/msbuild/issues/5981)

Context

The underlying problem with the Al issues is that the Al task finds its own tool based on the current process' architecture. This means:

x86 msbuild.exe -> x86 Al.exe x64 msbuild.exe -> x64 Al.exe

Now, if your x86 msbuild.exe is building with Platform=x64, the x86 Al.exe gets passed platform:x64 and logs its own warning because of mismatched platforms.

So we fixed that by checking if the platform was x64, then look in the x64 tools directory in common.targets.

Now we're hitting problems where the x64 msbuild.exe is calling the x64 Al.exe and being passed platform:x86, causing the reverse of the original issue!

Changes Made

The Al task checks the platform that was passed. If it's x86, it will find the 32 bit al.exe. If x64, it will append x64 to the path before finding the tool.

This also reverts appending x64 to the tools directory in common.currentversion.targets before calling the Al task. It shouldn't have worked in today's x64 msbuild.exe, but does because of the x86 fallback behavior. Apending x64 before the task is called is no longer required.

Testing

Notes

I allowed _ALExeToolPath to be overridden to account for projects that may be using it today with older msbuild binaries.

A mismatched common.currentversion.targets & microsoft.build.dll can fail.

Old targets & new dll: if platform is x64 it will double append x64, but the fallback will find the x64 al.exe. no fix required. if platform is x86 and x64 is appended to the path: will likely find the x64 tool and log the error. fix: customer should no longer append x64 to the path. new targets & old dll: for platform=x64, x64 needs to be manually appended. The "source of truth" is setting AlToolPath to end in x64. for platform=x86, no fix needed.

+9 -5

0 comment

3 changed files

BenVillalobos

pr closed time in 11 days

issue closeddotnet/msbuild

Warning AL1073 when .resx files is compiled under x64

Issue Description

msbuild reports a "Warning AL1073 Referenced assembly 'mscorlib.dll' targets a different processor" when you try to compile .resx files under x64.

Steps to Reproduce

Simply try to compile .resx file under x64 platform.

Expected Behavior

No warning.

Actual Behavior

Warning AL1073.

Analysis

msbuild seems to always call x86 al.exe even when the platform is x64. The issue is described at this post.

The workaround is to manually add the following code in your project file:

  <Target Name="FixAL1703Warning" BeforeTargets="GenerateSatelliteAssemblies" Condition="'$(PlatformTarget)' == 'x64'">
    <Message Text="Adjusting SDK tools directory to use x64 version of AL.EXE" />
    <PropertyGroup>
      <TargetFrameworkSDKToolsDirectory>$(TargetFrameworkSDKToolsDirectory)$(PlatformTarget)\</TargetFrameworkSDKToolsDirectory>
    </PropertyGroup>
  </Target>

Versions & Configurations

Visual Studio 2019 v16.8.3 WPF .NET 5.0 project

closed time in 11 days

CyberSinh

issue commentdotnet/msbuild

Epic: Make up-to-date checks faster

All issues are closed, we're done with the epic.

ladipro

comment created time in 11 days

issue closeddotnet/msbuild

Epic: Make up-to-date checks faster

This tracks epic-level work to make up-to-date checks in MSBuild smarter and faster. It has been demonstrated that optimizing file timestamp checks positively impacts user experience when building larger solutions.

Up-to-date checks are critical primarily for incremental build although some of the items below may make evaluation faster as well.

  • [x] Create a design capturing high-level approaches to the problem
  • [x] #5972
  • [x] #6727
  • [x] #6844
  • [x] #3586
  • [x] #6761
  • [x] #7011

closed time in 11 days

ladipro

push eventdotnet/msbuild

Roman Konecny

commit sha ba28ab4a861446addec770508681a8e592d1727a

Optimized immutable files up to date checks (#6974) Fixes #6761 ### Context Files from 'program files' and NuGet caches as considered immutable so we can optimize their up to date checks by caching their last known timestamp. ### Changes Made Changes made in `NativeMethodShare.LastWriteFileUtcTime`. Caching Last Write File Times into static cache without eviction. By our test on `Orchard Core` there were only about 400 files in that cache - in the end. ### Testing Debugging, unit tests, compile Orchard Core m:1 and m:8 ### Notes Results into 10x faster cumulative time of `NativeMethodShare.LastWriteFileUtcTime` during Orchard Core incremental build. ![image](https://user-images.githubusercontent.com/25249058/138052217-28efeb0f-ef07-4811-97bf-c109c525dca9.png) There are two main most perf demanding use cases: a) TargetUpToDateChecker ![image](https://user-images.githubusercontent.com/25249058/138150020-fbf34292-2feb-44c7-8f4f-9ca43c7405af.png) ![image](https://user-images.githubusercontent.com/25249058/138150067-fe1c63b2-698f-49e7-82b5-831aec1b8e1c.png) b) Check validity of the RAR cache ![image](https://user-images.githubusercontent.com/25249058/138153686-d0cad9d2-cfc4-4b99-bb8f-943f0f3060b7.png) ![image](https://user-images.githubusercontent.com/25249058/138153729-e3f9d269-1026-4897-acda-165b392451bc.png) However, when I measured wall clock time of build, the actual savings was small. ~2% of overall build time in incremental build and ~1% in rebuild. Co-authored-by: MichalPavlik <michalpavlik@outlook.com> Co-authored-by: Forgind <Forgind@users.noreply.github.com> Co-authored-by: Rainer Sigwald <raines@microsoft.com>

view details

push time in 11 days

PR merged dotnet/msbuild

Optimized immutable files up to date checks merge-when-branch-open

Fixes #6761

Context

Files from 'program files' and NuGet caches as considered immutable so we can optimize their up to date checks by caching their last known timestamp.

Changes Made

Changes made in NativeMethodShare.LastWriteFileUtcTime. Caching Last Write File Times into static cache without eviction. By our test on Orchard Core there were only about 400 files in that cache - in the end.

Testing

Debugging, unit tests, compile Orchard Core m:1 and m:8

Notes

Results into 10x faster cumulative time of NativeMethodShare.LastWriteFileUtcTime during Orchard Core incremental build. image

There are two main most perf demanding use cases:

a) TargetUpToDateChecker image image

b) Check validity of the RAR cache image image

However, when I measured wall clock time of build, the actual savings was small. ~2% of overall build time in incremental build and ~1% in rebuild.

+423 -19

2 comments

7 changed files

rokonec

pr closed time in 11 days

more