在非开发机器上加载错误的程序集?

发布于 2024-09-28 20:15:57 字数 1687 浏览 0 评论 0原文

我认为我陷入了一个常见的类别,“它在我的开发环境中完美运行,但在其他任何地方我都会得到奇怪的结果”,尽管我付出了所有努力,但我只是更加困惑。

我有 2 个应用程序。其中之一是 .NET 4 C# 应用程序,另一个是(我认为).NET 3.5 VB。 C# 应用程序创建了一个 DLL,目前我有一个使用 3.5 编译的 DLL 版本,以便我可以在我的 VB 应用程序中使用它。我有 VB 应用程序的源代码,但没有 C# 应用程序的源代码。我从未在我的机器上编译过 C# 应用程序。

在这个 DLL 中,它引用了一个基于 C 的库。 (我觉得这就是问题所在。)

在我的开发环境中,我可以在 VB 应用程序中使用这个 DLL,没有任何问题。但是,当我在另一台计算机上尝试此设置时,它的表现就好像与嵌入式基于 C 的 DLL 相关的位不是最新版本。

  • gacutil 确认 C# DLL 不是来自 GAC
  • FUSLOGVW 确认所引用的 C# DLL 的完全限定名称在开发/非开发环境中是相同的
  • 在我的 VB 应用程序和 app.config 中,我显式声明了 C# DLL 名称、令牌和版本。
  • 在我的 VB 应用程序中,在引用此 DLL 时,我将“复制本地”和“特定版本”设置为 False
  • 即使将基于 C 的 DLL 和 C# DLL 复制到目标计算机,看似错误的引用仍然会发生。
  • 即使在新系统上重新加载应用程序......问题也会出现。

这并不是说我遇到任何错误。 VB 应用程序仍然运行良好。 VB 应用程序正在实例化并使用该 C# DLL(其中包含 C DLL),我可以看到 VB 应用程序的不一致似乎是 C DLL 的问题。我的机器上从来没有 C# 应用程序的源代码,所以我不知道为什么它在我自己上运行良好,但在其他地方却运行得不好。

我觉得我对这件事所知甚少,已经到了尽头,而且我看不到其他地方可以去。不过,我确实觉得我应该能够在其他机器上重新创建工作环境。

我还可以查看什么?

编辑

我想我可以添加一些更具体的信息,希望能找到解决方案。目前,我已更新 VB 代码以处理不同的值。

该图表示从我的计算机上的 C-DLL 方法之一返回的值。 alt text

一切看起来都应该如此。然后,我将 DLL 和可执行文件带到新机器上,运行它,这些相同的项目显示为:

alt text

我已经多次检查了 GAC。我茫然地盯着加载的程序集日志几个小时,才注意到两个环境中都加载了相同的(正确的)DLL。我已确保两台计算机上都安装了相同的各种 MS 更新。我已从两个环境中删除了项目中使用的所有第 3 方 DLL,并将它们重新加载到两个环境中。

此时,我不知道是什么导致了这种情况的发生。没有错误。它在每个人的机器上都像在我自己​​的机器上一样愉快地工作,但我完全相信(可能是自己无法看到实际问题)我的开发机器创建/有“一些东西”,我无法移动,改变参考资料等。我目前感觉好像我已经用尽了我对此事的有限知识。

哦,最后一件事,这些 DLL 是从 VS2010 环境提供给我的。我明天就要 2010 年了,希望使用普通的 .NET 4 DLL,而不是我要求的 3.5。目前,这是我解决此问题的最后希望,除非我更改 VB 代码。

有什么想法吗?

I think I'm falling into a common category of, "It works perfectly in my dev environment, but anywhere else I get strange results," and for all my efforts I'm only more confused.

I have 2 applications. One of them is .NET 4 C# app, and the other is (I think) .NET 3.5 VB. The C# app creates a DLL, that for the time being, I have a version of this DLL compiled with 3.5 so that I can use it in my VB app. I have the source to the VB app, but not the C# app. I've never compiled the C# app on my machine.

Within this DLL, it references a C-based library. (I feel this is the problem.)

In my dev environment, I can use this DLL without any issue in my VB app. However, when I try this setup on another machine, it acts as though the bits relating to that embedded C-based DLL are not the most recent version.

  • gacutil confirms that the C# DLL isn't coming from the GAC
  • FUSLOGVW confirms that the fully qualified name of the C# DLL being referenced is the same in both the dev/non-dev environments
  • Within my VB app, and inside my app.config, I explicitly declare the C# DLL name, token and version.
  • Within my VB app, on my reference of this DLL, I have "Copy Local" and "Specific Version" set to False
  • Even with copying my C-based DLL and C# DLL to a target machine, the seemingly bad reference still occurs.
  • Even loading the apps anew on a fresh system... the problem presents itself.

It's not that I get any errors. The VB app still runs fine. The VB app is instantiating and using that C# DLL (which within it has the C DLL), and I can see that the inconsistencies from the VB app appear to be issues with the C DLL. I've never had the source code to the C# app on my machine, and so I haven't any idea why it works well on my own, but not anywhere else.

I feel I've reached the end of what little I know about this, and I don't see anywhere else to go. I do feel that I should be able to re-create a working environment on other machines, though.

What else can I look in to?

Edit

I thought I may add some more specific information in the hopes that it leads to a solution. For the time being, I've updated the VB code to work with the differing values.

This picture represents the values returned from one of the C-DLL methods on my machine.
alt text

Everything looks as it should. I then take my DLLs and executable to fresh machine, run it, and these same items appear as:

alt text

I've checked the GAC several times. I've stared blankly at the loaded assembly logs for several hours only to take note that the same (correct) DLLs are being loaded in both environments. I've ensured the same various MS updates are installed on both machines. I've removed all 3rd party DLLs from both environments, that are used in the project, and reloaded them to both.

At this point, I have no clue what is causing this to happen. There's no errors. It works just as happily on everyone's machine as it does my own, but I am thoroughly convinced (probably to own inability to see the actual problem) that my dev machine creates/has "something" I'm failing to move over, change the reference, etc. I just currently feel as though I've exhausted my limited knowledge on the matter.

Oh, one last thing, the DLLs were provided to me from a VS2010 environment. I'll have 2010 tomorrow, and hope to use the normal .NET 4 DLL instead of the 3.5 I requested. This currently is my last hope for fixing this issue short of me changing the VB code.

Any ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

生死何惧 2024-10-05 20:15:57

抱歉,如果我错过了某些内容,但您是否考虑过,这可能只是格式设置,而不是不同的结果?
从您的示例中,我只能看到以两种不同格式显示的相同结果(一种具有两个固定小数位,另一种仅显示相关数字)。
如果你检查你的代码,如果 top 值 == 2.0 它在所有计算机上都应该是 true,如果是这样 - DLL 在所有计算机上返回相同的值,并且它们只是显示不同(可能计算机区域设置不同?)

Sorry, if I have missed something, but have you considered, that it might be just formatting settings, not different results?
From your example, I can only see the same results displayed in two different formattings (one with two fixed decimal places, and the other showing only relevant numbers).
If you check in your code if the top value == 2.0 it should be true on all computers, and if so - the DLL returns the same values on all computers, and they are just displayed differently (maybe computer locale settings differ?)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文