Codestin Search App

jjonescz · 2025-08-14T16:11:57Z

Resolves #79907.

jjonescz · 2025-08-14T16:58:58Z

src/Compilers/Core/MSBuildTaskTests/TestUtilities/IntegrationTestBase.cs

+    }
+
+    [Fact, WorkItem("https://github.com/dotnet/roslyn/issues/79907")]
+    public void StdLib()


📝 This file contains only moved code (to share it) except this test which is new (and also shared).

jjonescz · 2025-08-14T16:59:40Z

src/Compilers/Test/Core/Platform/Desktop/TestHelpers.cs

+                .FirstOrDefault()
+                ?? throw new InvalidOperationException("Visual Studio instance not found.");
+            return vsInstance.MSBuildPath;
        }


📝 This didn't work but all the tests using it were skipped.

src/Compilers/Test/Core/Platform/Desktop/TestHelpers.cs

src/Compilers/Core/MSBuildTask/Csc.cs

Co-authored-by: Joey Robichaud <[email protected]>

jjonescz · 2025-08-18T11:34:48Z

@jaredpar @RikkiGibson PTAL

jaredpar · 2025-08-18T16:50:19Z

src/Compilers/Core/MSBuildTask/Csc.cs

            commandLine.AppendSwitchIfNotNull("/nullable:", Nullable);
            commandLine.AppendWhenTrue("/nosdkpath", _store, nameof(DisableSdkPath));

+            // Pass sdkpath if we are invoking core compiler from framework to preserve the behavior that framework compiler would have.


I agree this perfectly preserves the original behavior here where /sdkpath was used whenever we used msbuild. This compiler argument doesn't really make sense in a .NET SDK world though for the following reasons:

It means that project builds would be different when using msbuild and dotnet build because the compiler would get meaningfully different build parameters

It means that when we're building .NET Core projects we're giving them an /sdkpath that points to .NET Framework assemblies.

I'm wondering if there is a way we can constrain this shim a bit to narrow the impact. Would be nice if we could remove (2).

To get rid of (1) perhaps we could use RuntimeEnvironment.GetRuntimeDirectory() even on .NET Core, that also points to a directory which contains mscorlib.dll (albeit the core one, not the framework one, so it's still different). Then we could also get rid of the new /sdkpath: option. That might be a different breaking change though (all core msbuild based builds would now reference mscorlib.dll implicitly).

Getting rid of (2) would still be a breaking change though. Let's say I have this project:

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net10.0</TargetFramework> <OutputType>Exe</OutputType> </PropertyGroup> <Target Name="CustomTarget"> <Csc Sources="File.cs" /> </Target> </Project>

It's a .NET Core project that previously worked and now would be broken.

Btw, if you are building a normal .NET Core app, it should use NoStdLib=true anyway, so mscorlib.dll won't be referenced. I guess the .NET Framework path would still be added to search paths though.

The cleanest solution might be to close this PR and accept the break :) If we want dotnet build and msbuild to behave in the same way and invoke core compiler by default, it would make sense to say that there will be no implicit reference of framework mscorlib.dll.

What would a fix for the break look like? Essentially what code snippet would a customer write in order to get this scenario working again? The fear of the full break is this is most likely to impact customers in older project styles. That is where breaks are the most costly.

They would need to set RoslynCompilerType=Framework (or FrameworkPackage to avoid tearing).

Okay. Yeah that will work but ideally we're slowly deprecating RoslynCompilerType=Framework over the next few years. Don't want to have any scenarios where we're pushing people to use this while we're deprecating it.

src/Compilers/Core/MSBuildTaskTests/Microsoft.Build.Tasks.CodeAnalysis.UnitTests.csproj

src/Compilers/CSharp/Portable/CommandLine/CSharpCommandLineParser.cs

src/Compilers/Core/MSBuildTask/Csc.cs

src/Compilers/CSharp/Portable/CommandLine/CSharpCommandLineParser.cs

src/Compilers/Core/MSBuildTask/Csc.cs

