Application.UserAppDataPath奇怪的行为 [英] Application.UserAppDataPath strange behaviour

问题描述

当我使用Application.UserAppDataPath进行配置时，我遇到了ArgumentException路径中的非法字符."
根据Microsoft的说法，是不是错误，而是功能；

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;

如何在FileVersionInfo.ProductVersion(以及因此在Application.ProductVersion和Application.UserAppDataPath)中获取非法字符的唯一方法是在程序集中也有AssemblyFileVersion.转到AssemblyFileVersion的值将逐字复制到Win32资源中，并覆盖您传递给AssemblyVersion的值.此行为是设计使然.

The only way how 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.

因此，通过注释AssemblyInfo.cs中的[assembly:AssemblyFileVersion("...")]，可以解决此异常.

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

问题是: 我正在用Winforms控件编写一些.dll.获得此路径的最简单设计是使用Application.UserAppDataPath.但是，如果使用Application.UserAppDataPath，则使用此库的开发人员不能为其.exe文件使用AssemblyFileVersion. (虽然AssemblyFileVersion默认位于AssemblyInfo.cs中)

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)

我也找不到Microsoft提供的任何信息，这些信息表明使用AssemblyFileVersion会使我的应用程序停止运行，而某些人则不应使用它.因此，实际上，我无法向该库用户询问.

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.

在这种奇怪的情况下，是否存在原因或逻辑? 没有这样的问题，获取Application.UserAppDataPath路径的更好的解决方法是什么?

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?

虽然我具有AssemblyFileVersion和Application.UserAppDataPath会引发异常，但该应用程序可以正常工作，而且我可以通过以下方式获得该路径

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.

推荐答案

如果我在Connect上正确阅读了该帖子，则必须将AssemblyFileVersion与非法字符('*')一起使用.

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?

这篇关于Application.UserAppDataPath奇怪的行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！