Very long assembly name

Speaking of file name inspired me to write another post about assembly name.

Windows supports long file path since Win95 time. It has a MAX_PATH limit, which is defined as 260.

Prior to .Net era, you seldom see long file name. If you poke around your system32 directory, you probably won't notice any thing longer than 10 charater(excluding extenstion). Guess people are slowly migrating from DOS 8.3 era. MAX_PATH is really a luxury.

This is suddenly changed in .Net era. If you installed .Net framework redist, you have System.Runtime.Serialization.Formatters.Soap.dll. If you installed Visual Studio, you have Microsoft.VisualStudioAnalyzer.PrimaryEventCollector.dll.

And I have seen longer. 6 or 7 dots, with more than 10 charaters between dots.

Now suddenly MAX_PATH is not looking good.

I certainly don't like short name. But don't these very long names go too far?

Neverthless, Let's do some simple caculation to see what is the longest assembly name that can fit in GAC.

As of today, stuff lives in GAC have the following format(Subject to change in the future):
%windir%\assembly\GAC\<assembly name>\<version>_<culture>_<public key token>\<assembly name>.dll

Assume %windir%=C:\Windows, and <version> = 1.0.5000.0, <culture>=””, now all the non assembly name parts have a total of 59 character(Don't forget a null terminator). So maximum assembly name length is (MAX_PATH - 59) / 2 = 100 character.

Of course, if your version is longer than 1.0.5000.0, your limit is smaller.
And smaller if you have a culture.
And smaller if you want your assembly to be NGENed.

Comments (9)

  1. Jerry Pisk says:

    Actually NT kernels support 2^31 characters in a file name (well, the full path to be exact), just start with "\?".

  2. This is a very heated debate. Most kernel32.dll APIs support 2^31 character long file name. But shell32.dll and shlwapi.dll APIs are very much tight to MAX_PATH limit.

  3. moo says:

    Shouldnt everything support the max UNC limit?

  4. moo says:

    Shouldnt everything support the max UNC limit?

  5. Kiliman says:

    Since Explorer itself can’t handle files greater than MAX_PATH, it makes it very problematic to create files longer than that.

    Unfortunately, I don’t see an easy way around this problem.

    The majority of applications use something similar to:

    function foo()


    // allocate space for filename on stack

    TCHAR filename[MAX_PATH];

    // do something with filename


    Since the filename is allocated on the stack, changing it to something larger like 32K would certainly blow up the stack of any application that was recompiled.

    Also, existing applications would not be able to access files that are created with extremely long paths, short of using something similar to LFN -> 8.3 support introduced in Win95.

  6. The problem is if Microsoft does not make a move, nobody else will. But if Microsoft makes a move, many existing applicationd will be broken. Kind of chicken-and-egg problem.

  7. This will probably affect localization projects. For now many companies are just developing US versions and may not hit the problem. Add a culture and you’ll start seeing it.

    A class of localization issues that was extremely uncommon will be showing up more often 🙁

  8. moo says:

    Blasphsmey! There is no people outside the US!! There are sea serpants and you will fall off the edge of the Earth! The Sun orbits around the US!..

    Put him in the stocks, spreading dangerous rumours of lands beyond the US.

Skip to main content