Runtime: 是否应该有.Net Standard 2.0版本的Reflection.Emit？

@ericstj @weshaggard您知道这是疏忽大意？

这是故意的。 对于此类具有参差不齐的支持且没有可移植实现的库，我们已停止提供软件包。 期望您可以根据需要针对特定​​框架。 对于某些人，我们带回了带有地雷的包装（在某些平台上抛出了实现）。 人们可以建议我们重新添加它，但是由于缺乏对所有基于AOT的.net框架的支持，过去尤其对此进行了激烈的辩论。 / cc @terrajobst

@ericstj

期望您可以根据需要针对特定​​框架。

我应该如何学习呢？ 据我所知，platform-compat没有报告Reflection.Emit。 当我谷歌“反射发出的.Net标准”时，只谈论是否应该使用这种方式是在第一页上导致鸣叫从2017年7月通过@terrajobst建议你应该这样做（也许情况，因为再变？）。

我让@terrajobst做出回应，也许他在考虑1.x和1.x软件包中的nuget gaurdrails功能。 有了这些，我们就实现了锯齿状的实现，并为消息不支持的消息建立了时间支持。 在这里，我并不是特别倾向于一种方式，而只是为了解释当前的工作方式。 我认为，如果我们可以在不支持平台的实施方案上添加回包，从而获得人们的认可，我们可以这样做。

FWIW框架中可用的任何东西，但在netstandard或具有netstandard资产的库/软件包中不可用的任何东西，意味着您需要定位框架以获取它。 这就是我的期望评论。

@ericstj

框架中可用的任何东西，但在netstandard或具有netstandard资产的库/软件包中没有的任何东西，意味着您需要针对框架以获取它。 这就是我的期望评论。

但是，此软件包（带有.Net Standard 1.x资产）确实存在。 我认为您不能停止更新软件包并假设人们不再使用它了。 至少，您应该具有说明情况的文档。

System.Reflection.Emit的最大麻烦在于，由于TypeInfo，我们无法以网络标准的方式提供库（请参阅https://github.com/dotnet/corefx/issues/14334）。 现有的软件包以netstandard1.1为目标，但这是一个谎言，由于我们之间的紧密耦合，它只能在.NET Framework和.NET Core上运行。 我们通过玩InternalsVisibleTo技巧使它可以访问TypeInfo的构造函数，从而使其工作，但该技巧也使它无法在常规.NET Standard平台上工作。 我们决定不再以相同的方式入侵netstandard2.0来进一步传播错误，而是停止生产该软件包并使其特定于平台。

感谢您提出问题@svick ，我们应该使用此问题来记录软件包的问题。

在NuGet上取消列出不再更新的软件包怎么样，很明显不建议使用它们？

这是一个合理的建议。 我只是未列出所有https://www.nuget.org/packages/System.Reflection.Emit/和https://www.nuget.org/packages/System.Reflection.Emit.Lightweight的版本。

这是非常需要的。 当前，无法构建和保存程序集是我的dotnet / corefx＃1更新至.NET Core的最大障碍，我真的很想看到使此最基本的API能够比开发新功能具有更高的优先级， 。

@masonwheeler只是要声明您可以使用Reflection.Emit。如果您正在编写.NET Core应用程序或库，则当前在编写.NET Standard库时就不能使用它。

您确定@weshaggard吗？ 我刚刚检查了仓库，看来不仅AssemblyBuilder.Save没有实现，甚至在Core上

@masonwheeler您是正确的，我们不支持AssemblyBuilder。保存在另一个问题https://github.com/dotnet/corefx/issues/4491跟踪的.NET Core中

在那里！ 我以为我以前见过这个问题，但是搜索只发现了这个问题。 ：P

但是，是的。 没有实际发出结果的能力

所述System.Reflection.Emit.Lightweight包之前@weshaggard被不公开关于nuget.org有可能在Windows 10得到Selenium.WebDriver包PowerShell中5（用于.Net框架）和PowerShell核心6（对于.NET核2.0）使用以下命令：Install-Package Selenium.WebDriver -Destination $ PSScriptRoot -Force -ForceBootstrap

