FSharp.Compiler.CodeDom 适用于 VS2008 和 VS2010 并行
我正在使用 FSharp.Compiler.CodeDom（来自 PowerPack）动态创建 F# 类。问题是，我的计算机上并排有 VS2008 和 VS2010（它们工作正常），并且在此配置中使用 F# 充其量是有问题的：
- 如果我不安装 InstallFSharp.msi，那么在 VS2008 下构建的类抱怨找不到 FSharp.Core（即使它们被引用）
如果我安装 InstallFSharp.msi，那么在 VS2008 下，构建的类将使用为 VS2010 构建的 F#，并将抛出二进制不兼容异常，因为它将加载 .net4 变体：
FSC：错误 FS0219：引用的或默认的基本 CLI 库“mscorlib”是二进制的 - 与引用的 F# 核心库 'C:\Program Files (x86)\Microsoft 不兼容 F#\v4.0\FSharp.Core.dll'。考虑重新编译库或进行显式引用 到与您正在使用的 CLI 版本相匹配的该库的版本。
如果我将在先前位置找到的 F# 替换为单独安装的 dll，那么 VS2010 当然会抱怨二进制不兼容
我是否忽略了某些东西，或者它们不会简单地适用于这样的共享环境？当我部署应用程序时，这可能意味着真正的问题。
谢谢
I'm using FSharp.Compiler.CodeDom (from the PowerPack) to dynamically create F# classes. The problem is, that I have both VS2008 and VS2010 on my computer side-by-side (they works fine), and using F# in this configuration is buggy at best:
- If I don't install InstallFSharp.msi, then under VS2008 the built classes complain about not finding FSharp.Core (even if they're referenced)
If I install InstallFSharp.msi, then under VS2008 the built classes will use the F# built for VS2010, and will throw a binary-incompatibility exception, because it will load the .net4 variant:
FSC: error FS0219: The referenced or default base CLI library 'mscorlib' is binary-
incompatible with the referenced F# core library 'C:\Program Files (x86)\Microsoft
F#\v4.0\FSharp.Core.dll'. Consider recompiling the library or making an explicit reference
to a version of this library that matches the CLI version you are using.If I replace the F# found at the previous location to the separately installed dll-s, then of course VS2010 will complain about binary-incompatibility
Am I overlooking something, or they won't simply work for a shared environment like this? This might mean real problems when I deploy the applications.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我自己也有类似的问题 - 我们的源代码树的主干设置为使用 VS 2008 构建，而我们最新的分支升级到 VS 2010。至少可以说，F# 的情况令人厌烦。
我们找到的答案是使用 --noframework 编译器标志。设置该选项后，您可以（必须）指定要使用哪个 mscorlib.dll 和 System.dll，因此可以针对任何受支持的 .NET 框架进行构建。
I have a similar problem myself - the trunk of our source tree is set up to build with VS 2008, while our latest branch upgrades to VS 2010. The F# situation is wearisome, to say the least.
The answer that we've found is to use the --noframework compiler flag. With that option set, you can (must) specify which mscorlib.dll and System.dll you want to use, and therefore can build against any supported .NET framework.
鉴于您最初提出这个问题不久前，我想知道您是否有最新的 PowerPack？值得注意的是，您在 5 月 27 日提出问题，但我在下载页面上看到它的最后更新时间是 5 月 30 日。我不知道这是否会影响任何内容，只是指出来。
我还稍微编辑了这个问题，以防将问题移到顶部并导致托马斯看到它并回复:)
Given that you originally asked the question a while ago, I wonder if you have the most recent PowerPack? Notably, you ask the question on May 27, but I see on the downloads page that it was last updated on May 30. I dunno if that affects anything, just pointing it out.
I also edited the question a tiny bit, in case this moves the question to the top and causes Tomas to see it and reply :)
我修复了一个与 reghack 可能相同或不同的问题（Windows 7）：
Windows 注册表编辑器版本 5.00
[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\FSharp\2.0\Runtime]
我相信查找文件/编译器的解析路径意味着此 hack 将导致两者并行工作，但只有测试了2.0的情况。
与任何注册表破解一样，您应该首先备份该注册表密钥。
I fixed a problem that may or may not have been the same with the reghack (Windows 7):
Windows Registry Editor Version 5.00
[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\FSharp\2.0\Runtime]
I believe that the resolution path to find files/compilers means that this hack will cause both to work side-by-side, but have only tested the 2.0 case.
As with any reg hack, you should back up that that reg key first.