Toolset configuration net5.0 #6220

minglunli · 2021-03-03T21:24:33Z

Context

This change will give NET5.0 MSBuild the option to read toolset information from the configuration file ONLY if ToolsetDefinitionLocation is set to 'ConfigurationFile'. Otherwise everything should work the exact same way as before.

This change is beneficial as it allows net5.0 MSBuild to evaluate projects that only net framework MsBuild could before. Since ConfigurationFile wasn't an option in net5.0 before (Due to System.Configuration being only net472), toolsets available to net5.0 MsBuild was minimal, but with this change a net5.0 MsBuild user could specify ConfigurationFile as the ToolsetDefinitionLocation when creating a ProjectCollection and more toolsets would be available depending on the MsBuild.exe provided.

Changes Made

Updated all the System.Configuration references to System.Configuration.ConfigurationManager (Which supports netstandard2.0). This change allows net5.0 to read toolset information from configuration file, but the default remains the same.

Testing

Tested locally to make sure the toolset information remains the same for cases other than when ToolsetDefinitionLocation is set to ConfigurationFile. CI should be good enough to ensure everything else still works as before.

Existing unit tests should be good enough to verify that this change does not affect net472 at all. Freed up a lot of unit tests under FEATURE_SYSTEM_CONFIGURATION which can be used to validate that net5.0 behavior without configuration setting works the same as before. Also added in a couple more tests to ensure setting ToolsetDefinitionLocation to ConfigurationFile actually grabs more configurations comparing to default.

…ld into toolsetConfigurationNet5

dnfadmin · 2021-03-03T21:24:55Z

All CLA requirements met.

cdmihai · 2021-03-04T02:39:48Z

Should this test class get added all the time now?

msbuild/src/Build.UnitTests/Microsoft.Build.Engine.UnitTests.csproj

Line 57 in 4144194

    
           <Compile Include="Definition\ToolsetConfigurationReaderTestHelper.cs" Condition="'$(TargetFrameworkIdentifier)' == '.NETFramework'" />

minglunli · 2021-03-04T18:12:43Z

Should this test class get added all the time now?

msbuild/src/Build.UnitTests/Microsoft.Build.Engine.UnitTests.csproj

Line 57 in 4144194

<Compile Include="Definition\ToolsetConfigurationReaderTestHelper.cs" Condition="'$(TargetFrameworkIdentifier)' == '.NETFramework'" />

Yes I think it's fine to add it all the time now. I removed the FEATURE_CONFIGURATION_FILE flags for ToolsetConfigurationReader_Tests and ImportFromExtensionPath_Tests and they both require this file and they both seemed to pass. I believe those are the only 2 occurrences when the file is being used.

minglunli · 2021-03-04T19:01:24Z

Should this test class get added all the time now?

msbuild/src/Build.UnitTests/Microsoft.Build.Engine.UnitTests.csproj

Line 57 in 4144194

<Compile Include="Definition\ToolsetConfigurationReaderTestHelper.cs" Condition="'$(TargetFrameworkIdentifier)' == '.NETFramework'" />

Also just a heads up, I think you might have looked at the wrong PR 😄 The line you quoted is from another change

Forgind · 2021-03-05T20:04:35Z

eng/Packages.props

@@ -18,6 +18,7 @@
    <PackageReference Update="SourceLink.Create.CommandLine" Version="2.1.2" />
    <PackageReference Update="System.CodeDom" Version="4.4.0" />
    <PackageReference Update="System.Collections.Immutable" Version="5.0.0" />
+    <PackageReference Update="System.Configuration.ConfigurationManager" Version="4.7.0" />


Do we own this? Also thinking we should try running this through RPS.

Sorry this is my first time making a PR in MSBuild so I'm not familiar with the process. Mihai created an exp/* branch for me here and it triggered an VS insertion and that passed. Is that RPS or do we need to run something else for it?

And I do think we own the package as shown here. The package is owned by Microsoft and dotnetframework.

Great! That is what I was thinking of with RPS. It failed symbol check, but I'm assuming that was innocuous.

I should have clarified that I was wondering if MSBuild owns S.C.CM. I hit a problem at one point when MSBuild updated a package that Roslyn owned, and we had mismatching versions with them. I think that sort of problem would have been caught by RPS, so I think this is good? But I don't feel very confident about that.