现在，此命令无法下载两个PowerShell版本的所有Selenium软件包依赖项。 它失败是因为nuget.org上未列出System.Reflection.Emit.Lightweight.4.3.0程序包。
错误：安装软件包：无法找到依赖的软件包（System.Reflection.Emit.Lightweight）

您能提供有关如何解决此问题的建议吗？

@SergeyKhutornoy您是从Package Manager控制台在VS中调用“ Install-Package”吗？ 如果是这样，则可以为我正确安装该软件包。 如果要从Powershell调用安装程序包，则这是另一种程序包管理。 我实际上只是在本地尝试过，但遇到了另一个错误（安装程序包：找不到与指定搜索条件和程序包名称“ Selenium.WebDriver”匹配的文件。）我对该程序包管理系统不熟悉，所以我不知道如何解决它。 您可以尝试做的一件事是先明确安装System.Reflection.Emit.Lightweight 4.3.0，然后查看其是否有效。 如果那不起作用，是否有原因导致您无法使用VS或nuget工具来安装软件包？

不列出此程序包是一个错误，并且不提供.NET Standard 2.0版本是一个错误。

我们即将发布产品的主要新版本NServiceBus，我们的目标是netstandard2.0 。 我们还依赖于System.Reflection.Emit和System.Reflection.Emit.Lightweight。 我原本打算分别针对.NET Framework和.NET Core，但是与@terrajobst进行的Twitter对话以及发现这些软件包的结合使我改变了计划，而是针对了netstandard2.0 。

我不介意不能保存太多的动态程序集-我总是可以在.NET Framework TFM中测试逻辑-但是DynamicMethod非常有用，并且非常广泛地用于生成反射类，转换器委托等。System.Reflection.Emit。*软件包的下载量高达20,000,000。

请带回一种方法来引用netstandard2.0库中的DynamicMethod 。

既然未将其列为软件包，我们如何在.NET Core中使用DynamicMethod？

@danielcrenna您不需要包就可以在.Net Core上使用DynamicMethod ，因为它是内置的。 您只需要该软件包即可在.Net Standard上使用它。

我可以用System.Reflection.Emit.Lightweight 4.3，因为我用DynamicMethod的上.netstandard 2.0建立我的运行时间（这已经释放）。 现在，我看到构建过程从离线缓存而不是nuget提取软件包。 〜如果关闭了脱机缓存，我将无法再次为.NETstandard构建代码。〜（选择缓存确实会使构建过程再次拉出程序包，因为该程序包仍在此处，尽管未列出，所以它不是展示从技术上讲。

在这里查看： https :

因此，当我以.netstandard2.0为目标并使用DynamicMethod时，我可以引用System.Reflection.Emit.Lightweight，尽管它未列出并在ns1.6（？）中受支持，但是感觉确实不对：感觉就像责任，因为我现在依赖于未列出的软件包（然后我希望希望未列出的软件包一直保存到时间结束。）可悲的是：除了依赖未列出的软件包外，别无选择，只能因为知道确切的名字。

// @terrajobst

补充说明：EF Core 2.1的代理依赖于Castle.Core（https://www.nuget.org/packages/Castle.Core/），它依赖于System.Reflection.Emit。

让所有相关人员简单地再次征募这个软件包（和Emit.Lightweight），是否明智？

@FransBouma严格来说，EF Core代理具有依赖性，而不是EF Core本身。 但这还是一团糟。

实际上_FirebirdClient_依赖于_System.Reflection.Emit_。 现在该怎么办，对吗？

虽然可以理解的是，完整的AOT平台不允许在运行时生成新类型，但令人惊讶的是，我们不能在这些平台上支持System.Reflection.Emit.Lightweight 。
LambdaExpression.Compile()即使在AOT上解释，也可以在所有平台上使用。

我是LightInject DI库的作者，它使用Reflection.Emit和DynamicMethod在运行时生成代码。 在这些其他平台开始出现之前，一切都很好。 SilverLight，WinRT，iOS等。 那么该怎么办？ 我所做的是“匀衬” DynamicMethod以便将操作码转换为表达式。 操作码和表达式之间存在一种1-1关系，因此一点也不难。

