Tobi + C# = T#

... why 260 chars really is not that much.

Have you ever seen this error message, while starting a new project?

"The length of the full path for the solution, project or item you are creating exceeds the maximum path length allowed by the system. You must reduce the length of the name or the location."

I remember sitting in front of my first Win95 installation, wondering how they did that damn thing with the long filenames. And what a waste. 8.3 was enough. So I started naming all my new word documents something totally silly. Like "The Abstract Reflection Regarding Catcher In The Rye After Careful Consideration Disregarded.doc", or something similar in German. And I thought, wow, that's just 97 chars. 260 chars will last me forever! Little did I know...

A source of constant tweaking

How could it possibly be that 260 chars are not enough? Surprisingly 260 chars get used up surprisingly quickly when creating solutions in Visual Studio. Let's look at the default structure Visual Studio creates for me when I create a new solution:

<solution name>
               \_
                 <solution name>.sln
                 <solution name>
                                \_
                                  <solution name>.csproj
                                  Class1.cs
                                  ...
                                  bin
                                     \_
                                       Release
                                              \_
                                                <solution name>.dll
                                                <solution name>.pdb

(I hearts me ascii drawing)

That means a solution to create the dll "Com.Hertkorn.Framework.SampleFramework.dll" will result in a total path named:
C:\test\Com.Hertkorn.Framework.SampleFramework\Com.Hertkorn.Framework.SampleFramework\bin\
Release\Com.Hertkorn.Framework.SampleFramework.dll

That's a whopping 139 chars!

Hmm. Actually it seems as if the above error gets displayed at a total path name length of about 199 chars. Oh, well. Who cares what the actual number is. I guess the programmers of Visual Studio played it save and allowed for some leeway. Anyway, so we see, using the default strategy, Visual Studio creates a lot of file path bloat - which results in an obstacle, because it does limit the way we name dlls, which is directly connected with the default namespace, etc. and the way we structure the global structure of our subversion.
So the desire to have nice dll names and namespaces plus still being able to create deep directory structures creates, at least for me, a source of constant tweaking. Because either I create a solution with a short name and modify the namespace and dll name to represent the long name, or I start with the long name and shorten the subdirectories. Either way, it's an additional step that I would like to eliminate. And don't get me started on adding new projects to a solution.

What I currently do by hand are the following steps:

• I create a solution using the full name of the target dll name in a test folder.
• Close the solution.
• Rename subdirectories to use a short name, usually removing redundant information.
• Move the directory tree into my svn tree.
• Reopen the solution.
• Fix the paths to the projects.
• Reload the projects.
• If necessary tweak the namespaces.

That certainly is a number of steps that I can automate.

What we need to automate these steps

A tool automating these steps needs

• The name of the target dll (full project description name).
• The name of the target namespace.
• The short name for the directory.
• The filepath of the directory, where the solution structure will get created.
• The information if both a solution and a project should get created, or if the newly created project should get attached to an existing solution.

Now we can create a structure like this:

c:\dev\Projects\Com.Hertkorn.Framework\
<short name>
            \_
              <full project description name>.sln
              <short name>
                          \_
                            <full project description name>.csproj
                            Class1.cs
                            ...
                            bin
                               \_
                                 Release
                                        \_
                                          <full project description name>.dll
                                          <full project description name>.pdb

This results in a file path:
c:\dev\Projects\Com.Hertkorn.Framework\SampleFramework\SampleFramework\bin\Release\
Com.Hertkorn.Framework.SampleFramework.dll and even with a deep folder structure it results in 126 chars. That is even less than with the default behaviour and flat folder sturcture.

Namespace (sometimes) != dll name

Plus this method allows for the additional freedom of easily choosing the namespace independant of the dll name. That is sometimes desirable, for example in a situation where types, typically interfaces should be shared between different dlls usually unifying components.

So component A which lives in the dll and namespace Com.Hertkorn.Infrastructure.ComponentA and component B which lives in the dll and namespace Com.Hertkorn.Infrastructure.ComponentB should share types. Ideally their shared types live in a component Com.Hertkorn.Infrastructure.SharedTypes.dll but the root namespace should differ. I would argue the root namespace should be Com.Hertkorn.Infrastructure. That way a subdirectory ComponentA or ComponentB would result in a namespace complementing the namespace they want to unify. It is kind of an exotic situation that needs a lot of discussion if the team wants to live with the consequences. But it could happen.

What needs tweaking in the .sln or .csproj

Within the .sln we need to tweak the file path of the resulting .csproj, which should be quite straight forward.

The changes within the .csproj are located in these two lines:

Tweet this