Remove GUIDs from project files and references

davkean commented 8 years ago

GUIDs are extremely unfriendly, and are only used for Visual Studio purposes. As we move the project file to a human editable file format, we should avoid using them.

There are three main ones today:

ProjectGuid property

<ProjectGuid>{8123135E-B2A1-4CD1-9658-DDACABEAB8FC}</ProjectGuid>

This is used as unique key of a project within a solution. First approach of removal should be to move this to an in-memory and solution-only concept.

Project metadata

    <ProjectReference Include="..\Microsoft.VisualStudio.ProjectSystem.Managed\Microsoft.VisualStudio.ProjectSystem.Managed.csproj">
      <Project>{6c6a41ce-72c5-4d77-8208-d01693f9bc88}</Project>
      <Name>Microsoft.VisualStudio.ProjectSystem.Managed</Name>
    </ProjectReference>

Used by csproj/msvbprj to find the hierarchy of the project, introduced in VS 2010 release. I can't find the history, but it appears that it may have been persisted so that if a project is renamed underneath the project (for example, if it was unloaded, or in a different solution), it can continue to find the old project.

CPS does not persist this today - so no work to do here.

ProjectTypeGuids property

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

Used to indicate the project factories that should be used to open a project inside Visual Studio.

CPS completely removes the need for this, and this can be safely removed for projects that have opt'd into CPS.

Work required to pull this off:

[x] Remove ProjectTypeGuids (CPS doesn't have this concept)
[x] Verify that CPS doesn't persist <Project> metadata under a <ProjectReference>
[x] Verify that if you open a project that doesn't have a GUID, that it reuses the same GUID already persisted in the solution, and does not generate a new one.
[x] Stop CPS from persisting the <ProjectGuid>
- We should do this in a manner that means if we already have a GUID, we should continue to persist it/change it if the solution pushes us a new value so that it doesn't get out of sync.

davkean commented 8 years ago

Okay, did some investigation, for this, I think we should write a custom IProjectPropertiesProvider that handles the ProjectGuid property, that itself reads from a property that reads from the ProjectFile. We choose to delegate down to that property on Set based on whether it already has a GUID.

natidea commented 8 years ago

If the solution tries to push the project guid to the project, do not write it. (But if the project file already has a guid, leave it there.)

davidfowl commented 8 years ago

👏

citizenmatt commented 8 years ago

What's the replacement for ProjectTypeGuids? ReSharper currently uses this to enable certain functionality (e.g. if it's a web application, and so on). How would ReSharper do this in the CPS world?

davkean commented 8 years ago

@citizenmatt The replacement for ProjectTypeGuids is a concept called "project capabilities", web, for example, will have a special well-known capability that lights up the web tooling. ReSharper can use the same markers to light up their tooling.

citizenmatt commented 8 years ago

Ah, yes. We're already using project capabilities for shared project support in VS2015. Is there a plan to have the capability names documented somewhere?

davkean commented 8 years ago

We've started documenting them here: https://github.com/Microsoft/VSProjectSystem/blob/master/doc/overview/project_capabilities.md.

dotnet / project-system