在这里查看实现。
https://github.com/seesharper/LightInject/blob/a01be40607761d9b446dc4acad37d7f717742975/src/LightInject/LightInject.cs#L4483

请注意，我并没有实现所有的操作码。 只有我需要的。

我的观点是，应该有可能对所有操作码执行此操作，然后使许多库仍以netstandard2.0为目标。 大多数使用Reflection.Emit的库不会生成新类型。 他们只是通过DynamicMethod生成代码

还要注意，DynamicProxy，Moq和其他在运行时生成类型的库不能以netstandard2.0 。 他们必须是netcoreapp因为他们基本上依靠与朋友一起使用的AssemblyBuilder
因此，底线是System.Reflection.Emit.Lightweight软件包永远不能完全从netstandard2.0从NuGet中删除。 那将再次成为LeftPad的故事

我的两分钱

是否存在确实支持System.Reflection.Emit的TFM列表？ 我刚刚在项目中添加了net45和netcoreapp2.0显式TFM，但是我确定我缺少一些。

@jbogard除了netcoreapp TFM之外，所有完整的框架TFM都应该不错。 这是在AutoMapper中吗？

这似乎是一个经过深思熟虑并无法传达的决定，产生了深远的影响，似乎是在很少受到社区影响的情况下做出的，考虑到这些软件包下载了2200万，这令人惊讶。 难道不应该对目前取决于它的每个人的潜在影响进行某种分析吗？

ServiceStack在ServiceStack.Text中引用了现已取消列出的Reflection.Emit软件包，该软件包是有效地用于netstandard2.0和net45构建，强制定位.netcore平台会破坏每个依赖关系以及每个使用它的netstandard2.0项目-即用于创建跨平台的首选目标框架支持.NET Framework和.NET Core的内部版本。

那么对于使用Reflection.Emit的软件包有何建议？ 停止发布.NET Standard 2.0构建，并告诉所有人他们不再可以为其库和项目创建.NET Standard 2.0构建吗？

使用未实现该API的.NET标准API的先前解决方案是引发PlatformNotSupportedException运行时异常，为什么这不是解决方案？

@seesharper是的，我添加了这些内容，但可能会忽略其他内容。 API文档列出了更多内容，但可能还会缺少哪些内容？ 那是支持API的可能TFM的完整列表吗？ 假设xamarinxboxone呢？

我已经使用Lambda.Compile（）解决方案重构了我的DynamicMethod / ILGenerator代码，该代码用于在运行时为属性发出setter方法，因此对Reflection.Emit的依赖现在消失了，但是我不得不花3-4个小时我本来想花在其他事情上的。 但是，a，我猜这就是生活中的事物“快速移动并经常中断”的时候吗？

无论如何，我感到有些不安的是，过去几周来，Microsoft人员对此线程充耳不闻。 当实际上可以改变事物的人不在时，感觉就像在房间里辩论事物。

我完全同意@mythz和这里的其他人的

@mythz我不知道您如何使用它，但是对于我的东西，我不得不恢复为#if功能标记以删除不支持动态构建类型的平台中的功能（在我的库中，能够映射到接口，并且可以动态创建代理）。

@jbogard我们使用Env.SupportsEmit布尔值标志在运行时确定平台是否支持Reflection.Emit，如果使用，则回退到编译表达式。 关于这一点，如果有一个Platform.SupportsEmit标志，每个人都可以用来检查运行的平台是否支持Reflection.Emit，那将很有用。

#if指令将需要创建多个平台构建，这将是针对目标.netstandard2.0所有依赖包和项目造成重大变化的原因，因为它们还需要.netstandard2.0依赖关系。

为了进一步讨论，我想确保我们在System.Reflection.Emit和System.Reflection.Emit.Lightweight之间的差异时都在同一页上。

该问题实际上应该已经分为两个单独的问题。 😄

