Vagif Abilov's blog on .NET

Utility to generate solution files can now create solution folders

If somebody wants more from the program you wrote, it’s a good sign. It means that at last you did something useful :-)

Recently my colleague mentioned that the utility that I wrote to generate project solution file should support creation of solution folders. Our development team has in total more than 200 projects, and grouping them within the solution makes a lot of sense.

So I extended the tool, and you can specify number of solution folder levels using “/l” command line switch.

GenerateSolutionFile /p <path> /s <solution> [/i includeFilter] [/e excludeFilter] [/l [*]solutionFolderLevels]

You can specify solution folder levels using an integer number – project names will be split using “.” as separator, and resulting words will be used as solution folder names. Since it’s a good practice to start project name with a name of the company that won’t be useful as a solution folder, it’s possible to skip common project prefix by using an asterisk letter in front of the number specifying the number of levels.

Here are a few examples. If you generate solution file without instructing the tool to create solution folders, you will get a flat structure of projects:

Folders1

If you add a command line switch “/l 1”, then the program will extract a first word from compound project names and create a root solution folder:

Folders2

You can add number of levels with “/l 2” switch:

Folders3

To skip “MyCompany” from solution folder tree add an asterisk when specifying number of folder levels: “/l *1”:

Folders4

And of course you can increase number of levels, here’s how it looks when using “/l *2” switch:

Folders5

Enjoy!

Posted: Thu, Dec 3 2009 11:10 AM by Vagif Abilov | with 14 comment(s)
Filed under: , , ,

Comments

Filip Hammerstad said:

Nice utility.

One thought comes to mind though: wouldn't this make a good candidate for a Visual Studio Addin instead of/in addtion to a being a console application?

# December 23, 2009 8:47 AM

Vagif Abilov said:

Filip,

Probably yes. Or maybe it can be a template that can be used when people create projects or solutions. In addition to creating a new solution have a choice "Import solution" or "Create solution from folders".

Good idea, I'll investigate how this can be done.

# December 23, 2009 9:50 AM

Allen Sanborn said:

Thanks for sln folder feature. I was just about to sit down and implement that. :)

# January 7, 2010 10:40 PM

Mark said:

Hi, just to make sure. The utility does not analyze the project references to translate them into project dependencies in the final sln file, does it?

Thanks.

# February 12, 2010 11:06 PM

Vagif Abilov said:

Mark. No it doesn't and it shouldn't. Project dependencies are stored in project manifests. If you open any solution file, you will only see a list of projects, not what they reference (it may also contain source control binding information). A solution file is simply a collection of projects.

# February 13, 2010 5:25 AM

Mark said:

Hi Vagif.

I will explain myself. Our projects are not part of ASP.NET application, but rather console/rich client. We do not use project references, rather DLL references. The reason - there are many projects and people tend to create smaller sub-solutions with only a small subset of projects.

Anyway, because the references are to DLL, Visual Studio does not automatically defines build dependencies, meaning developers must define them manually. These dependencies are recorded in the solution file (see ProjectSection(ProjectDependencies) in a solution file). It is tedious and error prone to keep these dependencies up-to-date. It is annoying too, because they map one-to-one onto the project references, but again VS does not deduce the dependencies when the references are not project references, as in our case.

So, I am looking for a tool to recreate solution from projects, which would also recreate the build dependencies by analyzing the project references.

I hope I have explained myself more clearly now.

Thanks.

# February 14, 2010 10:55 PM

Vagif Abilov said:

Mark,

Can you mail me an example of your solution file. Without project files of course - just an SLN file. I will look into it.

You can mail it at vagif dot abilov at gmail dot com.

# February 16, 2010 10:41 PM

Vagif Abilov's blog on .NET said:

I installed to today the latest version of NDepend and gave it a try. Last time I blogged about NDepend

# March 11, 2010 11:20 PM

Vagif Abilov's blog on .NET said:

I am currently working on a next version of a utility to generate Visual Studio solutions . A new version

# April 19, 2010 8:47 PM

Tony OHagan said:

Thanks for this tool.

Feature wish:

* Computes projects dependencies based on project and DLL references.

Reason: Project references are the primary information source for determining project dependencies (ignoring dynamic loading of DLLs). I want to be able generate solution files and then use them to maintain subsets of out large code base (300+ projects) and be assured that I can auto build dependent projects inside VS.NET.

# March 21, 2012 7:39 AM

Vagif Abilov said:

Hi Tony,

I am working on a next version of the tool. Can you give a short example of a solution structure that you would need?

Vagif

# March 21, 2012 10:03 AM

Vagif Abilov's blog on .NET said:

A couple of years ago I wrote a utility that could scan directories and generate solution files (I blogged

# March 31, 2012 2:00 PM

Tony OHagan said:

> I am working on a next version of the tool. Can you give a short example of a solution structure that you would need?

Sorry for my delay in replying Vagif ...

The basic idea was:

Step 1. Build a dependency graph based on the existing DLL  and project references from the project files.  (Import phase)

Projects references can be:

   (a) Other projects

   (b) DLL or EXE (Note: A .EXE can be treated as a DLL)

   (c) Web service reference

      (perhaps defer for a future release if it's trickier)

Note: In addition to normal project references, when the *output* of a project is a DLL/EXE then it can become an *input* dependency for another project if the project references that DLL. We frequently do this in our coding shop instead of having project references due to the very large number of projects and the need to build them independently.

Step 2. Reduce the dependency graph by removing redundant dependencies:

  If A -> B -> C then A -> C can be removed

This step should be optional (checkbox or command line option).

Step 3. Report Cyclic dependencies (VS.NET may report this for you - I've not check this)

  A -> B -> C  and C -> A !

Step 4. Generate a solution file containing the project build dependency rules.

You can possibly use quickgraph.codeplex.com to implement some of this.  

Steps 2

 en.wikipedia.org/.../Transitive_reduction - I think this what you really want. QuickGraph does support Topological Sorting (close but "no cigar").

Step 3

 See Strongly Connected Components algorithm:

   quickgraph.codeplex.comdocumentation

Tony.

# April 3, 2012 3:12 AM

Vagif Abilov said:

Hi Tony, and sorry for a delay with my reply.

Can you give me some brief example of a solution and what would be an output of the tool. I must say I am still not sure that what you're suggesting is applicable to Solution Maker that is just a tool to generate SLN files. It scans projects, optionally find recursive dependencies but also on project file level. So perhaps if you take an example from your practice: a set of projects, referenced DLLs etc. and indicate what would be the resulting solution for them, I can understand better what can be improved in Solution Maker that I plan to keep matching its name: a solution file generation utility.

Best regards

Vagif

# April 27, 2012 8:20 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Please add 8 and 1 and type the answer here: