Should there be a .Net Standard 2.0 version of Reflection.Emit?

[svick]

System.Reflection.Emit is not part of .Net Standard, but there are packages that let you use it from a .Net Standard library (specifically, System.Reflection.Emit and System.Reflection.Emit.Lightweight). But those packages do not have a .Net Standard 2.0 version, only .Net Standard 1.x versions.

This has some implications:

• .Net Standard 2.0 libraries can't use typeBuilder.CreateType() (even though this code works both on .Net Framework 4.6.1 and .Net Core 2.0) and have to use typeBuilder.CreateTypeInfo().AsType() instead. It's possible there are also other APIs like this.
• .Net Standard 2.0 libraries that want to use Reflection.Emit still have to use .Net Standard 1.x-style System.* packages.

These issues would be solved if a .Net Standard 2.0 version was added to Reflection.Emit packages. Is that something that would be worth doing?

Though both of these are fairly small quibbles, so I'm not sure how much value would doing this add.

[karelz]

@ericstj @weshaggard do you know if it is on purpose this way, or an oversight?

[ericstj]

It was intentional. For libraries like this that have jagged support and no portable implementation we stopped shipping packages. The expectation is that you target a specific framework if you need it. For some we have brought back packages with land mines (throwing implementations on some platforms). Folks could propose we add it back but this one in particular has had some stong debate in the past due to lack of support on all AOT based .net frameworks. /cc @terrajobst

[svick]

@ericstj

The expectation is that you target a specific framework if you need it.

How am I supposed to learn about that? As far as I can tell, Reflection.Emit is not reported by platform-compat. And when I google "reflection emit .Net Standard", the only result on the first page talking about whether you should use it that way is a tweet from July 2017 by @terrajobst suggesting that you should do it (maybe the situation changed since then?).

[ericstj]

I’ll let @terrajobst respond to that, perhaps he was thinking about the nuget gaurdrails feature we had in 1.x and the 1.x packages. With those we had jagged implementations and build time support for messaging that things aren’t supported. I’m not particularly leaning one way or the other here just explaining the way things are working at the moment. I think if we can get sign off from folks on adding back a package with a platform not supported implementation we could do so.

FWIW anything that’s available in a framework but isn’t in netstandard or in a library/package with a netstandard asset means you need to target the framework to get it. That’s all I meant with my expectation comment.

[svick]

@ericstj

anything that’s available in a framework but isn’t in netstandard or in a library/package with a netstandard asset means you need to target the framework to get it. That’s all I meant with my expectation comment.

But here the package (with .Net Standard 1.x assets) does exist. I don't think you can just stop updating a package and assume people won't use it anymore. At the very least, you should have documentation explaining the situation.

[weshaggard]

The biggest trouble with System.Reflection.Emit is that we don't have a way to provide the library in a netstandard way because of TypeInfo (see https://github.com/dotnet/corefx/issues/14334). The existing package is targeting netstandard1.1 but it is a lie and will only work on .NET Framework and .NET Core because of the tight coupling we have. We hacked it to work by playing InternalsVisibleTo tricks to give it access to TypeInfo's constructors, but that same trick is what makes it not work on a general .NET Standard platform. We decided to not propagate the error further by hacking netstandard2.0 in the same way and instead stopped producing the package and made it platform specific.

Thanks for raising the issue @svick and we should use this issue to document the trouble with the package.

[akoeplinger]

What about unlisting the no longer updated packages on NuGet so it's clear they are not recommended?

[weshaggard]

That is a reasonable suggestion. I just unlisted all the versions of https://www.nuget.org/packages/System.Reflection.Emit/ and https://www.nuget.org/packages/System.Reflection.Emit.Lightweight

[masonwheeler]

This is very needed. Not being able to build and save assemblies is currently my dotnet/corefx#1 biggest blocker for updating to .NET Core, and I'd really like to see getting this very fundamental API up to speed made a higher priority than working on new features.

[weshaggard]

@masonwheeler just to call out you can use Reflection.Emit if you are writing .NET Core app or library you just cannot use it while writing .NET Standard library currently.

[masonwheeler]

@weshaggard are you sure? I just checked the repo, and it appears that not only is AssemblyBuilder.Save not implemented yet, it doesn't even exist at all on Core! (I might be wrong; I'm on my phone and GitHub's mobile interface isn't the best, but that's what it looks like.)

[weshaggard]

@masonwheeler you're correct that we don't support AssemblyBuilder.Save in .NET Core that is being tracked by another issue https://github.com/dotnet/corefx/issues/4491.

[masonwheeler]

There it is! I thought I had seen that issue before, but searching only turned up this one. :P

But yeah. Without the ability to actually emit your results, you can't really say that you can use Reflection.Emit on Core. ☹️

[SergeyKhutornoy]

@weshaggard before the System.Reflection.Emit.Lightweight package being unlisted on nuget.org it was possible to get Selenium.WebDriver package in PowerShell 5 (for .Net Framework) and PowerShell Core 6 (for .Net Core 2.0) on Windows 10 using the following command: Install-Package Selenium.WebDriver -Destination $PSScriptRoot -Force -ForceBootstrap

Now this command cannot download all the Selenium package dependencies for both PowerShell versions. It fails because System.Reflection.Emit.Lightweight.4.3.0 package is unlisted on nuget.org.
Error: Install-Package : Unable to find dependent package(s) (System.Reflection.Emit.Lightweight)

Could you advise on how to fix this issue?

[weshaggard]

@SergeyKhutornoy are you calling "Install-Package" in VS from the Package Manager Console? If so that correctly installs the package for me. If you are calling Install-Package from Powershell that is a different kind of package management. I actually just tried that locally and I get a different error (Install-Package : No match was found for the specified search criteria and package name 'Selenium.WebDriver'.) I'm not familiar with that package management system so I'm not sure how to work around it. One thing you could try is to explicitly install System.Reflection.Emit.Lightweight 4.3.0 first and then see if it works. If that doesn't work is there a reason you cannot use VS or nuget tools to install the package?