dotnet
xUnit Test Project (.NET Core) use the old project type GUID in the Solution file
Visual Studio Version: Microsoft Visual Studio Community 2019, Version 16.6.3
Summary: When creating a new project of type xUnit Test Project (.NET Core) C#, the project is added to the solution with the GUID FAE04EC0-301F-11D3-BF4B-00C04F79EFBC (legacy C#) instead of the new GUID 9A19103F-16F7-4668-BE54-9A1E7A4F7556 (SDK-style C#).
Steps to Reproduce:
-
Open Visual Studio 2019, Version 16.6.3
-
Create a new project of type
xUnit Test Project (.NET Core) C#with the nameProject1 -
Open the solution file (
.sln) on a text editor and notice that project is identified as being a legacy C# project
Expected Behavior:
MinimumVisualStudioVersion = 10.0.40219.1
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Project1", "Project1\Project1.csproj", "{9431EF13-2586-440E-B323-1145C81F6672}"
EndProject
Actual Behavior:
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Project1", "Project1\Project1.csproj", "{9431EF13-2586-440E-B323-1145C81F6672}"
EndProject
User Impact:
- Tooling incorrectly identify xUnit projects as being legacy C# projects instead of SDK-style projects
- Visual Studio 2019 has different behavior depending on the project type GUID (example)
- Visual Studio changes the GUID to
9A19103F-16F7-4668-BE54-9A1E7A4F7556at a later time (it's not clear exactly when) which creates changes in source control that are not related to the work being done at the time
This behaviour is intentional. Let's look at each of your user impact points in turn.
Tooling incorrectly identify xUnit projects as being legacy C# projects instead of SDK-style projects
I cannot reproduce this. Creating a new xUnit Test Project (.NET Core) loads in the new project system as expected:
That project has content:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<IsPackable>false</IsPackable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.5.0" />
<PackageReference Include="xunit" Version="2.4.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.0" />
<PackageReference Include="coverlet.collector" Version="1.2.0" />
</ItemGroup>
</Project>
Given it's SDK-style, it would not load in legacy. This is definitely loaded in the .NET Project System.
Visual Studio 2019 has different behavior depending on the project type GUID (example)
Projects that are registered in the solution with the legacy project-type GUID have their contents scanned to determine whether they use the SDK-style format or not. If so, the .NET Project System (the one in this repo) is used to load it.
The linked example appears to be related to importing the TargetFramework from another file. There have been improvements in that regard, but it has nothing to do with the GUID in the sln file. That GUID is only used when the project is first loaded.
Visual Studio changes the GUID to 9A19103F-16F7-4668-BE54-9A1E7A4F7556 at a later time (it's not clear exactly when) which creates changes in source control that are not related to the work being done at the time
I have not observed this personally, though would be interested in knowing more about this. If you are able to reproduce this behaviour we can investigate further.
Hey guys, I was able to confirm and reproduce the behavior of Visual Studio changing the ID. It happens when I add a new XUnit test project. Visual Studio seems to check all my packages in my solution file and it changes the GUID to 9A19103F-16F7-4668-BE54-9A1E7A4F7556.
I am not able to present any screenshots, because I can't share any information of my client. When you need it, let me know, I can try to find some time reproduce in a mock solution.
I am working on VS Enterprise 2019 version 16.7.0.
Yes it does, but I haven't tried it yet on different projects. I can try later this day and I will let you know.
I can repro it. The CSPROJ files load correctly in VS as if they are It loads fine in VS (16.9.2), but the sln file is wrong.
In this example, I've been coding in VS for a few hours and at some point, VS changed all the GUIDs to the new one. But for new projects (tried Class Library with .NET Standard 2.0 and XUnit with .NET Core 3.1), the old GUID is used.
I can repro it also, it causes significant issues like project not building, this is fragment from Test output:
Expected Behavior:
[04.01.2022 4:28:56.781 PM] Operation Dequeue : 'RunFromCodeLensOperation'
[04.01.2022 4:28:56.893 PM] Triggering build for 1 IProjectBasedTestContainers.
[04.01.2022 4:29:02.717 PM] No IBuildableTestContainers were found.
[04.01.2022 4:29:02.717 PM] Completed building containers.
[04.01.2022 4:29:02.717 PM] Start updating 1 containers.
[04.01.2022 4:29:02.718 PM] Updating container C:\Users\UserName\source\repos\ProjectName\ProjectNameTests\bin\Debug\net5.0\ProjectNameTests.dll.
[04.01.2022 4:29:02.719 PM] Completed updating containers.
[04.01.2022 4:29:02.742 PM] ========== Starting test run ==========
[04.01.2022 4:29:02.748 PM] Tests run settings for C:\Users\UserName\source\repos\ProjectName\ProjectNameTests\bin\Debug\net5.0\ProjectNameTests.dll:
<RunSettings>
<RunConfiguration>
<ResultsDirectory>C:\Users\UserName\source\repos\ProjectName\TestResults</ResultsDirectory>
<SolutionDirectory>C:\Users\UserName\source\repos\ProjectName\</SolutionDirectory>
<CollectSourceInformation>False</CollectSourceInformation>
</RunConfiguration>
</RunSettings>.
[04.01.2022 4:29:04.127 PM] Rejestrowanie diagnostyki TestHost w pliku: C:\Users\UserName\AppData\Local\Temp\TestPlatformLogs\5284_01_04_2022_16_28_28\logs.host.22-01-04_16-29-03_16305_6.txt
[04.01.2022 4:29:04.401 PM] [xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.3+1b45f5407b (64-bit .NET 5.0.13)
[04.01.2022 4:29:05.880 PM] [xUnit.net 00:00:01.51] Starting: ProjectNameTests
[04.01.2022 4:29:08.428 PM] [xUnit.net 00:00:04.03] Finished: ProjectNameTests
[04.01.2022 4:29:08.631 PM] ========== Test run finished: 1 Tests (1 Passed, 0 Failed, 0 Skipped) run in 4,1 sec ==========
Actual Behavior:
[04.01.2022 4:20:08.061 PM] Operation Dequeue : 'RunFromCodeLensOperation'
[04.01.2022 4:20:08.235 PM] Start building 1 containers.
[04.01.2022 4:20:08.235 PM] Triggering build for 1 IProjectBasedTestContainers.
[04.01.2022 4:20:08.236 PM] ProjectData: Could not find project with GUID 1234cda0-ae12-4f4b-88a0-21eef5b79824
[04.01.2022 4:20:08.236 PM] No IBuildableTestContainers were found.
[04.01.2022 4:20:08.236 PM] Completed building containers.
[04.01.2022 4:20:08.236 PM] Build or deployment failed.
[04.01.2022 4:20:08.236 PM] Skipping container updates since 'Projects and Solutions-> Build and Run-> On Run, when build or deployment errors occur:' is set to 'Do not launch'.
[04.01.2022 4:20:08.236 PM] Aborting test run due to build failures. Please see the build output for more details.
[04.01.2022 4:20:08.237 PM] You can change this default behavior by going to 'Tools -> Options -> Project and Solution -> Build and Run -> On Run, When build or deployment errors occur'
[04.01.2022 4:20:08.237 PM] Build failed or it was cancelled.
[04.01.2022 4:20:08.239 PM] DiscoveryOperation<RunFromCodeLensOperation> Changed container count is 0
[04.01.2022 4:20:56.664 PM] Log level is set to Trace (Includes Platform logs).
[04.01.2022 4:20:56.671 PM] Logging Test Platform diagnostic logs under 'C:\Users\UserName\AppData\Local\Temp\TestPlatformLogs\5284_01_04_2022_16_20_56'
[04.01.2022 4:21:01.996 PM] Interrupt: Enqueueing RunFromCodeLensOperation
[04.01.2022 4:21:01.996 PM] Enqueue operation 'RunFromCodeLensOperation', hashcode:56316885
[04.01.2022 4:21:01.997 PM] Operation left in the the queue: 1
[04.01.2022 4:21:01.997 PM] 'RunFromCodeLensOperation', hashcode:56316885
[04.01.2022 4:21:01.997 PM]
@augustoproiete thanks for reporting, it saved my time because Visual Studio doesn't prompt build error in traditional way.
Happened to me too yesterdy after adding an Xunit test project to my solution. VS 2022 v17.0.0, dotnet core 3.1
