search

3F / MvsSln

🧩 Customizable VisualStudio .sln parser with project support (.vcxproj, .csproj., …). Pluggable lightweight r/w handlers at runtime, and more …
MIT License
135 stars 27 forks source link

ProjectGuid is obsolete and cannot guarantee a unique project instance #18

Open 3F opened 4 years ago

3F commented 4 years ago

MS drops support of the ProjectGuid in their projects files. Means that some project files may not provide this at all. And as a result, it cannot guarantee a uniqueness on this basis anymore.

https://github.com/3F/DllExport/issues/36#issuecomment-320794498 https://github.com/3F/vsSolutionBuildEvent/issues/40

MvsSln still can provide a unique ProjectGuid because it uses data from .sln file and its project files.

However, it still will not guarantee a normal work with project instances through MBE.

Alternative is

Full path to project file is a unique identifier for today. Therefore, we need to review some parts of our code that was based on ProjectGuid when working with projects (some filters, collections, and so on).

DynConcepts commented 3 years ago

Any citation for the removal by Microsoft.... In the general sense, absolute path does not identify a unique project (i.e. the same project could be cloned into multiple repositories).

3F commented 3 years ago

Any citation for the removal by Microsoft....

Ask Claire Novotny (Microsoft employee; .NET Foundation Executive Director, and PM on the .NET Team) with whom I had a discussion in mentioned issue above.

In the general sense, absolute path does not identify a unique project (i.e. the same project could be cloned into multiple repositories).

What do you mean for "cloned into multiple repositories"? Please some example.

DynConcepts commented 3 years ago

Thanks. I will reach out to Claire (whom I already know) to see if the information has been published and available so I can easily refer people to authorized source...I know of much tooling that depends on these Guids...

As for Repos and Clones....

I could.... a) go to my C:\foo\A directory and do a "git clone https://github.com/3F/MvsSln" resulting in C:\foo\A\MvsSln... b) go to my C:\foo\B directory and do a "git clone https://github.com/3F/MvsSln" resulting in C:\foo\B\MvsSln...

Now there are two clones of the repository (this is the simplest, but there are many more realistic yet complex examples -- perhaps a .csproj file that is published as part of two different repositories - perhaps one on GitHub and also on Azure Devops)..

In any case, "C:\foo" will now contain 2 of every unique .csproj.... but they "couples" will not have the same full path...

3F commented 3 years ago

I see. But in fact your case represents exactly a unique project instances that we really need as a feature.

In any case, "C:\foo" will now contain 2 of every unique .csproj.... but they "couples" will not have the same full path...

This case, however, is slightly different (as I see it) from initial ProjectGuid feature (I will keep naming an original property as a feature) and completely identical to DllExport problem in the past. And this is how it was resolved https://github.com/3F/DllExport/blob/e9b20af53dc84814f1bb94d4ef52c9605b94122e/Wizard/Project.cs#L83 (this is your case too)

ProjectGuid (again in my opinion) just adds unnecessary complexity leading to possible errors (copy-paste etc.). But of course VS and MSBuild worlds are too different, here's example https://github.com/3F/MvsSln/issues/25#issuecomment-617956253