Type definitions are loaded by IDE out of the box by ilonatommy · Pull Request #132122 · dotnet/runtime

ilonatommy · 2026-08-11T09:08:15Z

Follow-up for #120097.

The original PR was placing the definitions in wwwroot, while the corresponding dotnet.js source file is imported from wwwroot/_framework. That prevented IDE from automatically resolving the types and required additional workarounds on the developer side.

Fix:
Create wwwroot/_framework during build with dotnet.d.ts inside.

How it works in practice

Intelisense-fixed.mp4

azure-pipelines · 2026-08-11T09:08:59Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Copilot

Pull request overview

This PR updates the WebAssembly SDK’s handling of dotnet.d.ts so TypeScript definitions are placed beside runtime assets under wwwroot/_framework and are included appropriately in publish output, with corresponding test updates.

Changes:

Copy dotnet.d.ts to wwwroot/_framework/dotnet.d.ts (instead of wwwroot/dotnet.d.ts) when WasmEmitTypeScriptDefinitions=true.
Ensure dotnet.d.ts is published alongside dotnet.js under the published wwwroot/_framework directory.
Update WASM build tests/bundle assertions to optionally expect dotnet.d.ts when enabled.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/mono/wasm/Wasm.Build.Tests/WasmSdkBasedProjectProvider.cs	Extends expected runtime file sets to include `dotnet.d.ts` when tests opt in.
src/mono/wasm/Wasm.Build.Tests/Templates/WasmTemplateTests.cs	Updates the TypeScript definitions test to validate the new `_framework` location and publish behavior.
src/mono/wasm/Wasm.Build.Tests/ProjectProviderBase.cs	Excludes `dotnet.d.ts` from boot-json entry validation (it’s not a boot resource).
src/mono/wasm/Wasm.Build.Tests/BrowserStructures/MSBuildOptions.cs	Adds a test harness flag to indicate when `dotnet.d.ts` should be expected.
src/mono/wasm/build/WasmApp.Common.targets	Updates documentation comment describing the new output location.
src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets	Implements new build/publish targets to place `dotnet.d.ts` under `wwwroot/_framework` and include it in publish output.

Copilot

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets:1307

_EnsureDotnetTypeScriptDefinitions is gated on !Exists('$(_DotnetTypesDestPath)'), which means dotnet.d.ts will never be refreshed once created. If the runtime pack’s dotnet.d.ts changes (e.g., SDK/runtime update), projects will keep a stale copy unless the file is manually deleted. Consider switching to a proper incremental target keyed off the source file (Inputs/Outputs) rather than skipping solely based on destination existence.

  <Target Name="_EnsureDotnetTypeScriptDefinitions" 
          DependsOnTargets="ResolveRuntimePackAssets"
          AfterTargets="PrepareForBuild"
          Outputs="$(_DotnetTypesDestPath)"
          Condition="'$(WasmEmitTypeScriptDefinitions)' == 'true' and !Exists('$(_DotnetTypesDestPath)')">

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets:1307

The _EnsureDotnetTypeScriptDefinitions target is currently gated on !Exists('$(_DotnetTypesDestPath)'), which makes the copy effectively “one-shot”. If the runtime pack’s dotnet.d.ts changes (e.g., after upgrading the SDK/runtime pack), the project’s wwwroot/_framework/dotnet.d.ts will never be refreshed, leaving stale typings.

Consider making this target properly incremental based on source→dest timestamps/content (Inputs/Outputs), and rely on Copy SkipUnchangedFiles for the common no-op case, rather than skipping solely because the destination already exists.

  <Target Name="_EnsureDotnetTypeScriptDefinitions" 
          DependsOnTargets="ResolveRuntimePackAssets"
          AfterTargets="PrepareForBuild"
          Outputs="$(_DotnetTypesDestPath)"
          Condition="'$(WasmEmitTypeScriptDefinitions)' == 'true' and !Exists('$(_DotnetTypesDestPath)')">

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets:1296

The Content Remove only excludes wwwroot\_framework\dotnet.d.ts. If a project previously built with an older SDK already has a stale wwwroot\dotnet.d.ts on disk, the default wwwroot glob can still pick it up when WasmEmitTypeScriptDefinitions=true, reintroducing the publish/content-item issue this block is trying to prevent.

  <ItemGroup Condition="'$(WasmEmitTypeScriptDefinitions)' == 'true'">
    <Content Remove="wwwroot\_framework\dotnet.d.ts" />
  </ItemGroup>

Hedbugg

nice

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets:1301