• 是否应该有.Net Standard 2.0版本的Reflection.Emit？
• 是否应该有System.Reflection.Emit.LightWeight的.Net Standard 2.0版本？

系统反射

该软件包包含AssemblyBuilder和相关类，我们需要在运行时生成程序集/类型。
此程序包的问题在于，它永远不应该作为netstandard程序包放在NuGet上，因为在运行时生成新类型不能在完整的AOT平台上支持。
我的猜测是，Microsoft将其添加为netstandard软件包，以便更轻松地从完整框架迁移到.Net Core和netstandard库。 事后看来，这并不是最好的主意。
“诱饵和切换”方法（全世界大约有5个人理解）也不是一个很好的解决方案。

系统反射光重量

此程序包包含DynamicMethod，无需创建新类型即可动态编译代码。 “动态方法”基本上是静态方法，我们可以为其创建用于调用该方法的委托。
LambdaExpression.Compile基本上是相同的，如果我们看一下整个框架的实现，我们会发现它实际上使用了DynamicMethod 。
问题是，使用AOT上的解释功能， LambdaExpression.Compile()可以在所有平台上工作。 因此没有理由我们不能创建一个System.Reflection.Emit.LightWeight包是netstandard使用我先前在本主题中描述的技术。

我的猜测是，现在对此进行回溯的原因是要确保该标准将来确实具有任何意义。 我所看到的问题是，我们可能会看到针对netcoreapp而不是netstandard库包，而在涉及整个netstandard概念时，这确实很糟糕。 。

我的建议是努力将System.Reflection.Emit.LightWeight作为真正的netstandard软件包发布，并在netcoreapp时继续争取System.Reflection.Emit 。

@seesharper据我所知，Reflection.Emit（包括Reflection.Emit.Lightweight）主要用于性能。 但是，如果使用IL解释器实现Reflection.Emit.Lightweight，则其性能可能会很差。 因此，我不认为在Reflection.Emit.Lightweight中支持IL解释模式的努力是合理的。

同样奇怪的是System.Reflection.Emit.ILGenerator仍然被列出（https://www.nuget.org/packages/System.Reflection.Emit.ILGeneration），因为它是netstandard1.6软件包，但是ILGenerator没有UWP实现（https://apisof.net/catalog/System.Reflection.Emit.ILGenerator）。

艾奥：有点混乱，天生？

@seesharper好的建议。

@svick我认为这不足以削减它。 特定领域的语言需要一种在运行时构造代码的功能。 DSL在规模较大的项目中经常出现（格林斯潘的第十条规则），如果每个作者都不必为此发明和编写自己的解释器（使用常规反射和Invoke ），那就更好了。 如果它是标准组件，则至少可以缓解规则的“非正式指定且漏洞百出”的部分。 至于以AOT为目标的实现的性能，它不必是IL解释器。 即使在不允许进程创建可执行内存页的平台上，也可以像许多FORTH实现一样将动态方法编译为线程代码，而对于“方法主体”适合几个高速缓存行的小型动态方法，运行时开销应该很低。

该软件包的问题在于，它绝不应该作为网络标准软件包放在NuGet上，因为在运行时生成新类型不能在完整的AOT平台上支持。

不同意。 主要的.NET Core和.NET Framework平台都支持它，只是因为AOT环境不应该阻止它支持以netstandard2.0目标的主要.NET平台。

现在这已成为.NET Standard前进的策略吗？ 现在要删除AOT环境中不支持的API吗？ 这样就不会再有PlatformNotSupportedException例外了，API会被淘汰，而是转回PCL子集吗？ 还是我们会变得不一致，有选择地减少某些功能的API表面，而继续添加其他功能？

PCL做到了支持最低公分母API的交集，并带来了可怕的开发经验，这迫使PCL诱饵和转换技术并委托给多个平台特定的实现，这是我们搬到时所放弃的全部投资。 NET标准。

