From f561312ea936d5dd8e85567ab803a16c36e3ff73 Mon Sep 17 00:00:00 2001 From: Rainer Sigwald Date: Thu, 9 Jan 2020 17:10:58 -0600 Subject: [PATCH] Clarify comment about MSBuildLoadContext test The confusing situation can be resolved by an IVT change, filed as #5041. --- src/MSBuild.UnitTests/ValidateAssemblyLoadContext.cs | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/MSBuild.UnitTests/ValidateAssemblyLoadContext.cs b/src/MSBuild.UnitTests/ValidateAssemblyLoadContext.cs index 095d1f1a45c..4cdcab25b0d 100644 --- a/src/MSBuild.UnitTests/ValidateAssemblyLoadContext.cs +++ b/src/MSBuild.UnitTests/ValidateAssemblyLoadContext.cs @@ -16,8 +16,11 @@ public override bool Execute() { var thisLoadContext = AssemblyLoadContext.GetLoadContext(typeof(ValidateAssemblyLoadContext).Assembly); - // Check by name because this always reports false, presumably due to ALC shenanigans: - // if (thisLoadContext is MSBuildLoadContext context) + // The straightforward implementation of this check: + // if (thisLoadContext is MSBuildLoadContext context) + // fails here because MSBuildLoadContext (in this test assembly) is from MSBuild.exe via + // IVT, but the one that actually gets used for task isolation is in Microsoft.Build.dll. + // This probably doesn't need to be how it is forever: https://github.com/microsoft/msbuild/issues/5041 if (thisLoadContext.GetType().FullName == typeof(MSBuildLoadContext).FullName) { #if NETCOREAPP && !NETCOREAPP2_1 // TODO: enable this functionality when targeting .NET Core 3.0+