The top-level PropertyGroup defining _DotnetTypesDestPath is redundant because the same property is (re)computed in _ResolveDotnetTypeScriptDefinitionPaths before _EnsureDotnetTypeScriptDefinitions uses it. Keeping two definitions makes it harder to reason about which value is in effect and can lead to future edits updating only one location.

  <!-- Ensure dotnet.d.ts is beside dotnet.js in wwwroot/_framework for TypeScript development experience when enabled -->
  <PropertyGroup>
    <_DotnetTypesDestPath>$([MSBuild]::NormalizePath($([MSBuild]::NormalizeDirectory($(MSBuildProjectDirectory), 'wwwroot', '_framework')), 'dotnet.d.ts'))</_DotnetTypesDestPath>

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets:1297

The Content Remove entries are conditioned on WasmEmitTypeScriptDefinitions=true, which means if the property is later turned off (or the file exists from a previous build), wwwroot/** globs can start picking up dotnet.d.ts again, potentially changing build/publish inputs unexpectedly. Since this file is always build-generated, consider removing it from @(Content) unconditionally to keep behavior stable regardless of the property’s current value.

  <ItemGroup Condition="'$(WasmEmitTypeScriptDefinitions)' == 'true'">
    <Content Remove="wwwroot\dotnet.d.ts" />
    <Content Remove="wwwroot\_framework\dotnet.d.ts" />
  </ItemGroup>

src/mono/wasm/Wasm.Build.Tests/Templates/WasmTemplateTests.cs:358

This comment is now slightly misleading: the test is checking both wwwroot/_framework/dotnet.d.ts and wwwroot/dotnet.d.ts, not just the wwwroot root. Updating the wording will keep the test intent clear.

            // Verify dotnet.d.ts is not in wwwroot after creation

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets:1321

_EnsureDotnetTypeScriptDefinitions only hooks AfterTargets="PrepareForBuild", so dotnet publish /p:NoBuild=true won’t run this target even though it’s a publish invocation. If the intent is “build/publish”, consider also hooking into the publish pipeline (e.g., BeforeTargets="PrepareForPublish") to cover NoBuild publishes.

  <Target Name="_EnsureDotnetTypeScriptDefinitions"
          DependsOnTargets="_ResolveDotnetTypeScriptDefinitionPaths"
          AfterTargets="PrepareForBuild"
          Inputs="$(_DotnetTypesSourcePath)"
          Outputs="$(_DotnetTypesDestPath)"
          Condition="'$(WasmEmitTypeScriptDefinitions)' == 'true'">

src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets:1302

_DotnetTypesDestPath is computed twice (once in the standalone <PropertyGroup> and again in _ResolveDotnetTypeScriptDefinitionPaths). This duplication makes it easy for the two definitions to drift and obscures which value the target’s incremental Outputs is meant to use. Consider defining _DotnetTypesDestDir/_DotnetTypesDestPath once in the property group and letting the resolve target focus only on the runtime-pack source path.

This issue also appears on line 1316 of the same file.

  <!-- Ensure dotnet.d.ts is beside dotnet.js in wwwroot/_framework for TypeScript development experience when enabled -->
  <PropertyGroup>
    <_DotnetTypesDestPath>$([MSBuild]::NormalizePath($([MSBuild]::NormalizeDirectory($(MSBuildProjectDirectory), 'wwwroot', '_framework')), 'dotnet.d.ts'))</_DotnetTypesDestPath>
  </PropertyGroup>

src/mono/wasm/Wasm.Build.Tests/Templates/WasmTemplateTests.cs:366

The updated logic is intended to run on both build and publish, but this test still only exercises the build path. Adding a publish variant (e.g., parameterize build vs publish and call PublishProject as well) would help ensure the wwwroot/_framework/dotnet.d.ts copy behaves the same across both entrypoints.

            // Build to trigger the _EnsureDotnetTypeScriptDefinitions target during the build phase
            BuildProject(info, config, new BuildOptions());

            // Verify dotnet.d.ts presence in the project's wwwroot/_framework directory after build
            bool fileExists = File.Exists(dotnetDtsWwwrootPath);

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

ArcadeMode

Looks great 👍

pavelsavara · 2026-08-11T14:52:21Z

Where is the dotnet.d.ts sourced from ? Is it from the runtime pack ?

ilonatommy · 2026-08-12T07:52:29Z

Where is the dotnet.d.ts sourced from ? Is it from the runtime pack ?

Yes, it's this line:

<_DotnetTypesSourcePath>$([MSBuild]::NormalizePath($(_RuntimePackNativeDir), 'dotnet.d.ts'))</_DotnetTypesSourcePath>

When WsmEmitTypeScriptDefinitions=true the build copies the file from runtime pack to the app project.

Cleanup #132122 (comment) 1) The original change belonged to net11 previews so it's a subject to change, we don't need to provide a way to clean "wwwroot\dotnet.d.ts" on upgrade. 2) The new target added in #132122 used public `WasmEmitTypeScriptDefinitions`, not internal `_WasmEmitTypeScriptDefinitions`.

Fix: definitions are placed in _framework dir after build/publish.

a12d961

ilonatommy self-assigned this Aug 11, 2026

Copilot AI lite review requested due to automatic review settings August 11, 2026 09:08

ilonatommy requested a review from maraf as a code owner August 11, 2026 09:08

ilonatommy added the arch-wasm WebAssembly architecture label Aug 11, 2026

ilonatommy requested review from akoeplinger and lewing as code owners August 11, 2026 09:08

ilonatommy added the area-Build-mono label Aug 11, 2026

Copilot started reviewing on behalf of ilonatommy August 11, 2026 09:08

View session

ilonatommy added this to the 11.0.0 milestone Aug 11, 2026

Copilot AI reviewed Aug 11, 2026

View reviewed changes

Comment thread ...nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets Resolved

Comment thread src/mono/wasm/Wasm.Build.Tests/BrowserStructures/MSBuildOptions.cs Resolved

Limit changes to comments.

8a67702

Copilot AI review requested due to automatic review settings August 11, 2026 09:17

Copilot started reviewing on behalf of ilonatommy August 11, 2026 09:18

View session

Copilot AI reviewed Aug 11, 2026

View reviewed changes

Comment thread src/mono/wasm/Wasm.Build.Tests/Templates/WasmTemplateTests.cs Resolved

Publish bundle doesn't need type definition file.

55ac0f7

Copilot AI review requested due to automatic review settings August 11, 2026 10:00

Copilot started reviewing on behalf of ilonatommy August 11, 2026 10:01

View session

Copilot AI reviewed Aug 11, 2026

View reviewed changes

Feedback: fix stale typings risk.

10d5225

Copilot AI review requested due to automatic review settings August 11, 2026 10:08

Copilot started reviewing on behalf of ilonatommy August 11, 2026 10:08

View session

Copilot AI reviewed Aug 11, 2026

View reviewed changes

Hedbugg reviewed Aug 11, 2026

View reviewed changes

Remove publish asserts.

6348b25

Copilot AI review requested due to automatic review settings August 11, 2026 10:21

Copilot started reviewing on behalf of ilonatommy August 11, 2026 10:21

View session

ilonatommy added 2 commits August 11, 2026 10:22

Feedback: backward compatibility.

a6b333f

Whitespace

6c579c6

Copilot AI reviewed Aug 11, 2026

View reviewed changes

Copilot AI review requested due to automatic review settings August 11, 2026 10:25

Copilot started reviewing on behalf of ilonatommy August 11, 2026 10:25

View session

Copilot AI reviewed Aug 11, 2026

View reviewed changes

Feedback: update stale comment.

468f5a3

Copilot AI review requested due to automatic review settings August 11, 2026 10:33

Copilot started reviewing on behalf of ilonatommy August 11, 2026 10:33

View session

Copilot AI reviewed Aug 11, 2026

View reviewed changes

Avoid recomputing typescript definition paths.

64c75bd

Copilot AI review requested due to automatic review settings August 11, 2026 10:57

Copilot started reviewing on behalf of ilonatommy August 11, 2026 10:57

View session

Copilot AI reviewed Aug 11, 2026

View reviewed changes

ArcadeMode approved these changes Aug 11, 2026

View reviewed changes

pavelsavara approved these changes Aug 12, 2026

View reviewed changes

ilonatommy merged commit 3265efb into main Aug 12, 2026
48 checks passed

ilonatommy deleted the improve-120097 branch August 12, 2026 09:02

akoeplinger reviewed Aug 12, 2026

View reviewed changes

Comment thread ...nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets Resolved

ilonatommy mentioned this pull request Aug 12, 2026

Remove obsolete WASM TypeScript definition cleanup logic #132208

Merged

dotnet-maestro Bot mentioned this pull request Aug 13, 2026

[main] Source code updates from dotnet/runtime dotnet/dotnet#8272

Merged

dotnet-milestone-bot Bot modified the milestones: 11.0.0, 11.0-rc1 Aug 13, 2026

github-actions Bot locked and limited conversation to collaborators Sep 14, 2026

Conversation

ilonatommy commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

azure-pipelines Bot commented Aug 11, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Hedbugg left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

ArcadeMode left a comment

Choose a reason for hiding this comment

Uh oh!

pavelsavara commented Aug 11, 2026

Uh oh!

ilonatommy commented Aug 12, 2026

Uh oh!

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

ilonatommy commented Aug 11, 2026 •

edited

Loading