Sets the ProjectGuid on an MSBuild Project as well as attempts to fix any ProjectReferences and Solutions
In the MSBuild Project System, the ProjectGuid is expected to exist in each MSBuild Style Project. It is used in several places; most importantly:
- Any ProjectReference should contain the Project Guid (in the Project Tag)
- The ProjectGuid is used in the Visual Studio Solution File as a way to Reference the Project
As the name suggests (ProjectGuid) this is expected to be a Globally Unique IDentifier.
The tooling is so dependent upon this fact that, if you attempt to import two projects which have identical ProjectGuid into a Visual Studio Solution File, one will be chosen as the loser and its Guid Regenerated.
Duplication most often happens because a developer was attempting to use an existing project as a "template" for a new project.
There is nothing wrong with making a copy of an existing project, but when you do so you need to take special care to generate a new ProjectGuid tag.
You will want to use this tool if a Developer has duplicated a ProjectGuid across two distinct projects in your code base and you need to update one of these to be unique.
It is unclear what the "Microsoft Solution" is in this case, at very least, in Visual Studio, if you attempted to load in both of these projects at the same time one would be chosen as a "loser" and have its Guid Updated. Unfortunately because of the deep dependencies with Project References if you are in a deep dependency tree and not all of the projects were loaded into your Solution not everyone would get updated.
Therefore the better solution is to use this tooling.
To prevent this scenario in the future see the sister Tattler Project https://github.com/aolszowka/MsBuildDuplicateProjectGuid
This tool was written as a one off and because of the need to edit multiple mainline releases is slightly different than other fixers. Take a look at the Program.Main(string[]). I am open to suggestions as to how to make this tool more CLI driven in a source layout agnostic way.
This tool assumes that any project that would reference the GUID being changed exists in the targetDirectory.
This tool assumes that the project had been opened in Visual Studio at least once. The reason is that Visual Studio will not allow you to have a ProjectGuid duplicated and will automatically fix this when it is encountered.
Because of this fact this statement is assumed to hold true:
// HOWEVER we can use this to advantage, because you can never
// have two projects with identical GUIDS in a solution we can
// safely assume that once we've identified the Solution as
// containing our project we CAN perform a find a replace.There is no such guarantee if the project has not been opened by Visual Studio (IE if the Solution was generated by a tool that did not maintain that rule). A place for improvement in this tool would be to account for this possibility.
The most likely change you will want to make is changing the supported project files. In theory this tool should support any MSBuild Project Format that utilizes a ProjectGuid.
See SetProjectGuid.GetProjectsInDirectory(string) for the place to modify this.
As mentioned above in the assumptions it is assumed that the GUID is not duplicated in the project (it can however be the "incorrect" project).
For this take a look at SetProjectGuid.UpdateSolutionReferenceGuids(string,string,string,string) specifically paying attention to SetProjectGuid.ShouldUpdateSolution(string,string,string).
Pull requests and bug reports are welcomed so long as they are MIT Licensed.
This tool is MIT Licensed.