最好的解决方案是现有的解决方案（尤其是因为现在将其删除是对其传递性部门的破坏性和突破性更改），这使我们能够在所有支持该平台的平台上使用Reflection.Emit，同时需要为那些不支持该功能的平台实施后备。 在.NET Standard中删除使用Reflection.Emit的功能意味着使用它的库不再可以以.NET Standard为目标。 如果我们不能在与平台无关的抽象中使用.NET Core和.NET Framework共享的功能，那还有什么意义呢？ 这只会给.NET生态系统带来不必要的抽象/混乱/复杂性。

感谢大家的反馈。 根据压倒性的反馈，我们重新列出了现有软件包的最新版本：

https://www.nuget.org/packages/System.Reflection.Emit/4.3.0
https://www.nuget.org/packages/System.Reflection.Emit.Lightweight/4.3.0

但是，如本线程前面所述，这些软件包声称与netstandard1.1兼容，但这是一个谎言。 它们仅适用于.NET Core和.NET Framework。 因此，如果您从netstandard库中使用它们，则期望该库在任何其他.NET Standard实现上运行时都会失败。

我们仍然没有很好的解决方案来在netstandard2.0上支持它们，但是System.Relfection.Emit的所有者（ @AtsushiKan @joshfree）将尝试找出更长期的解决方案。

@svick

据我所知，Reflection.Emit（包括Reflection.Emit.Lightweight）主要用于性能。 但是，如果使用IL解释器实现Reflection.Emit.Lightweight，则其性能可能会很差。 因此，我不认为在Reflection.Emit.Lightweight中支持IL解释模式的努力是合理的。

据我了解， LambaExpression.Compile()及其执行是在AOT平台上解释的，因此对于System.Reflection.Emit.LightWeight做它应该不会更糟。
有很多使用此软件包的库，拥有“真正的” netstandard2.0软件包会突然使这些软件包在您的iPhone上运行，而不会强迫这些软件包的开发人员重写其代码以匹配不同的平台。 性能可能会降低，但仍然可以像今天一样使用LambdaExpression.Compile()

@mythz

现在这已成为.NET Standard前进的策略吗？ 现在要删除AOT环境中不支持的API吗？ 因此，将不再有PlatformNotSupportedException异常，API将被取消，而是移回PCL子集？ 还是我们会变得不一致，有选择地减少某些功能的API表面，而继续添加其他功能？

恕我直言，抛出PlatformNotSupportedException只是我们在PCL中看到的API子集的另一个体现。 由于System.Reflection.Emit.LightWeight就是这种情况，我们实际上可以实现它，没有理由抛出PlatformNotSupportedException 。 但是，我确实同意，能力不足的平台会限制标准的发展是有问题的。 但这就是制定标准的本质。 在对标准进行添加时，必须确保至少可以以某种方式由实施该标准的平台来实施。 至少在主要参与者中，Xamarin属于这一类。

我认为，今天的这一数字是个谎言。 Xamarin声称支持netstandard ，但是这种支持充满了例外，对我们来说这似乎是合理的。 对于新手来说，可能不那么容易理解。

@weshaggard

从长远来看，继续以netstandard包的形式发布System.Reflection.Emit并不是一个好的解决方案。 它再次使标准为“ false”，并且仅可用于net / netcoreapp。 吞咽是一种苦药，相信我，我知道。 我对'LightInject.Interception'有完全相同的问题，它是使用System.Reflection.Emit的代理库。 但是我宁愿将netcoreapp目标定位在向消费者撒谎，因为这个库可以在任何地方运行。

@seesharper

恕我直言，抛出PlatformNotSupportedException只是我们在PCL中看到的API子集的另一个体现。 就像System.Reflection.Emit.LightWeight一样，我们实际上可以实现它，并且没有理由抛出PlatformNotSupportedException。

它们根本不相等。 .NET Standard之所以有用的唯一原因是因为它的API范围更大，它使我们能够创建一个可以在多个平台上运行的内部版本。 PCL的用处不大，因为其减少的API交集子集强制创建了针对非平凡功能的多个平台特定版本。 它们的功能不尽相同，导致的解决方案在库作者和使用者方面的复杂性也大不相同。使用.NET Standard，我们可以在所有平台上运行单个构建，因为我们可以在运行时检查平台是否支持Reflection.Emit，如果不是的话，我们将退回到Lambda Expressions和Reflection。 如果.NET Standard库无法使用这些API，我们将无法拥有一个单一的构建，因此需要回到开发和维护非便携式平台特定的构建。

