Move TemplateEngine TestTemplates to TestAssets/TestPackages/TemplateEngine#53733
Merged
MichaelSimons merged 1 commit intoApr 7, 2026
Merged
Conversation
…Engine These are test assets consumed at test time (packed into a NuGet package by tests), not build targets. Move them to TestAssets/ where they belong alongside other test-only content and inherit the existing build isolation provided by TestAssets/Directory.Build.props. The csproj now targets netstandard2.0 since it is a content-only template package with no build output.
Contributor
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Moves TemplateEngine test template assets under test/TestAssets/ to better align with test-only build isolation, and updates the associated package project settings for a content-only template NuGet package.
Changes:
- Relocates
Microsoft.TemplateEngine.TestTemplatesundertest/TestAssets/TestPackages/TemplateEngine/ - Changes the template package project to target
netstandard2.0 - Replaces
IsTestUtilityProjectwithIsShippingmetadata
Comments suppressed due to low confidence (1)
test/TestAssets/TestPackages/TemplateEngine/Microsoft.TemplateEngine.TestTemplates.csproj:1
- The PR description states this is a content-only template package with no build output, but targeting
netstandard2.0will still compile and (by default) include build output duringpack. If the intent is truly content-only, set the project up to avoid producing/including build outputs (e.g., set properties likeNoBuildand/orIncludeBuildOutputappropriately for packing) so the generated NuGet contains only the template content.
<Project Sdk="Microsoft.NET.Sdk">
NikolaMilosavljevic
approved these changes
Apr 7, 2026
Member
Author
|
/ba-g known windows agent machine outage. Other legs provide sufficient coverage for this change. |
dsplaisted
added a commit
that referenced
this pull request
May 13, 2026
PR #53733 moved test templates to test/TestAssets/TestPackages/TemplateEngine/. This codeflow re-introduces the old location from the VMR, which still has leftover files from when dotnet/templating was flowing in (now consolidated). The old-location files are unreferenced by sdk.slnx / TemplateEngine.slnf but get picked up by test/UnitTests.proj's `**\*.Tests.csproj` glob, causing NETSDK1138 (net7.0 EOL) and NU1008 (inline Version + CPM) on MyTestProject.Tests.csproj. Companion VMR cleanup: dotnet/dotnet#6594. Once that merges, future codeflow PRs won't re-introduce these files.
dotnet-maestro Bot
added a commit
that referenced
this pull request
May 18, 2026
[main] Source code updates from dotnet/dotnet - Update generated file Cherry-picked from 043321b (old codeflow PR #53847). Changes test class name reference and removes MetadataUpdater.IsSupported entry. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> - Update compiler error code in a test Cherry-picked from 84f3119 (old codeflow PR #53847). Updates CS1040 -> CS9378 for shebang-related compiler error. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> - Remove vestigial test_templates at old TemplateEngine.TestTemplates path PR #53733 moved test templates to test/TestAssets/TestPackages/TemplateEngine/. This codeflow re-introduces the old location from the VMR, which still has leftover files from when dotnet/templating was flowing in (now consolidated). The old-location files are unreferenced by sdk.slnx / TemplateEngine.slnf but get picked up by test/UnitTests.proj's `**\*.Tests.csproj` glob, causing NETSDK1138 (net7.0 EOL) and NU1008 (inline Version + CPM) on MyTestProject.Tests.csproj. Companion VMR cleanup: dotnet/dotnet#6594. Once that merges, future codeflow PRs won't re-introduce these files. - Containers SanityTest: remove Microsoft.Extensions.Logging.Abstractions The codeflow backflow commit dropped Microsoft.Extensions.Logging.Abstractions from Microsoft.NET.Build.Containers.csproj (it''s transitively pulled in via Microsoft.Extensions.Logging and doesn''t need to be redistributed). Update the SanityTest_NET_Build_ContainersDependencies known list to match. - dotnet-new: update verified baselines for template changes The codeflow brought in template changes that affect the output of `dotnet new` template-listing commands: - Added: blazor-wasm-servicedefaults, blazorwebworker - Removed: webworker (renamed to blazorwebworker) Update the .verified.txt baseline files for the affected tests on all three OS platforms: - DotnetNewCompleteTests.CanDoTabCompletion - DotnetNewListTests.BasicTest_WhenListCommandIsUsed - DotnetNewListTests.BasicTest_WhenLegacyCommandIsUsed - Blazor: regenerate StaticWebAssets baselines for new framework assemblies The codeflow brought in AspNetCore changes that include the following Microsoft.Extensions.* abstraction assemblies in the published Blazor wasm output where they previously were not: - Microsoft.Extensions.Configuration.Abstractions - Microsoft.Extensions.DependencyInjection.Abstractions - Microsoft.Extensions.FileProviders.Abstractions - Microsoft.Extensions.Logging.Abstractions - Microsoft.Extensions.Options - Microsoft.Extensions.Primitives Regenerated baselines via: dotnet exec Microsoft.NET.Sdk.BlazorWebAssembly.Tests.dll -trait "AspNetCore=BaselineTest" with environment variable ASPNETCORE_TEST_BASELINES=true. - test: include working-dir tail in Helix binlog upload name When tests run in Helix, every test that uses ExecuteCommand/CreateBuildCommand writes a relative-path binlog (e.g. `msbuild0.binlog`) to its per-test working directory. The upload step in TestCommand.Execute() copies those binlogs to HELIX_WORKITEM_UPLOAD_ROOT using only Path.GetFileName, so multiple tests in the same Helix work item all collide on the same upload name and overwrite each other; only the last test's binlog actually gets uploaded. Prefix the destination filename with the last two segments of the test's working directory (typically `<TestInstance>---<GUID>-<ProjectDir>`) so each test's binlog lands at a unique upload path and we can correlate failures with their binlogs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> - test: fix race where InitSdkVersion temporarily nulls FullFrameworkMSBuildPath on shared singleton Background: ToolsetInfo is a process-wide singleton accessed by all xUnit tests. InitSdkVersion runs `dotnet --version` to discover the SDK version, and to avoid recursing back into itself via AddTestEnvironmentVariables -> SdkVersion, it temporarily nulls FullFrameworkMSBuildPath on the singleton while the subprocess runs. When tests run in parallel (which the new TestPlatform/xUnit-v3 dispatch is more aggressive about than the previous version), another test thread that hits ToolsetInfo.CreateCommand during that window reads the transient null, treats ShouldUseFullFrameworkMSBuild as false, and silently invokes `dotnet msbuild` (Core MSBuild) instead of the desktop MSBuild that the FullFramework test leg requested. Observed regression: `GivenThatWeWantToBuildWithGlobalJson.It_fails_build_on_failed_sdk_resolution(runningInVS: True)` fails on the FullFramework leg because the Microsoft.DotNet.MSBuildSdkResolver (loaded via MSBUILDADDITIONALSDKRESOLVERSFOLDER_NETFRAMEWORK, which Core MSBuild doesn't read) is not loaded, so the expected `warning : Unable to locate the .NET SDK` is never emitted. Confirmed against the latest PR build (Core MSBuild 18.8.0-preview-26261-101 + MSBuildRuntimeType=Core) vs. recent main build 1417464 (Desktop MSBuild 18.6.1 + MSBuildRuntimeType=Full). Fix: replace the mutation of the shared FullFrameworkMSBuildPath with a [ThreadStatic] suppression flag. InitSdkVersion sets the flag for its own thread (preserving the recursion break for its DotnetCommand subprocess) but no longer perturbs the property other test threads observe. A private EffectiveFullFrameworkMSBuildPath helper returns null when the per-thread flag is set, otherwise the real value; CreateCommand and AddTestEnvironmentVariables now consult Effective* so the suppress thread breaks recursion as before while parallel test threads continue to see the real desktop MSBuild path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> - dotnet-new: bump AddPackageReference template Newtonsoft.Json version to 13.0.4 The Newtonsoft.Json package version was bumped from 13.0.3 to 13.0.4 in eng/Versions.props (commit 1599541, "Update Newtonsoft.Json to 13.0.4 to fix NU1109"). The corresponding test template still hardcoded 13.0.3, causing three tests to fail: - PostActionTests.AddPackageReference_Basic - PostActionTests.AddPackageReference_Basic_Approval - PostActionTests.ItCanCreateTemplate_WithAddPackageReference The first two tests assert via HaveStdOutContaining($"Adding a package reference Newtonsoft.Json (version: {ToolsetInfo.GetNewtonsoftJsonPackageVersion()})"), which expects the SDK-side version (13.0.4) but gets the template's hardcoded 13.0.3 in the CLI output. The Approval variant additionally relies on a regex scrubber anchored on the same "(version: <SDK Newtonsoft version>)" text, so the callback output isn't scrubbed when the versions mismatch. Bump the hardcoded version in both templates (Basic and BasicWithFiles) and update the three verified.txt files (Windows/Linux/OSX). This mirrors the precedent from commit b1dd035 (dotnet/templating@d845c2d8, Sep 2023), which made the equivalent 13.0.1 -> 13.0.3 update when eng/Versions.props was bumped earlier. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> - Don't expect wasm files in build output - dotnet-new: bump dotnet-new test_templates Newtonsoft.Json version to 13.0.4 The previous commit (071fdbb) bumped the TemplateEngine variants of the AddPackageReference test templates to 13.0.4 but missed the dotnet-new variants under test/TestAssets/TestPackages/dotnet-new/test_templates/, which are the ones actually consumed by the failing dotnet-new.IntegrationTests: - PostActionTests.AddPackageReference_Basic - PostActionTests.AddPackageReference_Basic_Approval - PostActionTests.ItCanCreateTemplate_WithAddPackageReference These tests assert via HaveStdOutContaining(\$"Adding a package reference Newtonsoft.Json (version: {ToolsetInfo.GetNewtonsoftJsonPackageVersion()})"), which expects the SDK-side 13.0.4 but received the template's hardcoded 13.0.3. The Approval variant additionally has a ScrubByRegex anchored on the same "(version: <SDK Newtonsoft version>)" text, so the NuGet callback output (including the two new `X.509 certificate chain validation will use the fallback certificate bundle` info lines from NuGet 7.7) goes unscrubbed when the versions mismatch. Bump the three dotnet-new template.json files to match. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> - dotnet-watch tests: send 'a' after rename in RenameSourceFile to dismiss rude-edit prompt SourceFileUpdateTests.RenameSourceFile(useMove: False) intermittently hangs on Windows for 60 minutes (until the hang collector fires). Roslyn's EnC analyzer classifies the delete-of-Foo.cs + add-of-Renamed.cs (same class content) as a rude edit (ENC0033 `Deleting class 'Lib' requires restarting the application'') some of the time -- whether it does depends on file-watcher event timing (whether the delete and add events arrive close enough for Roslyn to coalesce them into a rename vs. seeing two separate edits). When the rude edit fires, dotnet-watch displays an interactive restart prompt because the test launches `dotnet watch -bl'' without --non-interactive, without DOTNET_WATCH_RESTART_ON_RUDE_EDIT, and without TestFlags.ReadKeyFromStdin. The prompt's RestartPrompt.WaitForRestartConfirmationAsync blocks reading stdin, the test process keeps printing `> Foo.cs'' forever, and AssertOutputLineStartsWith `> Renamed.cs'' times out. Observed twice on PR #54292: - Build 1423147: TestBuild win-x64, dotnet-watch.Tests.dll.11 - Build 1424609: FullFramework win-x64, dotnet-watch.Tests.dll.6 (Each run hits at most one of the two Windows legs because the test shards differently between TestBuild and FullFramework.) Fix: opt into TestFlags.ReadKeyFromStdin and send 'a' (always restart) after the rename. This matches the pattern used by AutoRestartTests, BrowserTests, AspireHotReloadTests, MauiHotReloadTests, etc., and unblocks the test whether Roslyn classifies the change as a rude edit or not. The underlying inconsistency in Roslyn's EnC classification is worth a separate investigation by @dotnet/roslyn-ide, but is not addressed here. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
These are test assets consumed at test time (packed into a NuGet package by tests), not build targets. Move them to
TestAssets/where they belong alongside other test-only content and inherit the existing build isolation provided byTestAssets/Directory.Build.props.The csproj now targets
netstandard2.0since it is a content-only template package with no build output.Changes
test/TemplateEngine/Microsoft.TemplateEngine.TestTemplates/totest/TestAssets/TestPackages/TemplateEngine/netstandard2.0(content-only, no build output)Tracking issue: dotnet/templating#10085