System.Web reference is dropped from @(Reference) when building with the dotnet CLI (Core MSBuild)

[ehasis]

Split out from #103 (item 1).

Summary

When a project that uses MSBuild.SDK.SystemWeb is built with dotnet build (Core MSBuild), the System.Web framework reference never reaches the compiler, so any use of System.Web.* types fails to compile — e.g. error BC30002: type 'System.Web.HttpApplication' is not defined / error CS0246. Building the same project with the full Visual Studio MSBuild works fine.

Details

The SDK contributes the reference here: src/MSBuild.SDK.SystemWeb.CommonFiles/Sdk/MSBuild.SDK.SystemWeb.Common.DefaultPackages.targets

<ItemGroup Condition="'$(ExcludeSDKDefaultPackages)'=='false'">
  ...
  <Reference Include="System.Web" />
</ItemGroup>

That file is imported at the top of Sdk.targets, i.e. before <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />.

Observed under Core MSBuild (dotnet):

• Other default framework references (System, System.Core, System.Data, …) resolve from the v4.x reference assemblies and reach vbc/csc.
• System.Web does not appear in @(Reference) at ResolveAssemblyReferences time, so it is never passed to the compiler.
• A bare framework <Reference Include="System.Web" /> declared after the Microsoft.NET.Sdk targets import — or in the project body — does survive and resolve. So the drop is tied to declaring it before those targets, under Core MSBuild only.

Minimal repro

net48 project with <Project Sdk="MSBuild.SDK.SystemWeb/<ver>"> and a class that references System.Web.HttpApplication; a minimal web.config. dotnet build fails; msbuild (full VS) succeeds.

Open question (help wanted)

I have not yet pinned down the exact Microsoft.NET.Sdk target/logic that removes the pre-import reference under Core MSBuild — happy to dig further. If you (or anyone) recognize the mechanism, that would confirm the right fix. This is the "reference to the main Microsoft.NET.Sdk" you asked about.

Proposed fix

Re-declare System.Web after the Microsoft.NET.Sdk targets import, gated on '$(MSBuildRuntimeType)' == 'Core' so the full VS MSBuild keeps using the existing Common.DefaultPackages.targets reference and there is no duplicate (MSB3105).

[CZEMacLeod]

I cannot replicate this issue. Can you confirm which dotnet SDK version you are building with, and/or create a repo with a project which replicated the error.

See CZEMacLeod/TestSystemWebRef) for my testing.

[ehasis]

@CZEMacLeod Your are right — there was "something else going on," and after digging in I'm closing the System.Web item (1). It isn't a real standalone problem. Here's what I found.

The System.Web reference is provided by Microsoft.WebApplication.targets itself. When that file is imported, it adds <Reference Include="System.Web" />. So as soon as the import is resolved (i.e. the WebApplicationsTargetPath / item 2 problem is fixed, by any means), System.Web is in @(Reference) and resolves from the v4.x reference assemblies — under both the full Visual Studio MSBuild and the .NET Core MSBuild used by dotnet.

What threw me off:

• The released 4.0.106 doesn't reference System.Web in Common.DefaultPackages.targets — but you already added it in 23199f7 on main (so it's there). Either way it turns out not to be the deciding factor.
• More importantly, my original "the reference gets dropped under Core MSBuild" observation was an artifact of an inconsistent local SDK cache while I was iterating (the web targets weren't being imported in some of those states, so nothing was supplying System.Web). It wasn't real SDK behavior.

To verify, I built minimal repros that use System.Web against SDK 4.0.106 with dotnet build:

• C# (HttpApplication) and VB (with project-level Imports System.Web / Imports System.Web.SessionState, like a Global.asax).
• Without working around anything → fails with MSB4019 (that's item 2 — the web targets aren't found).
• With only the web-targets import resolved (e.g. -p:WebApplicationsTargetPath=<VS>\...\WebApplications\Microsoft.WebApplication.targets) → both compile fine, and @(Reference) begins with System.Web.

So there's no window where System.Web fails on its own: resolving the web-targets import brings it along. Item 1 is subsumed by item 2.

Closing this one. I'll keep the separate PRs/issues focused on:

• the actionable error when WebApplicationsTargetPath can't be resolved (item 2),
• the MvcBuildViews / AspNetCompiler MSB4803 message under Core MSBuild (item 3),
• and the optional, opt-in auto-location of WebApplicationsTargetPath (item 4).

Thanks for pushing back on this — it saved a change that wasn't needed.