从长远来看，继续将System.Reflection.Emit作为netstandard程序包发布不是一个好的解决方案。 它再次使标准为“ false”，并且仅可用于net / netcoreapp。

尤其是，强迫创建和依赖于特定于平台的版本的结果要差得多。 已经有很多传递依赖项依赖它。 .NET Standard的主要好处是能够创建库和项目以针对单个有用的抽象，如果我们不能使用它访问.NET Core和.NET Framework中可用的主流功能，则它无法解决其主要用途-case，也可能不存在，因为它只是向.NET生态系统添加了更多抽象/混乱，而没有PCL的任何好处。

PCL已经尝试绑定到抽象，该抽象仅公开每个平台上可用的API功能的交叉点，这实际上是您要返回的内容，因为您只能访问每个平台上可用的API，并且扩展名仅包含API在最受限制的平台上可用。

在.NET Standard中拥有更广泛的API Surface更加有用，它使库作者可以自由选择他们希望如何处理对不同平台的支持，如果这些API不可用，那么该选项将不存在。强制执行特定于平台的构建，并强制其所有依赖的库和项目也维护特定于平台的构建，这增加了摩擦，碎片，减少了可移植性，并且仅对作者选择维护构建的平台提供支持，而对所有支持.NET Standard的平台都提供了支持该功能。

这不仅仅是优先考虑的问题，删除主流API支持对可用的解决方案具有深远的破坏性影响，迫使不必要的特定于平台的版本影响库的实用性，同时破坏使用它们的每个.NET Standard库和项目。

@weshaggard

我们仍然没有很好的解决方案来在netstandard2.0上支持它们，但是System.Relfection.Emit的所有者（ @AtsushiKan @joshfree）将尝试找出更长期的解决方案。

如何告诉iDiots和控制怪胎谁在使用其平台的每个人上强制仅使用AOT，他们需要制定并修复不良的平台规则？ （因为说实话，我们都知道这才是真正的意义：移动世界中一些非常具体的坏演员。）

@mythz，您说得对。

@masonwheeler

我完全理解，考虑到它导致的脱落，隐藏ref发射包令人沮丧。 我也了解到，我们为您不关心的执行环境进行优化可能会令人沮丧，尤其是当这包括对您关心的方案造成负面影响的权衡时。

话虽如此，我已将您的评论标记为“侮辱性”，因为它不是建设性的。 侮辱人不会解决这些问题。 还要考虑这不是我们控制的政策。 您不能在iOS上的运行时生成和执行代码的事实是Apple的一项政策决策。 而且，在某些情况下，这不是政策限制，而是技术限制。

有反射发射的三个选项：

1. 修复当前软件包，并使它们在.NET Standard 2.0之上运行。 问题是.NET Standard 1.x中的Type和TypeInfo之间的怪异的继承关系与2.0相比并具有非公共构造函数。 我可以更详细地介绍，但是要使该软件包实际上可构建而又不还原黑客，则有些棘手，这就是我们最初决定隐藏该软件包的原因。

2. 将反射发射添加到.NET Standard vNext 。 为了支持仅AOT的方案，这可能会包含一个功能API，该功能API可使使用者检查代码生成是受支持的还是有效的（即，我们使用的是真实执行而不是解释）。

3. 不将反射辐射暴露于.NET Standard，并要求库作者具有多个目标。 当我们开始隐藏软件包时，这基本上是原始路径。

目前，我们倾向于第一种选择，但第二种选择也在讨论中。

我赞成2。它无处不在，应该在那里。 无论如何，由于其他原因，我们需要进行功能检查。

我赞成2。它无处不在，应该在那里。 无论如何，由于其他原因，我们需要进行功能检查。

我也是，但它对目前依赖.NET Standard 2.0的任何人都没有帮助，因为这需要标准的新版本。 但是，有关的API已经存在。

