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

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

Open
3F opened this issue Aug 4, 2019 · 4 comments
Open

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

3F opened this issue Aug 4, 2019 · 4 comments
Labels
3rd-party env Active environment and its .vcxproj, .csproj, ... support support

Comments

@3F
Copy link
Owner

3F commented Aug 4, 2019

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.

3F/DllExport#36 (comment)
3F/vsSolutionBuildEvent#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).
@3F 3F added 3rd-party support env Active environment and its .vcxproj, .csproj, ... support labels Aug 4, 2019
@3F 3F mentioned this issue Aug 4, 2019
Closed
3F added a commit that referenced this issue Aug 10, 2019
@3F
Public release of the MvsSln 2.4
a3694d5 
* FIXED: "The format ... of configuration is not supported". Issue #19.

* FIXED: Fixed loading of projects via `IsolatedEnv.LoadProjects()`.

* FIXED: Fixed possible NullReferenceException in `ProjectItem` constructors.

* NEW: Introduces XProjectEnv. PR #17.
       An splitted IsolatedEnv as the base but without IDisposable.
    ```
    IXProjectEnv slnEnv;
    ...
    slnEnv = new XProjectEnv(sln, properties);
    ...
    slnEnv = new IsolatedEnv(sln); // +IEnvironment, +IDisposable
    slnEnv.Assign();
    ...
    ((IDisposable)slnEnv)?.Dispose();
    ```

* NEW: Added `PropertyNames` type. Regular MSBuild Properties and related.

* NEW: Added `FileExt` type for work with `ProjectType` via its file only.

* NEW: Added `Kinds` type: PRJ_UNLOADED; PRJ_SLN_DIR

* NEW: New extension methods:
    ```
    +TVal GetOrDefault<TKey, TVal>(this IDictionary<TKey, TVal> data, TKey key, TVal def)
    +bool IsEqual(this Project a, Project b)
    +string GetSolutionDir(this Project eProject)
    +string GetProjectRelativePath(this Project eProject)
    +string GetConfig(this Project eProject)
    +string GetPlatform(this Project eProject)
    +string GetSolutionExt(this Project eProject)
    string GetDirectoryFromFile(this string file)
    Dictionary<string, string> GetFileProperties(this string file)
    IDictionary<string, string> AddOrUpdate(this IDictionary<string, string> source, IDictionary<string, string> items)
    bool Remove<T>(this IList<T> src, T elem, Func<T, T, bool> comparer)
    bool IsLimEqual(this IXProject x, IXProject prj)
    ```

* CHANGED: Removed pGuid checking from `IXProjectEnv.GetOrLoadProject()`
           Related to Issue #18.

* CHANGED: ISlnResult changes:
    ```
    +`string SolutionFile`
        Full path to an solution file.
        Old versions still can address it through Properties.
    ```

* CHANGED: IConfPlatform changes:
    ```
    +`bool IsEqualByRule(string config, string platform, bool icase = false);`
        Checking an config/platform by using {Rule} instance.
    ```

* CHANGED: IXProjectEnv (IEnvironment) changes:
    ```
    +`IXProject XProjectByFile(...);`
        Find project by full path to file.

    +`IEnumerable<IXProject> Assign(IEnumerable<Project> projects = null);`
        Assign an existing `Microsoft.Build.Evaluation.Project` instances for local collection.

    +`IXProject AddOrGet(Project project);`
        Adds `Microsoft.Build.Evaluation.Project` instance into IXProject collection if it does not exist.

    +`ProjectItemCfg ExtractItemCfg(Project project);`
        Prepares data from `Microsoft.Build.Evaluation.Project` instance.

    +`void UnloadAll(bool throwIfErr = true);`
        Unloads all evaluated projects at current time.

    +`bool Unload(IXProject xp);`
        Unloads specified project.

    +`IEnumerable<Project> ValidProjects`
        List of valid projects such as something except `.user`,`.metaproj` but contains FirstChild / LastChild XML node.
    ```

* CHANGED: Updated package's tool hMSBuild 2.2

           Release notes:
           https://github.com/3F/hMSBuild/releases/tag/v2.2

* NOTE: The most 2.4 changes is relevant to integration with vsSolutionBuildEvent.

        https://twitter.com/GitHub3F/status/1158091930309398528
        3F/vsSolutionBuildEvent#53
        #17

        Find any relevant use of the new features in that project.
This was referenced May 3, 2020
Closed
Merged
@DynConcepts
Copy link

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
Copy link
Owner Author

3F commented Dec 14, 2020

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
Copy link

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
Copy link
Owner Author

3F commented Dec 15, 2020

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 #25 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
3rd-party env Active environment and its .vcxproj, .csproj, ... support support
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@3F @DynConcepts