4

好的,我遇到了一个真正随机的错误,我找不到任何会发生这种情况的原因。我有一个我更新的应用程序,该应用程序是多年前首次开发的。我在一个庞大的开发团队工作,他们的唯一职责是管理这个应用程序,我们已经开始接受这个项目有点像“科学代码”项目。我们只是继承了这个项目的许多代开发人员中的谦逊开发人员。(稍后知道这一点很重要。)

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

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

这是交易。我的团队成员和我自己一直能够修改和构建我们解决方案的更高级别的 UI 和 DB 相关部分。我和其他任何人都修改了上述代码,或同一代码文件(或解决方案中的项目,就此而言)中的任何代码。

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

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

我用谷歌搜索了这个错误消息,看起来原来的开发人员只是做错了。这似乎是一个常见的错误,但让我感到困惑的是,直到今天,这才随机出现。

我知道这是一个奇怪的问题,但是有没有办法在不修改此代码的情况下解决这个问题。正如我所提到的,这是一个非常复杂的应用程序,常常让人感觉有些拼凑。我们的团队正在尝试清理或替换大部分应用程序功能,但有些部分我们根本没有触及,因为我们不知道应用程序在部署到我们的生产环境后将如何工作。这是一个非常关键的应用程序,它不能被破坏。

可能有人知道什么可能导致这种情况“神奇地”开始发生吗?特别是因为我一直在处理与 UI 相关的代码,并且在代码的低级配置解析部分附近没有任何地方。

补充说明

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

任何帮助表示赞赏。对不起小说。我只是被难住了,如果有任何机会改变这个过程在不同的用户环境中表现不同,我宁愿不使用不同的方法来获取这个路径字符串。

4

3 回答 3

2

我只能假设与项目/解决方案关联的 Visual Studio 中的某些工作文件已损坏。我搜索了我的项目文件的文本以及我的所有代码,我没有发现任何不合适的地方。

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

接下来,我复制了所有我知道我已经修改过的文件。我没有添加任何新的项目引用或资源,所以我只是复制了修改后的.cs文件。我构建并运行了应用程序,自从从我的分支中提取后,我没有遇到任何问题。

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

于 2015-05-22T12:02:48.270 回答
1

我可以确认 Path.GetDirectoryName 在安装 VS 2015 并在其中重建我们的项目后发生在我身上的这种变化,因此它似乎是 .NET 4.6 功能。在 VS 2013 中再次重建项目会返回先前的行为,其中带有“file:”前缀的 Assembly.CodeBase 可以被 Path.GetDirectoryName 接受,没有任何例外。但是重读MSDN文档,有一个说法是“file:”paths are not supported,但是在VS 2015代码中抛出的ArgumentException中并没有提到这一点。

于 2015-08-04T06:27:40.307 回答
0

首先,找出多少个版本之前开始发生这种情况:从当前版本开始,并按变更集回溯变更集,直到它不再失败。

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

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

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

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

于 2015-05-20T20:39:52.877 回答