"URI formats are not supported." 异常刚刚开始出现在非常旧的、未更改的代码中
"URI formats are not supported." exception just started showing up in really old, unchanged code
好的，我遇到了一个真正随机的错误，我找不到任何原因会发生这种情况。我有一个我更新的应用程序，它是多年前首次开发的。我在一个规模庞大的开发团队工作，他们的唯一职责就是管理这个应用程序，我们已经开始接受这个项目有点像 "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 解决方案后，我现在在尝试 运行 调试器测试时一直收到以下异常, 当初始化过程试图执行上面提到的代码片段时:
Exception: A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
Message: URI formats are not supported.
我用谷歌搜索了这条错误消息，看起来原来的开发者只是做错了。这似乎是 common error，但让我感到困惑的是，直到今天，这从来都不是问题。
我知道这是一个奇怪的问题，但是有没有办法在不修改这段代码的情况下解决这个问题。正如我所提到的，这是一个非常复杂的应用程序，常常感觉有点拼凑在一起。我们的团队正在尝试清理或替换大部分应用程序功能，但有些部分我们根本没有触及，因为我们没有确切的线索一旦应用程序部署到我们的生产环境后将如何工作。这是一个高度关键的应用程序，它不能被破坏。
可能有人知道是什么导致 "magically" 开始发生吗？特别是因为我一直在研究与 UI 相关的代码，并且没有接近代码的低级配置解析部分。
补充说明
- 我们使用源代码管理。如果我下载，构建一个 运行 应用程序的旧版本，它可以工作。
- 我们使用 AnkhSVN，当我检查我更改的文件时，再次发现，没有任何与现在失败的代码相关的更改。
- 我团队中没有其他人见过这个。
- 据我所知，我没有调整与我的项目相关的任何设置。我查看了我的项目属性，一切看起来都很正常。我想我有可能通过快捷键按下了一些奇怪的组合键和 enabled/disabled 东西，但我不知道那可能是什么。
感谢任何帮助。对不起小说。我只是被难住了，如果有任何机会改变这个过程可能在不同的用户环境中表现不同，我宁愿不使用不同的方法来获取这个路径字符串。
首先，找出多少个版本之前开始出现这种情况：从当前版本开始，逐个变更集返回变更集，直到它不再失败。
听起来，无论出于何种原因，System.Reflection.Assembly.GetExecutingAssembly().CodeBase 现在 returns 是一个 GetDirectoryName 不喜欢的字符串。因此，检查项目文件、.sln、repo 配置以及任何可能导致文件位于不同位置的内容。
如果在那里找不到任何东西，请检查同一提交中的其他文件，即使它们看起来不应该相关。
First Chance 当您有多个线程时，通常会发生异常，因此请检查以前版本中没有的新线程。我也遇到过 First Chance 异常只会在某些情况下被捕获，而在其他情况下会被默默忽略的情况，因此请查看调试设置中的更改：可能这个问题一直存在，您只是没有正确的设置抓到现在。
请记住，在源代码管理下，其他人可以更改 "yours" 的内容，即使只是偶然。
我只能假设 Visual Studio 中与 project/solution 关联的某些工作文件已损坏。我搜索了我的项目文件的文本和我所有的代码，没有发现任何不妥之处。
正如我提到的，我们使用源代码管理。为了尝试修复，我拉下了我最初为当前任务拉下的同一个源修订版。我编译并 运行 应用程序。一切都在其 "vanilla" 状态下正常工作。
接下来，我复制了我知道我修改过的所有文件。我没有添加任何新的项目引用或资源，所以我只是复制了修改后的 .cs 文件。我构建了 运行 应用程序，自从从我的 b运行ch 中拉出后，我没有遇到任何问题。
这并没有回答为什么会发生这种情况的问题，但是这种方法可以提供解决问题的方法。
我可以确认在安装 VS 2015 并在其中重建我们的项目后，Path.GetDirectoryName 发生了这一变化，因此它接缝成为 .NET 4.6 功能。
在 VS 2013 中再次重建项目 returns 以前的行为 Assembly.CodeBase 带有 "file:" 前缀是 Path.GetDirectoryName 可以接受的，没有任何例外。
但是重读MSDN文档，有一个说法是"file:" paths are not supported，但这在ArgumentException thrown in VS 2015 code.
中没有提到
好的，我遇到了一个真正随机的错误，我找不到任何原因会发生这种情况。我有一个我更新的应用程序，它是多年前首次开发的。我在一个规模庞大的开发团队工作，他们的唯一职责就是管理这个应用程序，我们已经开始接受这个项目有点像 "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 解决方案后，我现在在尝试 运行 调试器测试时一直收到以下异常, 当初始化过程试图执行上面提到的代码片段时:
Exception: A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll Message: URI formats are not supported.
我用谷歌搜索了这条错误消息，看起来原来的开发者只是做错了。这似乎是 common error，但让我感到困惑的是，直到今天，这从来都不是问题。
我知道这是一个奇怪的问题，但是有没有办法在不修改这段代码的情况下解决这个问题。正如我所提到的，这是一个非常复杂的应用程序，常常感觉有点拼凑在一起。我们的团队正在尝试清理或替换大部分应用程序功能，但有些部分我们根本没有触及，因为我们没有确切的线索一旦应用程序部署到我们的生产环境后将如何工作。这是一个高度关键的应用程序，它不能被破坏。
可能有人知道是什么导致 "magically" 开始发生吗？特别是因为我一直在研究与 UI 相关的代码，并且没有接近代码的低级配置解析部分。
补充说明
- 我们使用源代码管理。如果我下载，构建一个 运行 应用程序的旧版本，它可以工作。
- 我们使用 AnkhSVN，当我检查我更改的文件时，再次发现，没有任何与现在失败的代码相关的更改。
- 我团队中没有其他人见过这个。
- 据我所知，我没有调整与我的项目相关的任何设置。我查看了我的项目属性，一切看起来都很正常。我想我有可能通过快捷键按下了一些奇怪的组合键和 enabled/disabled 东西，但我不知道那可能是什么。
感谢任何帮助。对不起小说。我只是被难住了，如果有任何机会改变这个过程可能在不同的用户环境中表现不同，我宁愿不使用不同的方法来获取这个路径字符串。
首先，找出多少个版本之前开始出现这种情况：从当前版本开始，逐个变更集返回变更集，直到它不再失败。
听起来，无论出于何种原因，System.Reflection.Assembly.GetExecutingAssembly().CodeBase 现在 returns 是一个 GetDirectoryName 不喜欢的字符串。因此，检查项目文件、.sln、repo 配置以及任何可能导致文件位于不同位置的内容。
如果在那里找不到任何东西，请检查同一提交中的其他文件，即使它们看起来不应该相关。
First Chance 当您有多个线程时，通常会发生异常，因此请检查以前版本中没有的新线程。我也遇到过 First Chance 异常只会在某些情况下被捕获，而在其他情况下会被默默忽略的情况，因此请查看调试设置中的更改：可能这个问题一直存在，您只是没有正确的设置抓到现在。
请记住，在源代码管理下，其他人可以更改 "yours" 的内容，即使只是偶然。
我只能假设 Visual Studio 中与 project/solution 关联的某些工作文件已损坏。我搜索了我的项目文件的文本和我所有的代码，没有发现任何不妥之处。
正如我提到的，我们使用源代码管理。为了尝试修复，我拉下了我最初为当前任务拉下的同一个源修订版。我编译并 运行 应用程序。一切都在其 "vanilla" 状态下正常工作。
接下来，我复制了我知道我修改过的所有文件。我没有添加任何新的项目引用或资源，所以我只是复制了修改后的 .cs 文件。我构建了 运行 应用程序，自从从我的 b运行ch 中拉出后，我没有遇到任何问题。
这并没有回答为什么会发生这种情况的问题，但是这种方法可以提供解决问题的方法。
我可以确认在安装 VS 2015 并在其中重建我们的项目后，Path.GetDirectoryName 发生了这一变化，因此它接缝成为 .NET 4.6 功能。 在 VS 2013 中再次重建项目 returns 以前的行为 Assembly.CodeBase 带有 "file:" 前缀是 Path.GetDirectoryName 可以接受的，没有任何例外。 但是重读MSDN文档，有一个说法是"file:" paths are not supported，但这在ArgumentException thrown in VS 2015 code.
中没有提到