Following up to our convo this morning: I talked to @cdmihai and he's not sure about who owns this package exactly either, but believes it should be fine since it is not referenced in VS's config.corext.

I found AssemblyVersions.tt, and it isn't referenced there either.

KirillOsenkov · 2021-03-06T21:05:39Z

src/Build.UnitTests/Evaluation/ImportFromMSBuildExtensionsPath_Tests.cs

                var projColln = new ProjectCollection();
+#else
+                var projColln = new ProjectCollection(ToolsetDefinitionLocations.ConfigurationFile);
+#endif


Would it be possible to extract this to a new method GetProjectCollection() to avoid repeating this code in multiple places?

Oops forgot to reply to this one but this is a good call I made this change as well 😃

KirillOsenkov · 2021-03-06T21:06:19Z

src/Build.UnitTests/Evaluation/ImportFromMSBuildExtensionsPath_Tests.cs

                var projectCollection = new ProjectCollection(new Dictionary<string, string> { ["FallbackExpandDir1"] = extnDir1 });
+#else
+                var projectCollection = new ProjectCollection(new Dictionary<string, string> { ["FallbackExpandDir1"] = extnDir1 }, null, ToolsetDefinitionLocations.ConfigurationFile);


We should add the argument name before null so we know what parameter it is.

That's true, I added the argument name in the GetProjectCollection function

KirillOsenkov · 2021-03-06T21:07:24Z

src/Build.UnitTests/Evaluation/ToolsetConfigurationNet5_Tests.cs

+                }
+            }
+
+            Assert.True(toolsetProperties.ContainsKey("MSBuildSDKsPath"));


Have you looked into using Shouldly? Some other tests use Shouldly, if you just search for it for examples. It's better than the standard asserts.

Updated to Shouldly

benvillalobos · 2021-03-08T16:18:52Z

Note that a DDRIT test failed in the VS PR, but it doesn't explicitly look like us

Test method Microsoft.VisualStudio.Web.DDRIT.CSharpWapTest.CSharpWebApplicationTests threw exception:
Microsoft.Test.Apex.VisualStudio.Debugger.DebuggerException: Unable to stop debugging as the debugger is in 'Design' mode.
Assert.Fail failed. (3:34.844) [Visual Studio Host (7200):BreakPointVerifier] Verification failed: Breakpoint in file 'file:///C:/Test/Results/TestResults/Deploy_TestUser 2021-03-07 19_20_23/Out/TestSolutions/CSharpWAPWebForms/CSharpWAPWebForms/WebForm.aspx.cs', line 13 was hit successfully within 00:02:00 seconds.


Stack trace
 
Server stack trace: 
   at Microsoft.Test.Apex.VisualStudio.Debugger.DebuggerService.Stop(TimeSpan timeout) in Q:\cmd\n\src\omni\Apex\HostIntegration\VisualStudio.OM\Debugger\DebuggerService.cs:line 853
   at Microsoft.Test.Apex.VisualStudio.Debugger.DebuggerService.Stop() in Q:\cmd\n\src\omni\Apex\HostIntegration\VisualStudio.OM\Debugger\DebuggerService.cs:line 840
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)
Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Microsoft.Test.Apex.VisualStudio.Debugger.DebuggerService.Stop()
   at Microsoft.VisualStudio.Web.DDRIT.CSharpWapTest.CSharpWebApplicationTests() in Q:\cmd\w\src\Tests\Microsoft.VisualStudio.Web.DDRIT\CSharpWapTest.cs:line 163

