Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

How does project system determine if the project is ASPNET or generic C#? #3079

Closed
am11 opened this issue Dec 27, 2017 · 5 comments
Closed

How does project system determine if the project is ASPNET or generic C#? #3079

am11 opened this issue Dec 27, 2017 · 5 comments

Comments

@am11
Copy link
Member

am11 commented Dec 27, 2017 •
edited by drewnoakes
Loading

I noticed that sometimes modifying solution (add/remove project or solution item) causes my regular, non-web console app SDK-style projects to have 9A19103F-16F7-4668-BE54-9A1E7A4F7556 GUID in SLN, while the intended behavior is to keep the FAE04EC0-301F-11D3-BF4B-00C04F79EFBC GUID which was originally in sln file. This causes unintentional diffs in code checkins.

If VS is adding FAE04EC0-301F-11D3-BF4B-00C04F79EFBC on creating the .NET Core Console app and then changing it to 9A19103F-16F7-4668-BE54-9A1E7A4F7556 when modifying items in solution explorer, which GUID is expected and which one is incorrect? For variety, see #2891.

Is it correct that:

  • 9A19103F-16F7-4668-BE54-9A1E7A4F7556 is ASP.NET Core web application project GUID? (edit no, read below)
  • FAE04EC0-301F-11D3-BF4B-00C04F79EFBC is a generic C# project GUID, that is applicable to any csharp-y project and should be used in non-aspnet scenario? (edit no, read below)
    • If this is true and there is no benefit out of this specificity, can 9A19103F-16F7-4668-BE54-9A1E7A4F7556 be deprecated even for ASP.NET Core projects?

It seems if we have any ASP.NET Core package referenced in non-web, regular-console project, this alteration happens on modifying solution items in VS. To me it happened in a solution containing sfproj and a csproj, where csproj is SDK-style console app (targeting net462 TFM), referencing Microsoft.AspNetCore package. Perhaps the determination logic that deals with "Identification of ASP.NET project" needs a revisit?
@Pilchie
Copy link
Member

Pilchie commented Dec 27, 2017 •
edited by drewnoakes
Loading

See https://github.com/dotnet/project-system/blob/master/docs/opening-with-new-project-system.md. 9A19103F is the "new" project system guid, and FAE04EC0 is the "old" one. .NET Core apps should always be the 9A19103F guid, whether they are console apps or web.

@am11
Copy link
Member Author

am11 commented Dec 28, 2017

Thanks for the reference @Pilchie! I will use 9A19103F for new projects. 🎉

@am11 am11 closed this as completed Dec 28, 2017
@thusithagh
Copy link

@Pilchie appreciate if you can update the link as it is broken as of now.
Thank you.

@davkean
Copy link
Member

davkean commented Apr 20, 2018

New location is: https://github.com/dotnet/project-system/blob/master/docs/opening-with-new-project-system.md