因此，我正在考虑一个最小修复程序，以使此程序包按原样工作，而且还可以修复.NET Standard 2.0 vNext。

@terrajobst关于选项1的某些事情使选项2变得更难执行了吗？ 在我看来，获得针对netstandard2.0的软件包版本而不是需要引入netstandard1.1软件包图表是一个不错的短期目标。 然后，对于标准的vNext，它可以成为其中的一部分，并且您将不再需要这些软件包。

因此，除非有确凿的理由不这样做，否则我都投票支持1和2。

@无聊

看起来我们几乎同时发布了。 希望我的评论解决您的问题:-)

请注意， netstandard2.0支持System.Reflection.Assembly.Load(byte[] rawAssembly)静态方法，该方法从二进制图像字节数组加载程序集。 这意味着有可能在纯netstandard2.0下实现不是所有的System.Reflection.Emit API兼容。

（对不起，我不知道有多少平台Assembly.Load没有PNSE的情况下支持

@GlassGrass您认为netstandard2.0实现适用于哪些框架？

我当然可以想象某些实现会写出IL并产生像API驱动的ILASM这样的程序集的实现，但是我看不到要使用它的当前框架。

具有JIT（并支持Assembly.Load）的框架也可以直接支持Ref.Emit，并提供其Ref.Emit实现而不是netstandard2.0版本。 我知道至少台式机/.netcore/.netnative就是这种情况。 前两个支持ref.emit并提供一个实现，后一个不支持，也没有JIT，也不支持动态程序集加载。

我确实认为对于在corefxlab中玩耍的人来说，在类似于Ref.Emit（或更好）的System.Reflection.Metadata之上编写一些东西是一个有趣的项目。 不知道是否有人在看那个。 / cc @nguerrera @tmat

我确实认为对于在corefxlab中玩耍的人来说，在System.Reflection.Metadata之上编写类似于Ref.Emit（或更高版本）的东西将是一个有趣的项目。

那是我的盘子：（https://github.com/dotnet/corefx/issues/4491和https://github.com/dotnet/corefx/issues/2800）

https://github.com/dotnet/corefx/issues/2800将是第一个，因为ref发出的东西可能是它的扩展。 我本周开始对2800进行原型制作，并将在接下来的几个月中继续进行这项工作。 在我走得更远之前，我不会将其移至corefxlab。 就我的口味而言，工作流程效率太低。

@AtsushiKan ：很高兴看到在此问题上仍在进行中。 感谢您解决此问题。

我以前在其他地方提到过以下内容： System.Reflection.Metadata和Assembly.Load(byte[])不能做的一件事是逐个增量发射。 您不能发出一种类型，然后发出另一种类型……您只能发出完整的程序集，这对于例如依赖于动态代理类型生成的模拟库而言，这并不是太有用。

当然，一个人只能产生单一类型的程序集，但是当通过[assembly: InternalsVisibleTo]使内部对动态生成的程序集可见时，这可能会变得效率低下和困难（模拟/测试库经常需要这样做）。 您必须能够为多个动态单类型程序集赋予相同的标识/强名称，才能使其正常工作。 （实际上，运行时可能已允许这样做，但是我找不到正式确认它的文档。）

@stakx您可以向动态程序集发出System.Runtime.CompilerServices.IgnoresAccessChecksToAttribute ，以允许它访问指定程序集的非公共成员，而不是使用IVT。

@tmat ：这很有趣。 此属性是否已正式记录在某处？

遗憾的是，这个特殊属性尚未正式记录，有点使在运行时之外使用它有点赌博。

会将其添加到.NET core 3.0吗？

cc @steveharter @joshfree

@karelz https://github.com/dotnet/corefx/issues/30654跟踪3.0版的工作

@joshfree这是一个

@karelz涵盖了该问题，其中Ref.Emit程序包从nuget中被错误地删除，然后该程序包被@weshaggard重新列出。 我认为这个问题现在可以解决，因为使用dotnet / corefx＃30654跟踪剩余的工作。

OK，然后关闭:) ...如上所述，在dotnet / corefx＃30654中跟踪其余工作。