aolszowka/msbuildduplicateprojectguid

Utility to find duplicated MsBuild Project GUIDs

MsBuildDuplicateProjectGuid

Utility to find duplicated MsBuild Project GUIDs

Background

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)
  • Microsoft Docs: Common MSBuild Project Items - ProjectReference
• The ProjectGuid is used in the Visual Studio Solution File as a way to Reference the Project
  • Microsoft Docs: ProjectInSolution.ProjectGuid Property

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.

When To Use This Tool

This tool will help you identify projects (within a subfolder) that are not "Globally Unique".

However, this tool does not attempt to make corrections. In order to do so look at https://github.com/aolszowka/MsBuildSetProjectGuid

Usage

There are now two ways to run this tool:

1. (Compiled Executable) Invoke the tool via MsBuildDuplicateProjectGuid.exe and pass the arguments.
2. (Dotnet Tool) Install this tool using the following command dotnet tool install MsBuildDuplicateProjectGuid (assuming that you have the nuget package in your feed) then invoke it via dotnet duplicate-projectguid

In both cases the flags are identical to the tooling.

Usage: C:\DirectoryWithProjects

Scans given directory for MsBuild Projects; reporting any duplicate ProjectGuids
it finds.

Arguments:

              <>             The directory to scan for MSBuild Projects
      --xml                  Produce Output in XML Format
  -?, -h, --help             Show this message and exit

Hacking

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. This means that .NET Core Projects will not work out of the box.

See MsBuildDuplicateProjectGuid.GetProjectsInDirectory(string) for the place to modify this.

To assist in testing the dotnet tool version of this tool there is a batch file in build\Update-Package.bat that will attempt to clean up your NuGet Package Cache (in Windows) and re-install the tool as a local tool.

Contributing

Pull requests and bug reports are welcomed so long as they are MIT Licensed.

License

This tool is MIT Licensed.

Third Party Licenses

This project uses other open source contributions see LICENSES.md for a comprehensive listing.

msbuildduplicateprojectguid's Issues

Request: Utilize NDesk.Options For Options Parsing

tl;dr; Use http://www.ndesk.org/Options to perform our options parsing. Its MIT Licensed which is compatible with the license of this project and is extremely lightweight.

Currently we do a bunch of manual options parsing, however this makes it difficult to extend this program by forcing us to deal with command line parsing which isn't our goal. Rather we should spin this out into a library.

There are lots of options parsing libraries available to us, for example Microsoft provides https://github.com/dotnet/command-line-api. However if you look at the number of dependencies that has to carry around you nope out of that pretty quickly.

Rather I am going to suggest we use NDesk.Options for parsing, its a super lightweight dependency (just a single CS file), the usage is very straight forward, and is MIT Licensed.

The only downsides I can see is that it is not actively maintained (last updated back in 2008) and has some pretty gnarly LINQ in it to perform its magic. This probably means that there are some corner cases but at this point its better than rolling our own.

Request: Convert to .NET Core

Convert this project to .NET Core

The reason is I would like to try and ship these tools as a .NET Core Tool (https://docs.microsoft.com/en-us/dotnet/core/tools/global-tools-how-to-create)

Request: Optionally Create XML Output

Optionally this program should output its results in XML

Allow the CI to Publish This Package

In Creating #11 I forgot to uncommented out the actual code that publishes the package.

Resync editorconfig to Latest

Right now I have multiple editorconfigs across all these tools projects, resync this up to the latest version.

Request: Enable GitHub Actions

It would be nice if we had a CI Process around this that built the project as well as packaged it for distribution via dotnet tool

Request: Create a gitignore

These repositories should be standardized