Application.UserAppDataPath strange behaviour

When I use Application.UserAppDataPath to get to configs, I've got a ArgumentException "Illegal characters in path."

According to Microsoft it is not a bug, but a feature;

The only way ho开发者_如何学Cw you can get an illegal character in FileVersionInfo.ProductVersion (and hence in Application.ProductVersion and Application.UserAppDataPath) is when you also have AssemblyFileVersion on the assembly. The value that goes to AssemblyFileVersion is copied to the Win32 resources verbatim and overrides the value you pass to AssemblyVersion. This behavior is by design.

So by commenting [assembly: AssemblyFileVersion("...")] in AssemblyInfo.cs one could solve this exception.

The problem is: I'm writing some .dll with winforms controls. Easiest design to get this path would be to use Application.UserAppDataPath. But if Application.UserAppDataPath is used, then developers who use this library cannot have AssemblyFileVersion for their .exe files. (While AssemblyFileVersion is in the AssemblyInfo.cs by default)

Also I couldn't find any information by Microsoft that using AssemblyFileVersion should brake my application and somebody shouldn't use it. So I, actually, can't ask it from this library users.

Is there a reason or logic in such weird situation? What is a better work-around to get Application.UserAppDataPath path with no such problems?

While I have AssemblyFileVersion and Application.UserAppDataPath would throws the exception, the application works and i could get this path through

string path = ConfigurationManager.OpenExeConfiguration(
            ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath;

The config files are there and have no problems. But, certainly, it is an ugly way.

If I read that post on Connect correctly you have to use AssemblyFileVersion with an illegal char ('*').

Appropriately it ends with "If you still believe that this is a bug" ....

Did you reproduce the error, and was that a realistic scenario?