Msbuild: Documentation For ProjectGuid?

[aolszowka]

The ProjectGuid tag is pretty important in the MSBuild Ecosystem and as the name suggests should not be duplicated.

However I am unable to find documentation that describes just exactly how this is used.

At very least I know it is used when you create a ProjectReference Tag (and is documented here https://docs.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-items?view=vs-2017#projectreference) and when you create a Solution File in Visual Studio (the Project Guid is extracted and then kept in the SLN file) that is not as well documented but you see some inklings here: https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualstudio.workspace.extensions.msbuild.projectinsolution.projectguid?view=visualstudiosdk-2017).

Can someone point me in the right direction? If its not documented, who should I forward a request to?

[livarcocc]

@davkean do we have documentation for this?

[rainersigwald]

MSBuild itself has never cared about it, but VS has to varying degrees.

My (weak) understanding is that it's optional in most cases now. In the new project system I think (hope) it's ignored. I don't know if csproj still pays attention to it.

[davkean]

The project GUID in the solution is a unique identifier of a project across the solution _inside_ VS. In non-SDK-based projects, it's a required element that must be present in the project, and if not, will re-added the first time you open the project in Visual Studio. If it is not unique in a solution, VS will also make changes to the project/solution and any other reference to it to make it unique.

In the new project-system, we no longer require ProjectGuid to be present in the project. It is still present in the solution.

[aolszowka]

@davkean Can you expand upon this last line?

In the new project-system, we no longer require ProjectGuid to be present in the project. It is still present in the solution.

We have several tools that generate solution files due our our deep dependency tree (3,500+ MSBuild Project System Style Files) which would be impossible to maintain via the tooling (at least in any consistent manner). If this Guid is gone how does Visual Studio determine the Guid to Insert in the Solution? Much of the tooling blasts away any existing Solution File and regenerates from the N-Order Dependencies (as that is the safest thing to do) but because the solution file format is idempotent we can pretty safely perform this operation and not get a bunch of Version Control File Modified issues.

While I have your attention, is there any supported Solution API? We've rolled just about everything by hand and used the lightly documented Solution Class which probably means we are doing something wrong.

[aolszowka]

@davkean Sorry to ping you again; but if you wouldn't mind addressing the above; then I would be happy to close this issue out.

[drewnoakes]

@aolszowka I'm no authority on the topic, but if you want your tooling to generate the same GUID for your projects when those projects don't contain project GUIDs themselves, you'll need to either remember the existing GUID before overwriting the solution file, or generate one from something stable, such as the project path using a hashing algorithm, for example.

[aolszowka]

@drewnoakes The Projects currently contain the GUIDs (ProjectGuid); the concern is that the discussion here mentioned that this tag ProjectGuid is deprecated in the new project system. I am simply asking how the configurations are managed then in a solution world going forward.

[drewnoakes]

@aolszowka it's true that ProjectGuid is not needed in the new project system. What I wrote still applies. The solution knows the GUIDs, but the projects don't.

[Larswa]

I know this is an old thread, but I just had the same question. so .. for reference. After arriving here first, I found the answer here. https://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs

[davkean]

@Larswa That is ProjectTypeGuids not ProjectGuid.

ProjectGuid is a unique identifier of a project within a solution. In SDK-based projects, the solution is the only thing that is aware of the project GUID - there was no need to duplicate it in the project. If the project GUID is missing from the solution (in the Add/New project case) or clashes with another project, then the solution will generate a new unqiue GUID.

I think this has answered the quesation, and will close out. If not, ping again and I'll reopen.