可以将F＃类型提供程序合并到C＃中
可以使用酷炫的新F＃3.0特征类型提供程序来弥合F＃数据类型或类与XML或WSDL等数据源结构之间的不匹配。 然而，这种不匹配也是其他.NET语言（如C＃）的挑战。
我想在C＃代码中使用F＃3.0提供程序。 如果有的话，我怎么能这样做呢？ 此外，如果我们不能，C＃实现需要什么才能使用它们？
我认为@kvb很好地概述了一些技术难题。 我同意类型推断会有问题 – 你基本上只限于在本地使用提供者生成的类型，类似于匿名类型 。 我认为C＃可能会在Roslyn中出现类似的东西，但我怀疑它会像F＃一样优雅和流畅地集成（其中类型提供程序实际上是语言function而不仅仅是工具 ）。
回答你的两个具体问题：
[我怎么能]在C＃代码中使用F＃3.0提供程序？
F＃类型提供程序实际上只能被F＃编译器理解，因此您需要在F＃中使用它们。 对于生成类型提供程序（SQL，实体，WSDL，配置文件），您可以从F＃引用提供程序并使用C＃项目中生成的类型。
对于擦除类型提供程序，您将无法执行此操作，因为类型实际上并不存在，只有F＃才能看到它们。 因此，最好的选择是在F＃中编写处理代码，并将结果作为记录集合或其他易于从C＃中使用的类型返回。
C＃实现需要什么才能使用它们？
当然，我可以说“C＃必须支持类型提供商！”，但这里有更多的想法。 类型提供程序只是.NET程序集，它们不使用任何F＃特定类型。 任何.NET语言（包括C＃）都可以使用ITypeProvider接口 ，因此如果C＃设计人员需要，他们可以重用已经为F＃构建的所有优秀提供程序。
因此，将此建议提交给C＃用户语音或在其他地方提倡（或说服Mono团队实施此操作！）并且可能会将其添加到C＃（ vNext + 1 + ... ）中。 目前，您只能获得F＃的所有好处。
类型提供程序如何工作的某些方面特别适合F＃程序员的需求，但在考虑针对其他语言的强类型数据访问的解决方案时可能不那么引人注目。 例如，很多F＃编程都是在F＃Interactive中完成的，与代码生成器（需要使用语言外部机制生成源代码文件）相比，类型提供程序可以很好地启用此工作流。 由于C＃程序员习惯于较慢的编辑 – 编译 – 运行周期，因此在C＃设置中这可能不那么重要。
从技术角度来看，我怀疑与C＃等语言相比，F＃更普遍的类型推断可能是最大的优势。 例如，如果我想从另一种类型的类型提供程序中包装一些数据访问逻辑，我可以这样做：
let moviesStartingWith prefix = query { for movie in MyDataSource.Movies do where (movie.Title.StartsWith(prefix) } |> Seq.toList
在C＃中，我需要指定返回类型（例如List ），这最终成为一件苦差事，这意味着即使使用IntelliSense，我也会点击提供的类型集来生成签名除了点击提供的值集以生成查询。
当然，这也适用于类型提供者以外的区域，但我认为对于一些由某些提供者自然生成的嵌套类型层次结构，这在实践中尤其痛苦，因为类型名称变得非常长。