问题标签 [clr4.0]

标题是我想要完成的不言自明。我有一个内置于 3.5 的 COM 可见组件，我的新项目是 4.0。我想从 3.5 组件运行与下面非常相似的代码。

最终我得到了错误“这个程序集是由比当前加载的运行时更新的运行时构建的，并且无法加载”
我对我在其他地方找到的内容感到非常沮丧。我所需要的只是一个解决方法来实现这一点。谢谢！

再次问候，

继我之前的问题之后，我试图最大限度地提高我用 C# 编写的 Windows Explorer 扩展的兼容性。特别是，我有兴趣确保它在安装了 .NET 4且未安装 .NET 3.5 及更低版本的环境中工作。有人会认为没有问题，但显然不是那么简单......

有两个问题。首先，非 .NET-4 目标程序集将不会使用 CLR 4 加载，除非它们有一个.config指定<supportedRuntime version="v4.0" />. 如果没有这个文件，即使尝试使用ngen它们也会失败。.config但我的 DLL 进入 GAC。我如何也可以.config在其中获取文件？其他人也问过同样的问题，并得出结论“好吧，我将改为创建一个静态设置类。” 显然我不能这样做...

第二个问题：当我用 注册我的 DLL regasm.exe，然后打开注册表查看它写的内容时，我RuntimeVersion = v2.0.50727在它的 CLSID 条目下看到。这也可以防止加载 DLL。只有在我手动将RuntimeVersion值更改v4.0.30319为 DLL 加载后。

那么我必须让我的安装程序在这里做什么呢？对于第一个我不知道。第二，我想我必须让安装程序手动将注册表的 RuntimeVersion 设置为安装的任何 .NET 版本？这似乎太古怪了，不可能是真的……

我知道探查器 2.0 有一个：http: //www.codeproject.com/KB/dotnet/dotnetprofiler.aspx 但是探查器 API 在 .NET 4.0 中发生了变化，我们需要同时考虑进程内问题。我需要一个示例来自定义我们自己的分析器。有人知道吗？谢谢！

我是一名中级程序员，这些天我一直在分析 CLR，我的问题是需要学习 c# 命令行的所有命令！太无聊了。

有必要吗？

我的应用程序在其 .exe.config 中需要useLegacyV2RuntimeActivationPolicy，因为它是一个使用混合模式 CLR2 程序集的 CLR4 应用程序。

从“开始”菜单启动我们的应用程序时一切正常，但是如果用户通过单击与我们的应用程序具有文件类型关联的文件之一来启动我们的应用程序，则不会读取 app.config 文件并加载这些文件CLR2 程序集失败。

根据进一步的研究，ShellExecute 似乎不会读取 .config 文件（即使指定了 app 文件夹），但 WinExec 会。我认为 shell 使用 ShellExecute 通过文件关联来启动应用程序。

除了在启动主应用程序的进程之前编写一个设置当前文件夹的中间应用程序之外，还有什么解决方法吗？这是在本网站的其他地方提出的。

提前致谢！

我的同事提到 CLR 4.0 中有一些与Windows 事件跟踪相关的重大改进，但我无法找到有关新功能的详细信息。很少有博客文章只提到改进，但没有提供任何关于究竟是什么新功能的细节。有人对它有更深入的了解吗？

我有一个依赖于对 mscoree 2.0（来自 .net 2.0-3.5）的引用的应用程序。我知道这不是一个好习惯，但我现在必须忍受它。

该应用程序使用标准 msi（由 Visual Studion 安装项目生成）安装。我的问题是我在安装了 mscoree 2.4 的盒子上安装了 .net 4.0，每次我安装我的小应用程序时，mscoree 2.4 都会取消注册，我需要修复 .net 4.0 安装才能恢复正常。

有没有人在使用 .net COM 时遇到过类似的行为？有没有一种简单的方法/解决方法来避免 mscoree 2.4 注销？

我有一个应用程序，用 c++ 编写并用 VS 2010 编译。我需要加载用 C# 编写并从 c++ 代码为 .net 4.0 平台编译的 .net dll 并调用一些函数。我已经通过 C++ CLR 及其调用 .net 函数完成了这项工作，直到系统中没有安装 .net 4.0。

当未安装 .net 4.0 时，任何函数调用都会在我的 c++ 代码中引发 SEH 异常，但库加载成功。每次异常代码都是相同的0xE0434F4D。

问题：

1. 是否可以从 C++ 代码中确定加载的 dll 的目标 .net 平台，并确定系统中是否安装了该平台？
2. 也许还有其他方法可以防止 SEH 异常并显示人类可读的错误解释？

提前致谢

基本上每个关于 Windows Shell 扩展的 SO 线程（例如显示覆盖图标或扩展特定文件的资源管理器上下文菜单）都强烈建议不要为此目的使用托管代码。我完全理解 http://blogs.msdn.com/b/oldnewthing/archive/2006/12/18/1317290.aspx给出的推理

我的问题是，在 CLR4.0 环境中操作时，这些谨慎的话是否仍然成立。据我了解http://channel9.msdn.com/Shows/Going+Deep/CLR-4-Side-by-Side-In-Process-What-How-Why将依赖于不同 CLR 版本的托管代码加载到相同的进程（在本例中为 explorer.exe）在 CLR4.0 中得到更优雅的处理。

非常感谢您在这里的洞察力。

最近我正在运行Andrew Hunter 在他的博客“大对象堆的危险”中提供的示例，该示例针对 .NET 4 编译，我得到了以下数字：

大块：分配 622Mb
大块，频繁垃圾收集：分配 582Mb
仅小块：分配 1803Mb
大块，未增长的大块：分配 630Mb

如果针对 .NET 2.0 编译相同的代码，我几乎得到了文章中提到的数字：

使用大块：分配 21Mb
使用大块，频繁垃圾收集：分配 26Mb
仅分配小块：分配 1811Mb
使用大块，未增长的大块：分配 707Mb

如此显着改善的原因是什么？

代码针对 x86 平台编译并在 Windows 7 上运行