jaredpar · 2025-08-20T18:17:17Z

src/Compilers/CSharp/Portable/CSharpResources.resx

                              each error
 -preferreduilang              Specify the preferred output language name.
 -nosdkpath                    Disable searching the default SDK path for standard library assemblies.
+-sdkpath:&lt;path&gt;         Location of the .NET Framework SDK directory (mscorlib.dll).


Suggested change

-sdkpath:<path> Location of the .NET Framework SDK directory (mscorlib.dll).

-sdkpath:<path> Path used to search for standard library assemblies

Wanted to remove the Framework reference here as it's possible in the future we'd use this for .NET SDK as well. Consider for example that the RSP file we're generating for dotnet run app.cs could one day take advantage of this. Intstead of full pathing everything in the RSP it could be relative path + using /sdkpath to control where to look.

Tried to pattern the message no the wording of -nosdkpath

jaredpar · 2025-08-21T05:52:02Z

@RikkiGibson PTAL

RikkiGibson · 2025-08-21T20:30:52Z

src/Compilers/Core/MSBuildTask/Csc.cs

        protected override void AddResponseFileCommands(CommandLineBuilderExtension commandLine)
        {
+            // Pass sdkpath if we are invoking core compiler from framework to preserve the behavior that framework compiler would have.
+            // Pass this option only to the built-in compiler (customer-supplied compiler might not support it).


I am somewhat confused by this, if user-supplied compiler doesn't respect this option, don't we have a reason to believe their compiler will not behave correctly? So why avoid passing the argument?

I guess you are right. I was worried about this causing another regression (the custom compiler failing with unknown argument).

RikkiGibson · 2025-08-21T20:38:12Z

src/Compilers/Core/MSBuildTask/Vbc.cs

        protected override void AddResponseFileCommands(CommandLineBuilderExtension commandLine)
        {
+            // Pass sdkpath if we are invoking core compiler from framework to preserve the behavior that framework compiler would have.
+            // Pass this option only to the built-in compiler (customer-supplied compiler might not support it).


Same comment

RikkiGibson · 2025-08-21T20:42:52Z

src/Compilers/Core/MSBuildTaskTests/TestUtilities/IntegrationTestBase.cs

+    [Theory, CombinatorialData, WorkItem("https://github.com/dotnet/roslyn/issues/79907")]
+    public void StdLib_Csc(bool useSharedCompilation, bool disableSdkPath)
+    {
+        if (_msbuildExecutable == null) return;


Would it be helpful to log that we are essentially skipping the test in this scenario and in similar place in StdLib_Vbc test below?

We log that in the constructor which runs for each test separately, so the test's log contain the information:

roslyn/src/Compilers/Core/MSBuildTaskTests/TestUtilities/IntegrationTestBase.cs

Lines 32 to 37 in e927f0b

protected IntegrationTestBase(ITestOutputHelper output)

{

if (s_msbuildDirectory == null)

{

output.WriteLine("Could not locate MSBuild");

}

RikkiGibson · 2025-08-21T20:56:14Z

src/Scripting/CSharpTest.Desktop/InteractiveSessionReferencesTests.cs

        });

-        [Fact]
+        [Fact(Skip = "https://github.com/dotnet/roslyn/issues/79923")]


Normally I really do not like to skip tests if it can be avoided, but, it feels like the non-deterministic behavior makes this necessary.

This test is completly unrelated to this PR and it has not worked for some time but my infra fixes made it actually run in the CI.

Follow up on #79911. Fixes another inconsistency between the core and fx compilers: if the `<Csc>` task is used manually on a C# file which has `using System.Linq;` (for example), the fx compiler handles that fine (because there is `csc.rsp` deployed with it which has a set of default references) whereas the core compiler fails. A real-world use-case can be seen in https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/684436. The fix is to include this default `csc.rsp` in scenarios where we invoke the core compiler on fx msbuild (to avoid a break there). We continue to not include that `csc.rsp` in scenarios where just the core csc is being used (again, to avoid a break in those scenarios).

Fix stdlib inconsistency between core and fx compiler

0405e26

github-actions bot added the Area-Compilers label Aug 14, 2025

Simplify infra

ee730c8

jjonescz commented Aug 14, 2025

View reviewed changes

JoeRobich reviewed Aug 14, 2025

View reviewed changes

src/Compilers/Test/Core/Platform/Desktop/TestHelpers.cs Outdated Show resolved Hide resolved

src/Compilers/Core/MSBuildTask/Csc.cs Outdated Show resolved Hide resolved

jjonescz and others added 2 commits August 14, 2025 19:39

Improve wording

c01112b

Co-authored-by: Joey Robichaud <[email protected]>

Fix missing MSBuild where possible

dac4814

build-analysis bot mentioned this pull request Aug 15, 2025

The active test run was aborted. Reason: Test host process crashed dotnet/dnceng#451

Closed

3 tasks

jjonescz added 3 commits August 15, 2025 13:24

Fix csc dep missing

ca21080

Fix bincore hydratation

68d20d8

Skip broken tests

777edea

jjonescz marked this pull request as ready for review August 15, 2025 16:08

jjonescz requested review from a team as code owners August 15, 2025 16:08

JoeRobich approved these changes Aug 15, 2025

View reviewed changes

jaredpar reviewed Aug 18, 2025

View reviewed changes

src/Compilers/Core/MSBuildTaskTests/Microsoft.Build.Tasks.CodeAnalysis.UnitTests.csproj Outdated Show resolved Hide resolved

jaredpar reviewed Aug 19, 2025

View reviewed changes

src/Compilers/CSharp/Portable/CommandLine/CSharpCommandLineParser.cs Show resolved Hide resolved

src/Compilers/Core/MSBuildTask/Csc.cs Outdated Show resolved Hide resolved

src/Compilers/CSharp/Portable/CommandLine/CSharpCommandLineParser.cs Show resolved Hide resolved

jjonescz added 3 commits August 19, 2025 13:15

Handle VB

2eba38f

Deduplicate items

5b693b5

Improve deduplication

7afcc10

jaredpar reviewed Aug 19, 2025

View reviewed changes

src/Compilers/Core/MSBuildTask/Csc.cs Show resolved Hide resolved

jjonescz added 2 commits August 20, 2025 16:15

Fix ordering

fc3ce83

Improve UX

33964c9

jaredpar approved these changes Aug 20, 2025

View reviewed changes

Update help text

e927f0b

RikkiGibson self-assigned this Aug 21, 2025

RikkiGibson reviewed Aug 21, 2025

View reviewed changes

RikkiGibson approved these changes Aug 21, 2025

View reviewed changes

Pass option to custom compiler too

ecc66ac

jjonescz merged commit 091085e into dotnet:main Aug 25, 2025
28 checks passed

jjonescz deleted the 79907-StdLib branch August 25, 2025 09:16

dotnet-policy-service bot added this to the Next milestone Aug 25, 2025

This was referenced Aug 29, 2025

[Automated] PRs inserted in VS build main-10928.85 #80074

Closed

[Automated] PRs inserted in VS build feature.debugger.main-10928.208 #80080

Closed

akhera99 modified the milestones: Next, 18.0 P1, 18.0 P2 Sep 22, 2025

jjonescz mentioned this pull request Nov 3, 2025

Include default RSP files for core compilers #80993

Merged

	-sdkpath:<path> Location of the .NET Framework SDK directory (mscorlib.dll).
	-sdkpath:<path> Path used to search for standard library assemblies

	protected IntegrationTestBase(ITestOutputHelper output)
	{
	if (s_msbuildDirectory == null)
	{
	output.WriteLine("Could not locate MSBuild");
	}

Comments

Conversation

jjonescz commented Aug 14, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jjonescz commented Aug 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jjonescz Aug 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaredpar commented Aug 21, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jjonescz Aug 19, 2025 •

edited

Loading