TestCleanup Stack Trace
   at Microsoft.Test.Apex.DelayedAssertionVerifierSink.RerouteAssertion(String message) in Q:\cmd\y\src\omni\Apex\Framework\Verifier\DelayedAssertionVerifierSink.cs:line 423
   at Microsoft.Test.Apex.DelayedAssertionVerifierSink.DoFinalAssertion() in Q:\cmd\y\src\omni\Apex\Framework\Verifier\DelayedAssertionVerifierSink.cs:line 240
   at Microsoft.Test.Apex.ApexTest.TestCleanup() in Q:\cmd\4\src\omni\Apex\MsTestIntegration\ApexTest.cs:line 551
   at Microsoft.Test.Apex.ExternalProcessHostTest`2.TestCleanup() in Q:\cmd\4\src\omni\Apex\MsTestIntegration\ExternalProcessHostTest.cs:line 136
   at Microsoft.Test.Apex.VisualStudio.VisualStudioHostTest.TestCleanup() in Q:\cmd\4\src\omni\Apex\MsTestIntegration\VisualStudioHostTest.cs:line 232

benvillalobos

LGTM

benvillalobos · 2021-03-08T22:22:01Z

src/Build.UnitTests/Microsoft.Build.Engine.UnitTests.csproj

@@ -1,4 +1,4 @@
-<Project Sdk="Microsoft.NET.Sdk">
+<Project Sdk="Microsoft.NET.Sdk">


Hyper-Nit: Is this a BOM change from a text editor?

Yep seems like it... Though I thought I only opened it in VS so it's odd but it should be fixed now 👍

minglunli added 17 commits February 5, 2021 12:57

ToolsetConfigurationReader compilable with net5.0

d3e8516

Allow some unit tests to run in net5.0

d9a316d

Remove System.Configuration Reference completed

046e0a6

Allow IntrinsicFunctions to run in all conditions

9a541e4

Open up Registry as well

d0d0e7e

Removing all FEATURE_SYSTEM_CONFIGURATION that aren't needed

f3d2d22

Adding unit tests

82a23fc

ToolsetConfigurationReader compilable with net5.0

7570c02

Allow some unit tests to run in net5.0

ab9d9ed

Remove System.Configuration Reference completed

8ec091f

Allow IntrinsicFunctions to run in all conditions

b9d7dba

Open up Registry as well

f2e10bd

Removing all FEATURE_SYSTEM_CONFIGURATION that aren't needed

4b1343b

Adding unit tests

1616a36

Merge branch 'toolsetConfigurationNet5' of github.com:minglunli/msbui…

fd7a68f

…ld into toolsetConfigurationNet5

Fixing whitespaces

da88865

Fixing comment and more whitespace

dbc1236

Unit test + package version update

7e4ab72

cdmihai approved these changes Mar 4, 2021

View reviewed changes

Forgind reviewed Mar 5, 2021

View reviewed changes

KirillOsenkov reviewed Mar 6, 2021

View reviewed changes

Addressing PR comments

a5d1939

Forgind approved these changes Mar 8, 2021

View reviewed changes

benvillalobos approved these changes Mar 8, 2021

View reviewed changes

Fix BOM change

6989bc1

Forgind added the merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now. label Mar 9, 2021

benvillalobos merged commit 6848774 into dotnet:master Mar 11, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Toolset configuration net5.0 #6220

Toolset configuration net5.0 #6220

minglunli commented Mar 3, 2021 •

edited

Loading

dnfadmin commented Mar 3, 2021 •

edited

Loading

cdmihai commented Mar 4, 2021

minglunli commented Mar 4, 2021

minglunli commented Mar 4, 2021

Forgind Mar 5, 2021

minglunli Mar 5, 2021

Forgind Mar 5, 2021

minglunli Mar 8, 2021

Forgind Mar 8, 2021

KirillOsenkov Mar 6, 2021

minglunli Mar 9, 2021

KirillOsenkov Mar 6, 2021

minglunli Mar 8, 2021

KirillOsenkov Mar 6, 2021

minglunli Mar 8, 2021

benvillalobos commented Mar 8, 2021

benvillalobos left a comment

benvillalobos Mar 8, 2021

minglunli Mar 9, 2021

		@@ -1,4 +1,4 @@
		<Project Sdk="Microsoft.NET.Sdk">
		<Project Sdk="Microsoft.NET.Sdk">

Toolset configuration net5.0 #6220

Toolset configuration net5.0 #6220

Conversation

minglunli commented Mar 3, 2021 • edited Loading

Context

Changes Made

Testing

dnfadmin commented Mar 3, 2021 • edited Loading

cdmihai commented Mar 4, 2021

minglunli commented Mar 4, 2021

minglunli commented Mar 4, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

benvillalobos commented Mar 8, 2021

benvillalobos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

minglunli commented Mar 3, 2021 •

edited

Loading

dnfadmin commented Mar 3, 2021 •

edited

Loading