@seangwright seangwright mentioned this issue Apr 28, 2018
Merged
@axdiamond axdiamond mentioned this issue Jun 28, 2018
Merged
@mishra14 mishra14 mentioned this issue Jul 12, 2018
Merged
mishra14 pushed a commit to NuGet/NuGet.Client that referenced this issue Jul 17, 2018
Refactoring ErrorList into NuGet.VisualStudio.Common (#2340)
4277fad 
Follow up to #2313

As requested by @nkolev92, I have refactored the code to move `ErrorListTableEntry.cs` and `ErrorListTableDataSource.cs` from `NuGet.SolutionRestoreManager` to `NuGet.VisualStudio.Common` and removed the dependency from `NuGet.Tools` to `NuGet.SolutionRestoreManager`

Also updating the guid for test projects based off of this [comment](dotnet/project-system#3079 (comment)).
jfoshee added a commit to Durwella/Durwella.Azure.ArmTesting that referenced this issue Oct 28, 2018
@jfoshee
Let VS update guid for project to 9a....
39e8847 
dotnet/project-system#3079
@MithrilMan MithrilMan mentioned this issue Dec 13, 2018
Merged
@WojciechNagorski WojciechNagorski mentioned this issue Dec 18, 2019
Merged
yvt added a commit to yvt/ngspades that referenced this issue Apr 25, 2020
@yvt
Update Nightingales.sln
ad9729e 
These changes were made automatically by Visual Studio.

- The project type GUID was replaced with the "modern" one which
  ".NET Core apps should always [have]"
  <dotnet/project-system#3079>.

- `HideSolutionNode` was set to `FALSE`, which is the default value for
  multi-project solutions.

- Other insignificant changes.
@maxkatz6 maxkatz6 mentioned this issue May 26, 2020
Merged
@danjagnow danjagnow mentioned this issue Jul 19, 2020
Merged
dahlia added a commit to dahlia/libplanet that referenced this issue Oct 7, 2020
@dahlia
Migrate to MSBuild new project system
880d7ac 
dotnet/project-system#3079 (comment)

[changelog skip]
dahlia added a commit to dahlia/libplanet that referenced this issue Oct 13, 2020
@dahlia
Migrate to MSBuild new project system
95f42bb 
dotnet/project-system#3079 (comment)

[changelog skip]
dahlia added a commit to dahlia/libplanet that referenced this issue Oct 14, 2020
@dahlia
Migrate to MSBuild new project system
ea35d3e 
dotnet/project-system#3079 (comment)

[changelog skip]
dahlia added a commit to dahlia/libplanet that referenced this issue Oct 15, 2020
@dahlia
Migrate to MSBuild new project system
add15ee 
dotnet/project-system#3079 (comment)

[changelog skip]
dahlia added a commit to dahlia/libplanet that referenced this issue Oct 15, 2020
@dahlia
Migrate to MSBuild new project system
7f294ae 
dotnet/project-system#3079 (comment)

[changelog skip]
datadiode added a commit to datadiode/toxy that referenced this issue Mar 7, 2021
@datadiode
*.sln: dotnet/project-system#3079
6e4d468
leohemsted added a commit to alphagov/notifications-net-client that referenced this issue Mar 19, 2021
@leohemsted
regenerate sln file
762302b 
The sln file tells dotnet what projects exist within the repo.
Regenerate this by removing the old file, and then running the following

This was generated using the following steps:

```
dotnet new sln --name GovukNotify
dotnet sln add src/GovukNotify
dotnet sln add src/GovukNotify.Tests
```

Note: The Project Type GUIDS (`Project("{xxxx}")` in the sln file)
values have changed as a result of regenerating the file. The new GUID
values (FAE04EC0...) appear to be GUIDs that represent older project
types vs the prev one (9A19103F...). However, our csproj files specify
precisely how to open the project files, so changing the GUID shouldn't
affect building/running tests/releasing the notify client.

The following links were helpful in understanding what was going on:

* dotnet/project-system#3079
* https://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs
* https://github.com/dotnet/project-system/blob/main/docs/opening-with-new-project-system.md#project-type-guids
leohemsted added a commit to alphagov/notifications-net-client that referenced this issue Mar 19, 2021
@leohemsted
regenerate sln file
4c18417 
The sln file tells dotnet what projects exist within the repo.
Regenerate this by removing the old file, and then running the following

This was generated using the following steps:

```
dotnet new sln --name GovukNotify
dotnet sln add src/GovukNotify
dotnet sln add src/GovukNotify.Tests
```

Note: The Project Type GUIDS (`Project("{xxxx}")` in the sln file)
values have changed as a result of regenerating the file. The new GUID
values (FAE04EC0...) appear to be GUIDs that represent older project
types vs the prev one (9A19103F...). However, our csproj files specify
precisely how to open the project files, so changing the GUID shouldn't
affect building/running tests/releasing the notify client.

The following links were helpful in understanding what was going on:

* dotnet/project-system#3079
* https://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs
* https://github.com/dotnet/project-system/blob/main/docs/opening-with-new-project-system.md#project-type-guids
leohemsted added a commit to alphagov/notifications-net-client that referenced this issue Mar 19, 2021
@leohemsted
regenerate sln file
d4aef54 
The sln file tells dotnet what projects exist within the repo.
Regenerate this by removing the old file, and then running the following

This was generated using the following steps:

```
dotnet new sln --name GovukNotify
dotnet sln add src/GovukNotify
dotnet sln add src/GovukNotify.Tests
```

Note: The Project Type GUIDS (`Project("{xxxx}")` in the sln file)
values have changed as a result of regenerating the file. The new GUID
values (FAE04EC0...) appear to be GUIDs that represent older project
types vs the prev one (9A19103F...). However, our csproj files specify
precisely how to open the project files, so changing the GUID shouldn't
affect building/running tests/releasing the notify client.

The following links were helpful in understanding what was going on:

* dotnet/project-system#3079
* https://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs
* https://github.com/dotnet/project-system/blob/main/docs/opening-with-new-project-system.md#project-type-guids
leohemsted added a commit to alphagov/notifications-net-client that referenced this issue Mar 19, 2021
@leohemsted
regenerate sln file
92ff78d 
The sln file tells dotnet what projects exist within the repo.
Regenerate this by removing the old file, and then running the following

This was generated using the following steps:

```
dotnet new sln --name GovukNotify
dotnet sln add src/GovukNotify
dotnet sln add src/GovukNotify.Tests
```

Note: The Project Type GUIDS (`Project("{xxxx}")` in the sln file)
values have changed as a result of regenerating the file. The new GUID
values (FAE04EC0...) appear to be GUIDs that represent older project
types vs the prev one (9A19103F...). However, our csproj files specify
precisely how to open the project files, so changing the GUID shouldn't
affect building/running tests/releasing the notify client.

The following links were helpful in understanding what was going on:

* dotnet/project-system#3079
* https://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs
* https://github.com/dotnet/project-system/blob/main/docs/opening-with-new-project-system.md#project-type-guids
leohemsted added a commit to alphagov/notifications-net-client that referenced this issue Mar 19, 2021
@leohemsted
regenerate sln file
58027d0 
The sln file tells dotnet what projects exist within the repo.
Regenerate this by removing the old file, and then running the following

This was generated using the following steps:

```
dotnet new sln --name GovukNotify
dotnet sln add src/GovukNotify
dotnet sln add src/GovukNotify.Tests
```

Note: The Project Type GUIDS (`Project("{xxxx}")` in the sln file)
values have changed as a result of regenerating the file. The new GUID
values (FAE04EC0...) appear to be GUIDs that represent older project
types vs the prev one (9A19103F...). However, our csproj files specify
precisely how to open the project files, so changing the GUID shouldn't
affect building/running tests/releasing the notify client.

The following links were helpful in understanding what was going on:

* dotnet/project-system#3079
* https://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs
* https://github.com/dotnet/project-system/blob/main/docs/opening-with-new-project-system.md#project-type-guids
leohemsted added a commit to alphagov/notifications-net-client that referenced this issue Mar 19, 2021
@leohemsted
regenerate sln file
d1e61de 
The sln file tells dotnet what projects exist within the repo.
Regenerate this by removing the old file, and then running the following

This was generated using the following steps:

```
dotnet new sln --name GovukNotify
dotnet sln add src/GovukNotify
dotnet sln add src/GovukNotify.Tests
```

Note: The Project Type GUIDS (`Project("{xxxx}")` in the sln file)
values have changed as a result of regenerating the file. The new GUID
values (FAE04EC0...) appear to be GUIDs that represent older project
types vs the prev one (9A19103F...). However, our csproj files specify
precisely how to open the project files, so changing the GUID shouldn't
affect building/running tests/releasing the notify client.

The following links were helpful in understanding what was going on:

* dotnet/project-system#3079
* https://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs
* https://github.com/dotnet/project-system/blob/main/docs/opening-with-new-project-system.md#project-type-guids
@atifaziz atifaziz mentioned this issue Mar 31, 2021
Merged
database64128 added a commit to database64128/shadowsocks-uri-generator that referenced this issue Jun 16, 2021
@database64128
🤥 Project type GUID nonsense
c9d1014 
- dotnet/project-system#1821
- dotnet/project-system#3079
@pellared pellared mentioned this issue Jun 24, 2021
Merged
@eiriktsarpalis eiriktsarpalis mentioned this issue Jul 13, 2021
Merged
@TysonMN TysonMN mentioned this issue Aug 15, 2021
Merged
jasonsparc pushed a commit to srskokoro/srskokoro-maui that referenced this issue Mar 18, 2022
@netaneru
Fix: should use new project type GUID
860b1aa 
See, dotnet/project-system#3079
@0liver 0liver mentioned this issue Jul 27, 2022
Merged
ronaldvanmanen added a commit to ronaldvanmanen/SDL2Sharp that referenced this issue Sep 25, 2022
@ronaldvanmanen
Project system GUID of SwirlStars sample was changed by Visual Studio…
6f03c80 
… to the new project system GUID.

See dotnet/project-system#3079
ronaldvanmanen added a commit to ronaldvanmanen/SDL2Sharp that referenced this issue Dec 19, 2022
@ronaldvanmanen
Project system GUID of SwirlStars sample was changed by Visual Studio…
4b51367 
… to the new project system GUID.

See dotnet/project-system#3079
@Regenhardt Regenhardt mentioned this issue Mar 8, 2023
Merged
@dtivel dtivel mentioned this issue Jul 17, 2023
Merged
@JeppeSN
Copy link

JeppeSN commented Sep 1, 2023

A list of project types including 9A19103F and FAE04EC0 and many others, can be found at /JamesW75/visual-studio-project-type-guid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@Pilchie @davkean @am11 @thusithagh @JeppeSN