Slngen does not support including multiple projects with the same name

[anladwig]

While it's understood that having multiple projects in the same repo with the same name is bad practice, it happens :). VS does allow this if the projects are in different solution folders, such as in this example:

Slngen should detect same-name projects and put them in different solution folders. It currently creates a solution that gives errors like the following upon opening:

Which means that VS cannot load every project:

As a workaround, users can use the --folders flag to generate a solution with a hierarchical folder structure:

slngen --folders true

However, I would argue that it should be able to detect and correct duplicate project names in flat mode too.

[jeffkl]

I guess the question is how to handle the situation in your opinion?

1. Error out and tell the user to use --folders true
2. Keep a running list of projects that collide and warn the user that solution folders are going to be used for every project just as if they had specified --folders true
3. Keep a running list of projects that collide and then have some methodology to generate solution folders for just the affected projects
4. Other suggestions?

# 1 would be the easiest obviously. # 2 wouldn't be too bad, my only concern is keeping the list of project names to detect collisions might slow the tool down for large solutions. For # 3 I'd be open to suggestions for what logic the tool could use to generate folders that made sense. We wouldn't want them to be very deep since they'd be the only projects in folders. What folder structure would you propose? Any other suggestions I'm missing?

[anladwig]

This is a good set of options. Specifically, I was thinking that option # 3 might be the most expected and least invasive. I would imagine this implemented as keeping a running list of duplicates and then creating a root-level, single-depth folder for each duplicate found. The naming could be as simple as following the windows pattern for dupes: Common, Common (2), Common (3) ...etc. Or something like Common-1, Common-2, Common-3. It seems like using the project name in the folders is the safest way to ensure that the folders themselves don't also run into duplicate naming issues.

[jeffkl]

I'm open to the functionality. What happens in Visual Studio today if you already have a project named Common and try to add another with the same name?