Support CoreCLR

[jbogard]

I spiked this out, the biggest issue will be getting the Mono.Reflection dependency. You'd either need to switch to the MS packages or get that package updated.

[daveaglick]

👍 I appreciate you taking the time to figure out what it would take. I use this library like crazy and it's going to end up being a blocker for moving to .NET Core on a lot of my work-related projects (though that won't even be on the table for a long while).

[hazzik]

@jbogard, probably I will internalize the Mono.Reflection or switch to some other decompiler (Roslyn/Cecil/ILSpy - not sure yet).

[hazzik]

@jbogard @daveaglick I would happily accept a pull request

[rondefreitas]

@jbogard @hazzik looks like the assembly-saver branch of Mono.Reflection has some recent changes that address issues in vNext/Core specifically. Might be able to get @jbevain to put out a new release?

[https://github.com/jbevain/mono.reflection/tree/assembly-saver]

[hazzik]

@Rdefreitas I dont think that .NET Core has .GetMethodBody() method

[rondefreitas]

@hazzik if I'm not mistaken, GetMethodBody is internal but there is the MethodBody property of the MethodImplementation struct.

https://github.com/dotnet/corefx/blob/release/1.0.0-rc1/src/System.Reflection.Metadata/src/System/Reflection/Metadata/MethodImplementation.cs

[jbevain]

@Rdefreitas System.Reflection.Metadata is a fully managed metadata reader, it's completely separate from the traditional System.Reflection.

If .NET Core doesn't have GetMethodBody(), Mono.Reflection is going to be difficult to port.

[rondefreitas]

@jbevain, my apologies, it seems you're correct. I came across this issue in dotnet/corefx#4543, which mentions that .NET Native won't have access to retrieve MetadataTokens... I would assume this is the reason for the lack of GetMethodBody().

(@nguerrera - https://github.com/dotnet/corefx/issues/4543#issuecomment-157491151 ) You can use GetMetadataToken() from System.Reflection.TypeExtensions and then drop down to System.Reflection.Metadata to get the IL. I'll post a gist later tonight. Keep in mind that tokens will not be available on .NET Native if you're also expecting this to work there.

---

Having a windows-only version of Mono.Reflection would kind of defeat the purpose of even having Mono in the name. 👎 Although, maybe having a subproject that is temporarily limited wouldn't be all bad and would at least get the ball rolling (with a delay for cross-platform functionality)... perhaps Mono.Reflection.CoreFx. @hazzik, is DelegateDecompiler Mono-friendly or just using the lib?

---

Anyway, I was led down this road through a need to see @AutoMapper EF6 extensions ported to EF Core... I'm happy to contribute to make this happen, I just need to find the right starting point.

[zsvanderlaan]

I would also like to see .net core support for use with Automapper EF extensions and would be happy to help contribute if anyone can point in the right direction.

[jbogard]

@zsvanderlaan we're all waiting for .NET Standard 2.0/.NET Core 2.0 to drop. That's where GetMethodBody comes back. Then this will need to target netstandard20.

[zsvanderlaan]

In case anyone else is not familiar with this, i did some research, and from what I understand .net core 2.0 will run on top of .net standard 2.0, which is cross platform. .net standard 2.0 is the framework layer where GetMethodBody is defined, and so once .net standard 2.0 is released (suspected May 10th at Build) the Delegate Decompiler library (and its Mono.Reflection dependency) should be able to target .net standard 2.0 instead of the full .net framework currently being referenced.

[hazzik]

Btw, I made a PR to support .NET Standard 2.0 to Mono.Reflection: jbevain/mono.reflection#16

[tb-mtg]

Hi guys, Are there any updates now that .NET Standard/Core 2.0 specifications are complete?

[hazzik]

@tb-mtg I'm waiting on Mono.Reflection dependency. However you can easily reference DelegateDecompiler/Mono.Reflection from .NET Standard 2.0 assembly using compatibility mode

[derigel23]

DelegateDecompiler.EntityFramework should reference Microsoft.EntityFrameworkCore for .NET Standard/Core 2.0 or better introduce new package DelegateDecompiler.EntityFrameworkCore?

[jbogard]

New package.

…

On Fri, Jan 5, 2018 at 10:05 AM Slava Trenogin ***@***.***> wrote: DelegateDecompiler.EntityFramework should reference Microsoft.EntityFrameworkCore for .NET Standard/Core 2.0 or better introduce new package DelegateDecompiler.EntityFrameworkCore? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#66 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGYMnIJI3V15PvIhiXBqujtnBChN8zeks5tHkhVgaJpZM4G9A3R> .

[mbrookson]

Is there any update or progress on .NET Core / .NET Standard 2.x support?

[eveneveneven]

Are you still waiting for Mono.Reflection dependency? Will that even happen this year?
I'm eagerly awaiting support for EF Core :)

[hazzik]

I had to release own version of Mono.Reflection to be able to proceed.

[hazzik]

I've released DelegateDecompiler.EntityFrameworkCore.