能在Fsharp脚本文件没有打开命名空间

当在SomeLib.fs单独Fsharp项目文件中的以下代码编译：能在Fsharp脚本文件没有打开命名空间

namespace SomeNameSpace 
type SomeType = 
    member this.SomeMember = "Some member"

，并要引用，并像一个脚本文件中使用此类型：

#I @"c:/pathToDll/" 
#r "SomeLib.dll"

这是不可能的，虽然dll的路径是正确的，我检查了一切。另外，当SomeLib.fs文件位于同一个项目中并且被#load引用时，您仍然无法打开命名空间。

我知道你可以把这个类型放在一个模块中，但是我不能这样做，因为这个类型已经被用作一个Wcf服务类型。

来源

2013-06-04 halcwb

经过大量的实验工作和令人惊讶的一点信息在互联网上或在F＃的书，我发现了以下工作：

// Cannot use a relative path 
//#I @"bin\Debug" 
// Have to use a absolute path 
#I @"C:\Development\FSharpNameSpaceTest\SomeCSharpLib\bin\Debug" 
// But I can reference a Csharp dll lib 
#r "SomeCSharpLib.dll" 

// I cannot add a reference to an external F# library dll 
// #I @"C:\Development\FSharpNameSpaceTest\NameSpace\bin\Debug" 
// #r "NameSpace.dll" 

// If I directly load the external fs file, it works" 
#load @"C:\Development\FSharpNameSpaceTest\NameSpace\SomeNameSpace.fs" 
#load "Library1.fs" 

// Namespaces in both the local and the external fs files can only be openend if every single file is loaded instead of referencing the dll. 
// Referencing a C# dll is no problem 

open FSharpNameSpaceTest 
open SomeCSharpLib 
open NameSpace

我不知道这是否是最理想的方法，但它的工作原理。我要做的是，我将为每个项目创建一个fsx文件，以便在该项目中加载单个fs文件，然后将该fsx文件加载到引用该项目的fsx文件中。

我仍然觉得这一切非常混乱和违反直觉。但是这可能是我对F＃内部工作的有限了解。编辑：而且正确和完整的答案是，我没有实现默认的构造函数。不过，如果你不想这样做，上述方法是一种选择。感谢Marc Sigrit。

来源

2013-06-05 11:22:43 halcwb

请注意：当您使用依赖#I导入的#r引用时，智能感知通常不适用于引用中的类型。但是，当您使用“独立”#r参考（完整路径，不带#I）时，智能感知可以正常工作。这就是为什么我几乎从不使用#I，但它会是非常实用的，否则... –

“我无法添加对外部F＃库DLL的引用”：添加对外部F＃库DLL的引用是绝对有可能的。有时你必须小心引用的顺序。如果F＃dll依赖于C＃dll，则必须先引用c＃dll，然后再引用F＃dll ... –

@MarcSigrist我试过上面的代码，它绝对没有引用F＃dll，我可以向你保证。唯一的可能性仍然是我在上面的代码中做了一些愚蠢的事情。我也在这里发布了一个更详细的答案和解决方案：http://stackoverflow.com/questions/16937387/f-and-c-sharp-web-service-cannot-open-namespace – halcwb

如果在Windows上，导入指令中的斜杠应该用反斜杠代替。

来源

2013-06-05 11:10:58

谢谢，但实际上并不重要。你甚至可以混合前进和反斜杠（尽管它是丑陋的）。 – halcwb

惊喜！我不知道，谢谢你的提示！ –

能在Fsharp脚本文件没有打开命名空间

回答

相关问题