“不支持URI格式。”异常开始出现在真正陈旧的未更改的代码中

Question

好吧，我遇到了一个真正的随机错误，我找不到任何理由为什么会这样。 我有一个我更新的应用程序，这是多年前首次开发的。 我在一个规模很大的开发团队工作，他们的唯一责任是管理这个应用程序，我们已经开始接受这个项目是一个“franken-code”项目。 在继承这个项目的许多代开发人员中，我们只是谦虚的开发人员。 （稍后会知道这一点很重要。）

我们的应用程序的一部分在初始化过程的深处调用以下代码：

string strPath = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().CodeBase);
string strFile = strPath.Substring(6) + "\\" + FILE_NAME;

这是交易。 我的团队成员和我自己已经能够永久地修改和构建我们解决方案的更高级别，UI和DB相关部分。 我或其他任何人都修改了上面的代码，或者相同代码文件中的任何代码（或解决方案中的项目）。

然而，今天在我的应用程序的一个完全不同的部分工作时，我开始得到一些非常奇怪的“Out of Memory”异常错误。 我不确定这是否与我的问题有关，但我觉得值得一提的是，在重新启动我的机器并重新加载VS解决方案之后，当我尝试运行调试器测试时，我现在一直得到以下异常进程尝试执行上面提到的代码片段：

异常：mscorlib.dll中出现“System.ArgumentException”类型的第一次机会异常消息：不支持URI格式。

我用谷歌搜索了这个错误信息，看起来原来的开发人员只是做错了。 这似乎是一个常见的错误 ，但令我感到困惑的是，这一直是今天随机发生的问题。

我知道这是一个奇怪的问题，但有没有办法解决这个问题，而无需修改此代码。 正如我所提到的，这是一个非常复杂的应用程序，通常会感觉有点拼凑在一起。 我们的团队正在尝试清理或替换大部分应用程序功能，但有些部分我们根本不接触，因为我们无法确定应用程序在部署到我们的生产环境后如何工作。 这是一个非常关键的应用程序，它不能被打破。

任何人都可能有任何线索可能导致这种“神奇地”开始发生吗？ 特别是因为我一直在使用与UI相关的代码，并且没有接近代码的低级配置解析部分。

补充笔记

• 我们使用源代码控制。 如果我下载，构建一个运行较旧的应用程序版本，它的工作原理。
• 我们使用AnkhSVN，当我再次检查更改的文件时，没有任何与现在失败的代码相关的更改。
• 我的团队中没有其他人见过这个。
• 据我所知，我没有调整任何与我的项目相关的设置。 我看了一下我的项目属性，一切看起来都很正常。 我想有可能我通过快捷键击中了一些奇怪的键组合并启用/禁用了某些东西，但我不知道那可能是什么。

任何帮助表示赞赏。 对不起小说。 我只是难倒，如果有可能在不同的用户环境中改变这个过程可能会有不同的行为，我宁愿不使用不同的方法来获取此路径字符串。

Answer 1

我只能假设Visual Studio中与项目/解决方案相关的一些工作文件已损坏。 我搜索了我的项目文件的文本和我的所有代码，但我没有看到任何不合适的地方。

正如我所提到的，我们使用源代码控制。 为了尝试修复，我删除了我最初为当前任务提取的相同源代码修订版。 我编译并运行了应用程序。 一切都在“香草”状态下正常运作。

接下来，我复制了我知道修改过的所有文件。 我没有添加任何新的项目引用或资源，所以我只是复制了修改后的.cs文件。 我构建并运行了应用程序，因为从我的分支中拉出来我没有遇到任何麻烦。

这并没有回答为什么会发生这种情况的问题，但这种方法可以解决问题。

Answer 2

我可以在安装VS 2015并在其中重建我们的项目后确认Path.GetDirectoryName中发生的这种变化，因此它接缝为.NET 4.6功能。 在VS 2013中再次重建项目将返回先前的行为，其中带有“file：”前缀的Assembly.CodeBase可由Path.GetDirectoryName接受，没有任何异常。 但是重新阅读MSDN文档，有一条声明不支持“file：”路径，但在VS 2015代码中抛出的ArgumentException中没有提到这一点。

Answer 3

首先，找出这个开始发生的版本：从当前版本开始，然后通过changeset返回changeset，直到它不再失败。

听起来，无论出于何种原因， System.Reflection.Assembly.GetExecutingAssembly().CodeBase现在返回一个GetDirectoryName不喜欢的字符串。 因此，请检查项目文件， .sln ，repo配置，以及可能导致文件位于其他位置的任何内容。

如果您在那里找不到任何内容，请检查同一提交中的其他文件，即使它们看起来不应该相关。

第一次机会异常通常在您发生多个线程时发生，因此请检查不在先前版本中的新线程。 我也遇到过First Chance异常只会在某些情况下被捕获的情况，否则会被忽略，所以看看Debug设置中的更改：这个问题可能一直存在，你只是没有正确的设置抓住它直到现在。

请记住，在源代码控制下，其他人可以更改“你的”内容，即使只是偶然。