Current 6.0 SDK building in VS errors with 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found. #17461

benaadams · 2021-05-05T23:36:02Z

In VS building a mostly empty web project fails with

1>------ Rebuild All started: Project: WebApplication1, Configuration: Release Any CPU ------
1>C:\Program Files\dotnet\sdk\6.0.100-preview.5.21255.14\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.props(14,3):
 error : C:\Program Files\dotnet\sdk\6.0.100-preview.5.21255.14\Sdks\Microsoft.NET.SDK.WorkloadAutoImportPropsLocator\Sdk not found.
 Check that a recent enough .NET SDK is installed and/or increase the version specified in global.json.

1>C:\Program Files\dotnet\sdk\6.0.100-preview.5.21255.14\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.props(14,38):
 error MSB4236: The SDK 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found.

1>Done building project "WebApplication1.csproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

At CLI it suceeds by has a different warning (which is #17388)

Microsoft (R) Build Engine version 16.11.0-preview-21254-21+e73d08c28 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored C:\Users\thund\source\repos\WebApplication1\WebApplication1\WebApplication1.csproj (in 62 ms).
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview

C:\Program Files\dotnet\sdk\6.0.100-preview.5.21255.14\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(255,5):
 warning NETSDK1048: 'AdditionalProbingPaths' were specified for GenerateRuntimeConfigurationFiles,
 but are being skipped because 'RuntimeConfigDevPath' is empty. 

[C:\Users\thund\source\repos\WebApplication1\WebApplication1\WebApplication1.csproj]
  WebApplication1 -> C:\Users\thund\source\repos\WebApplication1\WebApplication1\bin\Debug\net6.0\win-x64\WebApplication1.dll

Build succeeded.

The text was updated successfully, but these errors were encountered:

dotnet-issue-labeler · 2021-05-05T23:36:04Z

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

benaadams · 2021-05-05T23:58:06Z

Causes all VS builds to fail including net5.0 ones.

Adding global.json does allow them to build

{
    "sdk": {
        "version": "5.0.202",
        "rollForward": "latestFeature"
    }
}

davidfowl · 2021-05-09T18:42:28Z

I'm hitting this too. I reverted my upgrade because of this

dsplaisted · 2021-05-10T04:48:07Z

The .NET 6 SDK now enables workload resolvers by default. This means when using Full Framework MSBuild (which happens in Visual Studio or when you use msbuild instead of dotnet from the command line), you need the workload resolver enabled. This is enabled by default in VS 16.10 Preview 3. For previous versions of MSBuild, you can set the MSBuildEnableWorkloadResolver environment variable to true. However, this workaround is likely to stop working in Preview 4 or Preview 5 of .NET SDK 6.0.100, as there is a change to the workload manifest schema which will cause the previous version of the resolver to fail.

In short: Update to VS 16.10 Preview 3 or later if you can, and if you can't you can try setting the MSBuildEnableWorkloadResolver environment variable to true.

davidfowl · 2021-05-10T05:22:15Z

I tried updating both VS and the .NET SDK and ASP.NET Core basically disappeared. I can't seem to make a new project (or open an existing one).

davidfowl · 2021-05-10T05:23:03Z

Actually, I can't seem to create any projects...

davidfowl · 2021-05-10T05:57:06Z

Repaired VS, still doesn't work. I'm gonna declare that there's a bug here.

benaadams · 2021-05-10T11:30:35Z

Actually, I can't seem to create any projects...

I get this when doing new project in VS #17515 have to create a new one in cli

dsplaisted · 2021-05-10T18:49:38Z

Actually, a better workaround is probably to set MSBuildEnableWorkloadResolver to false. This should avoid the issue with the manifest schema change.

Of course, eventually after you are using an updated version of VS you'll want to unset the environment variable to allow workloads to work.

davidfowl · 2021-05-10T19:03:49Z

I'm using internal dogfood builds and its still broken in the ways expressed here.

akamud · 2021-05-29T22:59:49Z

I'm having this same issue on macOS, either on Rider or running dotnet build from the command line. .NET 6 was working a few days ago when I was using the nightly releases, stopped working when I installed Preview 4.

Tried the workaround, setting MSBuildEnableWorkloadResolver env variable to false seems to work. I was able to load and build the project now.

michaelherndon · 2021-05-31T04:56:50Z

This issue is definitely causing problems with omnisharp. No luck with the MSBuildEnableWorkloadResolver environment variable. Uninstalling the preview caused even more issues. I had to reinstall the preview and install the preview version of Visual Studio.

dotMorten · 2021-11-09T23:56:27Z

@danwalmsley Really? My case is better now.

apousada · 2021-11-15T17:55:57Z

Bumping... I see a similar exception in the log produced under %TEMP%\servicehub\logs\ when trying to start Live Unit Testing:

Error : 10 :Exception thrown from request "4" for method LoadProjectAsync: System.AggregateException: One or more errors occurred. ---> Microsoft.Build.Exceptions.InvalidProjectFileException: The SDK 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found.  C:\Program Files\dotnet\sdk\6.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.props

Setting the MSBuildEnableWorkloadResolver environment variable to false seems to get me by for now.

marcpopMSFT · 2021-11-17T18:30:53Z

@sfoslund to look into the LUT report above.

sfoslund · 2021-11-17T21:56:42Z

@apousada can you give a full repro of this issue?

cc @dsplaisted in case you've seen this issue before or have any ideas.

goaaats · 2021-11-18T13:59:04Z

This happens to us using the windows-2022 GitHub Actions image. Setting MSBuildEnableWorkloadResolver to true doesn't seem to fix it.

https://github.com/actions/virtual-environments/blob/main/images/win/Windows2022-Readme.md#net-core-sdk
https://github.com/goatcorp/Dalamud/runs/4252003866?check_suite_focus=true#step:5:19

hellfirehd · 2021-11-22T01:06:37Z

This is still happening for me as well.

Windows 11 Pro Workstation clean install (not upgrade)
VS 2022 clean install, no VS 2019
Nuke 5.3.0
<Project Sdk="Microsoft.NET.Sdk">
<TargetFrameworks>net6.0</TargetFrameworks>
Don't know what MSBuildEnableWorkloadResolver is so I assume it's not set.

❯ nuke
PowerShell Desktop version 5.1.22000.282
Microsoft (R) .NET Core SDK version 6.0.100
Creating directory 'C:\Source\Redacted.EntityFrameworkCore\.nuke\temp'...

███╗   ██╗██╗   ██╗██╗  ██╗███████╗
████╗  ██║██║   ██║██║ ██╔╝██╔════╝
██╔██╗ ██║██║   ██║█████╔╝ █████╗
██║╚██╗██║██║   ██║██╔═██╗ ██╔══╝
██║ ╚████║╚██████╔╝██║  ██╗███████╗
╚═╝  ╚═══╝ ╚═════╝ ╚═╝  ╚═╝╚══════╝

NUKE Execution Engine version 5.3.0 (Windows,.NETCoreApp,Version=v5.0)

The SDK 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found.  C:\Program Files\dotnet\sdk\6.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.props
StackTrace:
   at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
   at Microsoft.Build.Evaluation.Evaluator`4.ExpandAndLoadImportsFromUnescapedImportExpressionConditioned(String directoryOfImportingFile, ProjectImportElement importElement, List`1& projects, SdkResult& sdkResult, Boolean throwOnFileNotExistsError)
   at Microsoft.Build.Evaluation.Evaluator`4.ExpandAndLoadImports(String directoryOfImportingFile, ProjectImportElement importElement, SdkResult& sdkResult)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.Evaluate()
   at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IEvaluatorData`4 data, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean interactive)
   at Microsoft.Build.Evaluation.Project.ProjectImpl.Reevaluate(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.ProjectImpl.Initialize(IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project..ctor(ProjectRootElement xml, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.FromProjectRootElement(ProjectRootElement rootElement, ProjectOptions options)
   at Nuke.Common.ProjectModel.ProjectModelTasks.ParseProject(String projectFile, String configuration, String targetFramework)
   at Nuke.Common.Execution.Telemetry.CheckAwareness()

vova-lantsov-dev · 2021-11-22T07:29:44Z

@hellfirehd please read #22221 (or better visit official Nuke community in Slack to get support there)

apousada · 2021-11-23T13:23:20Z

@apousada can you give a full repro of this issue?

cc @dsplaisted in case you've seen this issue before or have any ideas.

Sorry for the delay, @sfoslund ! Yes, a barebones solution that reproduces the issue for me is attached. The steps are simply to open Visual Studio 2022, load the solution and try starting Live Unit Testing when the MSBuildEnableWorkloadResolver environment variable is either not set or is set to true. Close Visual Studio 2022, set the environment variable to false, and then re-open VS and the solution, start unit testing, and then it works for me.

LutWorkloadResolverIssue.zip

AeroBliss · 2021-12-05T19:25:00Z

I am also having this issue. Attempting to run my project (https://github.com/ppy/osu) in monodevelop gives me:
/usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.ImportWorkloads.props(38,38): Error MSB4236: The SDK 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found. (MSB4236) (osu.Game)
But if I run it in CLI (dotnet run --project osu.Desktop) it runs just fine. I am not sure if this is an issue relating to dotnet or monodevelop, but I read here that this is apparently an issue with dotnet, so I figured putting it here.

AraHaan · 2021-12-05T20:03:45Z

That is because monodevelop is not supported anymore I think at all.

kwaazaar · 2022-03-24T12:21:18Z

I created a .NET 4 webapplication project and migrated it to the SDK-style projectfile format (using this project). To build it I need to use msbuild (as both dotnet build and dotnet msbuild don't work. Msbuild is installed on our custom agents, but does not contain the .NET Core Build Tools workload, as this no longer exists since VS2022. By specifying MSBuildSDKsPath I can make it find the SDKs and I need to set MSBuildEnableWorkloadResolver to false to prevent this error.

baskren · 2022-05-24T17:55:30Z

I would like to ask for this issue to be reopened. Upon install of VS2022 (v17.0 - build8989) on x64 Mac, I get this error. Do not get this error when building from command line.

Have 3x deleted every trace of Mono, Xamarin, NuGet, DotNet, and VisualStudio from my system and reinstalled VS2022 to the same result.

Setting the MSBuildEnableWorkloadResolver environment variable does not help.

baskren · 2022-05-25T13:56:02Z

CORECTION

I am finally able to get VS2022 for Mac (v17.0 - build 8989) working by setting the MSBuildEnableWorkloadResolver = false environment variable.

For those who have the same issue: Note that the most systemic way to set environment variables in MacOS is through launchctl:

 % launchctl setenv MSBuildEnableWorkloadResolver false

The old approach of systemically setting environmental variables was via ~/.MacOSX/environment.plist . However, that approach was removed in OS X Lion.

If you turn on Diagnostic log verbosity, the first thing listed in the build log will be the environment variables used for the build. Setting environment variables in the traditional Unix way (.profile, .bash_profile, .zprofile, .zshenv, etc) will not work for applications.

TO THE MAINTAINERS

I still ask that you consider reopening this issue. Several times it is stated that setting the MSBuildEnableWorkloadResolver environment variable is not necessary with more recent releases of VS2022. My experience has proven that this is not universally true.

marcpopMSFT · 2022-05-26T20:15:15Z

@mrward the latest customer reply above is specific to VSMac 17.0. Have you seen this behavior in your own testing of VSMac 17? Since you manage how the SDK gets inserted and configured into VSMac, I wonder if there is an issue with that specific scenario.

mrward · 2022-05-26T21:29:38Z

@marcpopMSFT There is this feedback ticket - https://developercommunity.visualstudio.com/t/Unable-to-find-SDK-’MicrosoftNETSDKWo/10053602 - which has the same error, and needs further investigation.

With this feedback ticket the problem seems to be that one of the project's in the solution is a non-sdk project (or one that targets .NET Framework v4) which causes VS Mac 17.0 to use MSBuild on mono for the solution, and .NET 6.0.300 SDK was the only SDK installed, which is not supported by MSBuild on mono. VS Mac downgrades the .NET SDK to allow MSBuild on mono to work, and then that means there is no SDK available which I suspect then causes the workload resolver to fail. This particular problem is specific to VS Mac and is not a dotnet sdk or runtime issue. dotnet restore/build would not be affected by this.

Possible workarounds that may fix this are to install .NET 6.0.10x SDK, or to uncheck the Solution options - Build - General - Build with MSBuild on Mono check box.

baskren · 2022-05-26T22:21:53Z

@mrward : FWIW:

Among the things I tried were manually installing .NET 6.0.100 and .NET 6.0.300 SDKs.
My solution(s) are all UNO platform libraries and platform projects. As such, they only target one of the following:
- platform specific (for the platform executable projects)
- .NetStandard 2.0
- or the following:

    <TargetFrameworks>uap10.0.18362;netstandard2.0;Xamarin.iOS10;Xamarin.Mac20;MonoAndroid11.0;</TargetFrameworks>
    <TargetFrameworks Condition=" $(SolutionName.Contains('.vsmac')) ">netstandard2.0;Xamarin.iOS10;Xamarin.Mac20;MonoAndroid11.0;</TargetFrameworks>
    <TargetFrameworks Condition=" $(SolutionName.Contains('.Droid')) ">MonoAndroid11.0</TargetFrameworks>
    <TargetFrameworks Condition=" $(SolutionName.Contains('.iOS')) ">Xamarin.iOS10</TargetFrameworks>
    <TargetFrameworks Condition=" $(SolutionName.Contains('.macOS')) ">Xamarin.Mac20</TargetFrameworks>
    <TargetFrameworks Condition=" $(SolutionName.Contains('.GtK')) ">netstandard2.0</TargetFrameworks>
    <TargetFrameworks Condition=" $(SolutionName.Contains('.Tizen')) ">Tizen50</TargetFrameworks>
    <TargetFrameworks Condition=" $(SolutionName.Contains('.WPF')) ">netstandard2.0</TargetFrameworks>
    <TargetFrameworks Condition=" $(SolutionName.Contains('.UWP')) ">uap10.0.18362</TargetFrameworks>
    <TargetFrameworks Condition=" $(SolutionName.Contains('.Wasm')) ">netstandard2.0</TargetFrameworks>

I use the above conditionals (and, as needed, corresponding solution files) to reduce build times when doing application debugging.

praeclarum · 2022-06-01T20:17:23Z

I am running into this with my VS for Mac 2019 and 2022 projects. It seems including a .NET 6 project into a solution breaks resolution. Hoping for a fix as this affects all my projects.

@mrward uncheck the Solution options - Build - General - Build with MSBuild on Mono check box.

That worked for at least one of my projects. Thank you.

tompi · 2022-06-09T08:31:02Z

Thank you @baskren !

'''
launchctl setenv MSBuildEnableWorkloadResolver false
'''

finally brought back my rider ide

jwoeste · 2022-10-06T11:10:35Z

Just had this issue on VS 17.3.6 (build 20) on macOS Monterey 12.6

Wasted days before finding this "launchctl setenv MSBuildEnableWorkloadResolver false"

The issue started after installing latest Xamarin.iOS.

Seems like a lot of regression testing is left with the community.

trampster · 2022-10-30T21:39:24Z

I just had this issue with Visual Studio for Mac 17.3.8 (build 5). This issue is clearly not fixed and should be reopened.

emmanuelpare · 2022-11-08T20:34:21Z

I got this issue for the first time today with the latest Macos version 17.5

Workaround is to executer:
launchctl setenv MSBuildEnableWorkloadResolver false

Release ID: 1705000437
Git revision: a5d0fb913c1ff781c80fe725a3e0511c34e26a08
Build date: 2022-11-02 21:34:22+00
Build branch: release-17.5

INFO [2022-11-08 15:30:51Z]: Running on .NET 7.0.0 (64-bit)
INFO [2022-11-08 15:30:51Z]: Operating System: Mac OS X 13.0.0
Darwin 22.1.0 Darwin Kernel Version 22.1.0
Sun Oct 9 20:15:09 PDT 2022
root:xnu-8792.41.9~2/RELEASE_ARM64_T6000 arm64

JonBushby77 · 2022-11-08T23:01:48Z

Got this issue today after updating to VS Mac 17.5. I need to set the environment variable every time i reboot.

zbecknell · 2022-11-09T00:44:41Z

Just adding to the anecdotes -- I also encountered the issue and had to set the environment variable.

dimdrandakis · 2022-11-09T08:43:02Z

Same here VS Mac 17.5 Preview (17.5 build 437)

mrward · 2022-11-10T09:39:42Z

The 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' not being found error can happen in VS Mac for different reasons. There is a recent feedback ticket where if there were old pre-release versions of .NET 7 installed then this could also happen:

https://developercommunity.visualstudio.com/t/After-updating-to-net-7-Visual-Studio-/10194756

The underlying bug, old workload was renamed in later .NET 7 SDK, was also reported for Windows - #28947

The workaround there is to remove .NET completely and install it again. The developer community ticket gives information on how to do that.

If that does not solve the problem, then we would need the IDE log. Since the IDE log may contain personal data it would better if this was reported on Developer Community or via Report a Problem from with VS Mac itself. Thanks.

dotnet-issue-labeler bot added the untriaged Request triage from a team member label May 5, 2021

riverar mentioned this issue May 7, 2021

Sdks\Microsoft.NET.SDK.WorkloadAutoImportPropsLocator\Sdk not found dotnet/installer#10551

Closed

This was referenced May 9, 2021

Optimise GetCustomAttribute(s) dotnet/runtime#45121

Closed

Improve IndexOfAny(byte,byte,byte) dotnet/runtime#40894

Merged

Drop unnecessary fields from SocketAsyncEventArgs dotnet/runtime#51078

Closed

marcpopMSFT assigned sfoslund May 11, 2021

MihaZupan mentioned this issue May 13, 2021

Add net6.0 targets microsoft/reverse-proxy#972

Merged

sfoslund removed the untriaged Request triage from a team member label May 13, 2021

sfoslund removed their assignment May 13, 2021

sfoslund added the Area-NetSDK label May 13, 2021

sfoslund added this to the 6.0.1xx milestone May 13, 2021

sfoslund added the Area-Workloads label May 13, 2021

This was referenced May 14, 2021

Bump SDK and disable RSG for BasicTestApp dotnet/aspnetcore#32581

Merged

Resolve issues with dotnet-openapi tests in latest SDK dotnet/aspnetcore#32686

Closed

debonte added a commit to NuGet/NuGet.Client that referenced this issue May 21, 2021

Set MSBuildEnableWorkloadResolver to work around dotnet/sdk#17461

eaac4f2

janusw mentioned this issue Jun 14, 2022

Cannot build with VS4Mac: nuget issue Mapsui/Mapsui#1641

Closed

pracplayopen mentioned this issue Aug 16, 2022

dotnetcore / netstandard projects not working if .net 5.0 (dotnet 5) is installed dotdevelop/dotdevelop#40

Closed

ProActive-Engineer pushed a commit to ProActive-Engineer/StronglyID that referenced this issue Aug 19, 2023

Add workaround for dotnet/sdk#17461

e9fc171

ProActive-Engineer added a commit to ProActive-Engineer/StronglyID that referenced this issue Aug 19, 2023

Add workaround for dotnet/sdk#17461

58d46ac

YuliiaKovalova mentioned this issue Aug 30, 2023

Bootstrapped Framework MSBuild can't build .NET SDK projects when built from .NET Core dotnet/msbuild#6947

Closed

Current 6.0 SDK building in VS errors with 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found. #17461

Current 6.0 SDK building in VS errors with 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found. #17461

Comments

benaadams commented May 5, 2021 • edited Loading

dotnet-issue-labeler bot commented May 5, 2021

benaadams commented May 5, 2021

davidfowl commented May 9, 2021

dsplaisted commented May 10, 2021

davidfowl commented May 10, 2021

davidfowl commented May 10, 2021

davidfowl commented May 10, 2021

benaadams commented May 10, 2021

dsplaisted commented May 10, 2021

davidfowl commented May 10, 2021

akamud commented May 29, 2021 • edited Loading

michaelherndon commented May 31, 2021

dotMorten commented Nov 9, 2021 • edited Loading

apousada commented Nov 15, 2021

marcpopMSFT commented Nov 17, 2021

sfoslund commented Nov 17, 2021

goaaats commented Nov 18, 2021

hellfirehd commented Nov 22, 2021

vova-lantsov-dev commented Nov 22, 2021

apousada commented Nov 23, 2021 • edited Loading

AeroBliss commented Dec 5, 2021

AraHaan commented Dec 5, 2021

kwaazaar commented Mar 24, 2022

baskren commented May 24, 2022

baskren commented May 25, 2022

CORECTION

TO THE MAINTAINERS

marcpopMSFT commented May 26, 2022

mrward commented May 26, 2022

baskren commented May 26, 2022

praeclarum commented Jun 1, 2022 • edited Loading

tompi commented Jun 9, 2022

jwoeste commented Oct 6, 2022

trampster commented Oct 30, 2022

emmanuelpare commented Nov 8, 2022

JonBushby77 commented Nov 8, 2022

zbecknell commented Nov 9, 2022

dimdrandakis commented Nov 9, 2022

mrward commented Nov 10, 2022

benaadams commented May 5, 2021 •

edited

Loading

akamud commented May 29, 2021 •

edited

Loading

dotMorten commented Nov 9, 2021 •

edited

Loading

apousada commented Nov 23, 2021 •

edited

Loading

praeclarum commented Jun 1, 2022 •

edited

Loading