.net core support?

[jollescott]

Hi, just wondering if you have done any testing on .net core yet?

[ghost]

We have not. But it's the same IKVM as before with 1 very small bug fix so it should be the same answer as the main IKVM branch.

Which I believe is - it doesn't run on .NET Core.

[fanoI]

Hello!

Do you have intention to port IKWM.net to Net Core in the future?

[ghost]

We also would love to see it ported to .NET Core. Unfortunately we don't have the resources to do so at present.

Have you considered doing it?

[mikeTWC1984]

Actually IKVM is almost 100% compatible with Core/Net.Standard (based on api analyzer tool). You can add those assemblies to core project. IKVM.OpenJDK.dll rely on one of the constructors of System.IO.FileStream which is not ported to core, which seemed to be the only major dependency. I opened an issue with corefx to add it. IKVM.Runtime.dll has references to several methods from System.Reflection.Emit (see below). Any Idea what Emit API is used for in IKVM? All other assemblies seemed to be 100% compatible.

Target type	Target member	Header for assembly name entries	.NET Core + Platform Extensions	.NET Core	.NET Standard + Platform Extensions	Recommended changes
T:System.Reflection.Emit.MethodToken	T:System.Reflection.Emit.MethodToken	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.MethodToken	M:System.Reflection.Emit.MethodToken.get_Token	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.FieldToken	T:System.Reflection.Emit.FieldToken	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.FieldToken	M:System.Reflection.Emit.FieldToken.get_Token	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.TypeBuilder	M:System.Reflection.Emit.TypeBuilder.AddDeclarativeSecurity(System.Security.Permissions.SecurityAction,System.Security.PermissionSet)	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.FieldBuilder	M:System.Reflection.Emit.FieldBuilder.GetToken	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.ModuleBuilder	M:System.Reflection.Emit.ModuleBuilder.DefineDocument(System.String,System.Guid,System.Guid,System.Guid)	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.ILGenerator	M:System.Reflection.Emit.ILGenerator.MarkSequencePoint(System.Diagnostics.SymbolStore.ISymbolDocumentWriter,System.Int32,System.Int32,System.Int32,System.Int32)	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.IO.FileStream	M:System.IO.FileStream.#ctor(System.String,System.IO.FileMode,System.Security.AccessControl.FileSystemRights,System.IO.FileShare,System.Int32,System.IO.FileOptions)	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.MethodBuilder	M:System.Reflection.Emit.MethodBuilder.AddDeclarativeSecurity(System.Security.Permissions.SecurityAction,System.Security.PermissionSet)	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.MethodBuilder	M:System.Reflection.Emit.MethodBuilder.GetToken	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.AssemblyBuilder	M:System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(System.String,System.Boolean)	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.AssemblyBuilder	M:System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(System.String,System.String)	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.AssemblyBuilder	M:System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(System.String,System.String,System.Boolean)	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.Reflection.Emit.AssemblyBuilder	M:System.Reflection.Emit.AssemblyBuilder.Save(System.String)	IKVM.Runtime	Not supported	Not supported	Not supported
T:System.AppDomain	M:System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName,System.Reflection.Emit.AssemblyBuilderAccess,System.String,System.Security.Policy.Evidence,System.Security.PermissionSet,System.Security.PermissionSet,System.Security.PermissionSet,System.Boolean,System.Collections.Generic.IEnumerable{System.Reflection.Emit.CustomAttributeBuilder})	IKVM.Runtime	Not supported	Not supported	Not supported	Use AssemblyBuilder.DefineDynamicAssembly
T:System.Reflection.Emit.LocalBuilder	M:System.Reflection.Emit.LocalBuilder.SetLocalSymInfo(System.String)	IKVM.Runtime	Not supported	Not supported	Not supported

[timotei]

FYI, I am looking into seeing if I can build IKVM against .NET Standard 2.0 (so that we can use it from both .NET Framework and .NET Core) and while solving some of the issues, it seems not all have a proper solving. Truth be told, I'm doing this on an older version for now (java 6-based): 0.46. I saw some commits in the master branch that tried to enhance the .NET Standard support/

The reflection parts can be easily solved by using the System.Reflection NuGet packages.

[ams-tschoening]

I opened an issue with corefx to add it.

https://github.com/dotnet/corefx/issues/39920

[ams-tschoening]

If anyone is interested, I've created a branch in my fork of IKVM trying to get things running with .NET Core: https://github.com/ams-ts-ikvm-bag/ikvm/tree/nant_build_net_core

Some usages of the not available CTOR of System.IO.FileStream could be ported to other CTORs to at least successfully read files. The CTOR is only used to get atomic appends to files, which one might simply not need.

Additionally I found that some cases breaking the UWP-app are code which is specially targeting .NET 4.0, so I simply undefined using that in the build files and got some more compatibility. At some places it's difficult to decide why things have been implemented specially for 4.0 as the GIT-history lacks details, code simply occurs.

This allowed me to run my PoC of a Java-lib reading YAML files, parsing some data, using Google Guava-caches and stuff successfully in the end.

[mikeTWC1984]

@ams-tschoening Very interesting. Any chance you can publish binaries?

[ams-tschoening]

I've added a branch, but consider this completely internal work for now. I will surely reorganize things to better fit my needs. Not even sure about tracking things in those repos at all in the long term, the formerly main intention for the repos was to simply backup everything I could find regarding IKVM.

https://github.com/ams-ts-ikvm-bag/ikvm-bin/tree/ts_build_net_core

[mikeTWC1984]

Just tested webclient and jdbc, and both are working now under .net core 2, fantastic! @jollescott @fanoI @timotei can you test your stuff too?

[timotei]

@mikeTWC1984 I am focusing on .NET Standard generation (which seems more tricky than .NET Core), but I will give it a try :)

So far I managed to get all (most?) of the IKVM.Runtime compile against .NET Standard, but the generation of the OpenJDK.*.dll seems a bit more trickier to get right since netstandard.dll references has either incomplete types definition or type forwarding, thus linking it with mscorlib/System.runtime directly. I'll publish what I did so far on my fork this week maybe.

[mikeTWC1984]

OK, good. I also tested updated IKVM on WSL and linux container and it works too ( yay:) ), so it's sort of netstandard already. Maybe we should consolidate all these updates and send PR on this repo

[ams-tschoening]

So far I managed to get all (most?) of the IKVM.Runtime compile against .NET Standard[...]

How did you do that? I simply reused the builds available for NAnt and wasn't able to address anything else then .NET 4. The project files for Visual Studio don't seem to target .NET Standard as well.

https://github.com/wwrd/ikvm8/issues/8#issuecomment-530845006

Maybe we should consolidate all these updates and send PR on this repo

I would prefer using a repo containing all the history of the original project as targets of PRs and asked to to change that. Other opinions?

https://github.com/wwrd/ikvm8/issues/11

[mikeTWC1984]

@ams-tschoening Agreed. Probably it make sense to have a separate fork that would focus on core/netstandard compatibility. You kind of created one already, let's see what @timotei got.

[ams-tschoening]

Depending on what wwrd says, we might consider simply creating a new organization for IKVM and fork the repos of interest from mine into that. If necessary at all, customized forks for .NET Core vs. other focus/implementations could easily be created within that than. Which I don't see necessary currently, though.

I won't have time to get too much involved into IKVM, so suggest that the organization is managed by others, like you or wwrd in the end. I only would like to see my work converting the repo not only useful for me. :-)

Any good orga-names in mind already? ikvm-[bag|maintenance|revived|...]

I suggest following the discussion in #11 as well.

[ams-tschoening]

I've added a branch, but consider this completely internal work for now.

I've deleted the old branch and created new ones, better named to (hopefully) not care about anymore for now. This one contains the fixes of wwrd as well, but I pretty sure to not maintain it intentionally.

https://github.com/ams-ts-ikvm-bag/ikvm-bin/tree/net_core_compat

[ghost]

Speaking for Windward our primary goal is to have a single repo everyone works on going forward. Having IKVM split into distinct repos would be very harmful for it's future.

On having a repo with more history, not an issue for us. But we are not opposed to it so fine with whatever the rest of you prefer. We're also fine if we use someone else's repo and they own it. We only did this because no one else did.

If we use another repo, we have 2 bug fixes in our repo and those need to be added to your repo if we make that the new main repo.

And we, along with you, need to get this to be .NET Core compatible. We were going to start in about 6 months and so we're thrilled if you all do it sooner.

[mikeTWC1984]

Regarding compatibility, after @ams-tschoening fixed the FileStream CTOR issue, looks like many jars can be ported to core now. Below is the list of missing methods (besides those in Reflection.Emit). They probably are not critical. I think we might need focus on testing now. I already tested some jdbc, I'm going to try BouncyCastle (encryption library) and HtmlUnit (headless browser) some time soon.

[timotei]

My current work is available here: https://github.com/Itiviti/ikvm/tree/v0.46-netstandard

Please note it's not in any way a "production" version yet, just want to get my foot in the door to see if .NET Standard is even viable, or we need to be either .NET Framework/.NET Core

[ams-tschoening]

@timotei

There's an new repo for IKVM now:

https://github.com/ikvm-revived/ikvm

I suggest you fork this, create a branch based on master and integrate your changes from your former repo into that new branch by cherry-picking. Just make your repo a remote for the new fork. I tried that already and ran into various conflicts which make me believe you might not have based your work on master of your repo or I simply don't understand it enough. :-) I didn't understand how your branch 0.46-netstandard relates to 0.47, which contains pretty new commits regarding IPv6, already.

If you think it might be of help I could push my branch, but I didn't even ran nant. It might be complete garbage, therefore I didn't push it yet.

The overall goal should be to create a branch called net_standard_compat like the already available net_core_compat. Afterwards people can decide which of those changes to merge into master and how to move forward.

[ams-tschoening]

Just want to add some notes that Reflection.Emit seems to be supported in .NET Core 3.0 again:

Reflection emit & capability APIs. This includes Reflection emit itself as well as two new properties on the RuntimeFeature class that allows you to check whether runtime code generation is supported at all (IsDynamicCodeSupported) and whether it’s compiled using a JIT or interpreted (IsDynamicCodeCompiled). This enables you to author .NET Standard libraries that can take advantage of dynamic code generation if available and fallback to other behavior when you run in environments that don’t have JIT and/or don’t have support for IL interpretation.

https://devblogs.microsoft.com/dotnet/announcing-net-core-3-preview-3/

.NET Core 3.0 ist die erste .NET-Variante, die .NET Standard Version 2.1 implementiert. Zu den neuen Klassen in .NET Core 3.0 gehören neben den Basisklassen für einige Sprachfeatures (z.B. System.Index, System.Range, System.Span, System.Memory, System.ValueTask) auch einige alte Tanten aus den Gründertagen von .NET wie die dynamische Codegenerierung mit Reflection Emit[...]

https://www.heise.de/developer/meldung/Microsoft-laeutet-mit-NET-Core-3-0-und-C-8-0-neues-Zeitalter-ein-4535758.html?seite=2

@mikeTWC1984

Maybe you want to give your formerly mentioned API-analyzer an additional try?

[timotei]

FYI, managed to compile everything (the IKVM.OpenJDK.*.dll) for .NET Standard and it seems work fine for some really basic tests I did :O I will push the rest of the work soon in the branch. It's also very hackish method to generate them, but hey, it works I guess.

@ams-tschoening The portability tool is here: https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer

Oh, and missed some earlier messages:

So far I managed to get all (most?) of the IKVM.Runtime compile against .NET Standard[...]

How did you do that? I simply reused the builds available for NAnt and wasn't able to address anything else then .NET 4. The project files for Visual Studio don't seem to target .NET Standard as well.

I had to update nant's config to use the new compiler paths, will share soon (this week hopefully, as I am wrapping up everything for anyone outside to be able to use it).

[mikeTWC1984]

@ams-tschoening I ran it recently, and didn't see the change. The namespace itself (Reflection.Emit) was there, but missing some methods/ctors. Below is the list. Not sure if the anything from that list was added on the most recent release, I'll do some analysis later.

Target type	Target member
T:System.Reflection.Emit.FieldToken	T:Reflection.Emit.FieldToken
T:System.Reflection.Emit.FieldToken	M:Reflection.Emit.FieldToken.get_Token
T:System.Reflection.Emit.MethodToken	T:Reflection.Emit.MethodToken
T:System.Reflection.Emit.MethodToken	M:Reflection.Emit.MethodToken.get_Token
T:System.Reflection.Emit.ILGenerator	M:Reflection.Emit.ILGenerator.MarkSequencePoint(Diagnostics.SymbolStore.ISymbolDocumentWriter,Int32,Int32,Int32,Int32)
T:System.Reflection.Emit.ModuleBuilder	M:Reflection.Emit.ModuleBuilder.DefineDocument(String,Guid,Guid,Guid)
T:System.Reflection.Emit.TypeBuilder	M:Reflection.Emit.TypeBuilder.AddDeclarativeSecurity(Security.Permissions.SecurityAction,Security.PermissionSet)
T:System.Reflection.Emit.AssemblyBuilder	M:Reflection.Emit.AssemblyBuilder.DefineDynamicModule(String,Boolean)
T:System.Reflection.Emit.AssemblyBuilder	M:Reflection.Emit.AssemblyBuilder.DefineDynamicModule(String,String)
T:System.Reflection.Emit.AssemblyBuilder	M:Reflection.Emit.AssemblyBuilder.DefineDynamicModule(String,String,Boolean)
T:System.Reflection.Emit.AssemblyBuilder	M:Reflection.Emit.AssemblyBuilder.Save(String)
T:System.Reflection.Emit.MethodBuilder	M:Reflection.Emit.MethodBuilder.AddDeclarativeSecurity(Security.Permissions.SecurityAction,Security.PermissionSet)
T:System.Reflection.Emit.MethodBuilder	M:Reflection.Emit.MethodBuilder.GetToken
T:System.Reflection.Emit.LocalBuilder	M:Reflection.Emit.LocalBuilder.SetLocalSymInfo(String)
T:System.AppDomain	M:AppDomain.DefineDynamicAssembly(Reflection.AssemblyName,Reflection.Emit.AssemblyBuilderAccess,String,Boolean,Collections.Generic.IEnumerable{Reflection.Emit.CustomAttributeBuilder})
T:System.Reflection.Emit.FieldBuilder	M:Reflection.Emit.FieldBuilder.GetToken
T:System.Diagnostics.StackTrace	M:Diagnostics.StackTrace.#ctor(Threading.Thread,Boolean)

[mikeTWC1984]

@timotei if you can attach binaries I'll run some tests I ran before for "Core" version

[timotei]

Btw, what I did was to reference some System.* nuget packages like: https://www.nuget.org/packages/System.Reflection.Emit/

Then we'd get them just fine even if they're not in netstandard. You can even see some types are specified as ".NET Standard Platform Extensions" = "netstandard + those extra NuGet libs"

[mikeTWC1984]

I think I was exploring that nuget, and missing methods were not there. From the other hand it's probably just used while converting dll to jar or otherwise, and in this case there is no really need to port it

[mikeTWC1984]

I just did a quick test - removing IKVM.Runtime.dll is not affecting code that uses converted jars and OpenJDK dlls, but crashes ikvmc while converting jar to dll. So I guess jar conversion is the only purpose of that Runtime.dll assembly and we shouldn't bother about missing Emit namespace types/methods, as long as we have access to a Windows machine with .net 4x.

[ams-tschoening]

That sounds like something we should explicitly document somewhere, e.g. in the wiki of the newly created organisation:

https://github.com/ikvm-revived/ikvm/wiki

Copying the wiki-contents from Sourceforge over might be an idea as well. Doesn't seem to be that much anyway:

https://sourceforge.net/p/ikvm/wiki/Main_Page/

[mikeTWC1984]

@ams-tschoening Agreed. Probably we can start with some simple readme (I'll probably work on this). I'd also put binaries to release page, or at list put a link on readme

[mikeTWC1984]

Btw, looks like you can run ikvmc (jar->dll) on linux using mono, just tried few jdbc and it seemed to work

[timotei]

@mikeTWC1984 Hmm, Interesting finding about IKVM.Runtime. I just completed most of the conversion, but I have some weird NPEs in some classes when trying to use BigDecimal from the .NET Standard libs, and it made me think the reason might be because I haven't compiled IKVM.Runtime later than first-pass (which is needed to compile the OpenJDK* dlls)

[timotei]

Hi guys, some good news, I managed to successfully compile IKVM-related binaries against .NET Standard (and ikvmc can generate .NET Standard libs).

Here are the changes done: https://github.com/Itiviti/ikvm/pull/5/files

Not all things are complete, some were left out, will probably fix them later, but at least to have the overview

[mikeTWC1984]

@timotei can you put your binaries somewhere?

[timotei]

Here you go:

NETSTANDARD_472.zip

Right now it's still a bit of mess w/r/t to the needed packages for running, depending on how you consume this (e.g., I used the dlls in deploy-net472, in my .NET 4.7.2 tests)

[cosentino-smeup]

I've added a branch, but consider this completely internal work for now.

I've deleted the old branch and created new ones, better named to (hopefully) not care about anymore for now. This one contains the fixes of wwrd as well, but I pretty sure to not maintain it intentionally.

https://github.com/ams-ts-ikvm-bag/ikvm-bin/tree/net_core_compat

Thank you very much!!! that fixed the problem!!!

[mbinsfeld]

@timotei are you planning on eventually merging your changes into the IKVM revived repo that @ams-tschoening created?

[timotei]

@mbinsfeld Yes :) Just got focused on some other thing these weeks, hopefully can do it by end of year or january

[mbinsfeld]

@timotei great! I'm just trying to get a better idea of what direction the IKVM project is heading.

[marshallcoco]

@timotei I'm new to IKVM and trying to use some Java libraries in a .Net Standard project I just found this topic and I'm really interested in what you are doing! Can you tell me which basic tests you successfully exectuted with your binaries? I tried to run a jar file on the fly, which failed but that may just be my lack of experience with IKVM. Thanks!

[ams-tschoening]

@marshallcoco Your question seems off-topic here and is more about general usage. As there's currently no mailing list infrastructure or such, I suggest you ask your question on Stackoverflow and/or in the new IKVM-organisation. Especially SO can still be used, because it has IKVM-tags and some people are still using it and reading there.

But in any case you should be more detailed about what exactly you did with which version of IKVM from where and about the exact error messages you get. Otherwise nobody will be able to help you. Most of the published docs are still valid as well:

https://www.ikvm.net https://sourceforge.net/p/ikvm/wiki/Main_Page/

[ghost]

Hi all;

Ok, we (Windward) now need to get our stuff working on .NET Core. @timotei & @ams-tschoening, what can I do to get all of your changes into our branch? And whatever is left, I'll port over.

Also we have extensive unit tests of our libraries (we run all the JUnit tests on the .NET code too). So our tests are a pretty thorough test of IKVM itself.

Anyways, get me your changes and I should be able to turn this all around in a week. And thank you both so much for the work you've already done.

I've sent both of you invites to give you read access to the project.

ps - We're aiming at .NET Core 3.1, not earlier. Is that an issue?

[ams-tschoening]

Ok, we (Windward) now need to get our stuff working on .NET Core. @timotei & @ams-tschoening, what can I do to get all of your changes into our branch? And whatever is left, I'll port over.

You should clone https://github.com/ikvm-revived/ikvm and base you work on that. That includes all your customizations not included in IKVM before (wwrd_fork) and the branch net_core_compat, in which I started to fix and/or at least document problems regarding compatibility. Search the code for TODOs like the following:

// TODO NET_CORE[_INCOMPAT]

There are .NET Core+UWP-app related PRs already as well, in some of which I document what CN1 did in their fork to support UWP-apps in the past. Additionally, some forks already base their work on that repo instead of yours.

This might give the new organisation an additional boost to become the one new entry point for IKVM.

[ghost]

@ams-tschoening Reading through the work in https://github.com/ikvm-revived/ikvm it looks like the only new stuff is our changes (wwrd_fork) and yours (net_core_compat & vs_19_build). And they're distinct branches so it doesn't have both.

Are you opposed to my bringing your net_core_compat changes over to here and moving forward on this project? And if so, should I bring the vs_19_build changes over too?

Or should we merge all three into ikvm-revived and then merge that into master. And do you or I have permissions in the project to push to the master branch?

[ams-tschoening]

[...]And they're distinct branches so it doesn't have both.

That was by purpose to make using ikvm-revived easier: Some people forked your repo, some worked on the last official release. Everything is available in ikvm-revived and users can simply decide what branch they base their work on and merge everything else as needed.

Are you opposed to my bringing your net_core_compat changes over to here and moving forward on this project?

I won't do that, but instead focus on working with ikvm-revived: Whatever I consider relevant for all IKVM-users will be published into ikvm-revived, like I did with my PRs and ikvm-junit already. Whatever is relevant to my current employer only will be published in a company-fork for that purpose. Whoever asks me about IKVM, will be directed to ikvm-revived instead of here, simply because I would like to have one place to keep track of IKVM-related stuff only.

So, I would prefer if you do the same and fork the repo of ikvm-revived, work on that and maybe provide PRs with your changes or push them directly. Others did fork as well already:

https://github.com/ikvm-revived/ikvm/network/members

And if so, should I bring the vs_19_build changes over too?

That branch is not strictly related to .NET Core, but instead I tried to get things to work with Visual Studio only to make development faster and reduce turnaround times. Needed to stop at some point, but might be of interest to others as well.

Or should we merge all three into ikvm-revived and then merge that into master.

vs_19_build should NOT be merged currently in my opinion, the other both might be: wwrd_fork contains your version numbers etc., so one could simply continue where you left off. net_core_compat depends on if unrelated things break if merged into master and if we care at all. I only use IKVM for some UWP-app, so don't care too much about other .NET currently.

And do you or I have permissions in the project to push to the master branch?

We both have, all members of ikvm-revived have currently.

https://github.com/orgs/ikvm-revived/people

[ghost]

@ams-tschoening I'm good with our switching to ikvm-revived if we can merge the wwrd_fork and net_core_compat into the master branch. And I'll then work on completing the .NET Core work.

We want to have a single IKVM that builds .NET Standard. So it creates a single DLL that will run on both .NET Framework & .NET Core.

In addition we need to get it up on NuGet. At present the only IKVM on NuGet is the original, one by qCat, and Windward's. What/how do you propose doing this as well as keeping the private signing key confidential?

[ams-tschoening]

@ams-tschoening I'm good with our switching to ikvm-revived if we can merge the wwrd_fork and net_core_compat into the master branch. And I'll then work on completing the .NET Core work.

Reads reasonable to me.

[...]What/how do you propose doing this as well as keeping the private signing key confidential?

I have absolutely no idea and experience with NuGet and this might be better discussed in an existing issue.

[NightOwl888]

I'm good with our switching to ikvm-revived if we can merge the wwrd_fork and net_core_compat into the master branch.

FYI - the original maintainer of IKVM requested that if someone take over the project, that the name be changed. Maybe calling it ikvm-revived isn't the best of ideas (although it doesn't bother me).

We want to have a single IKVM that builds .NET Standard. So it creates a single DLL that will run on both .NET Framework & .NET Core.

Agreed. So long as you plan to target .NET Standard 2.0.

[ghost]

Agreed. So long as you plan to target .NET Standard 2.0.

We're targeting .NET 3.1. I don't think it's worth the extra effort to work on 2.0 when everyone will be on 3.1 by the end of this year.

[NightOwl888]

We're targeting .NET 3.1. I don't think it's worth the extra effort to work on 2.0 when everyone will be on 3.1 by the end of this year.

.NET Standard 2.0 is the best option to have a single-targeted library.

.NET Standard 2.1 doesn't support .NET Framework. Having a direct .NET Core 3.1 target as well is okay if it makes sense for performance or compatibility reasons. But targeting NET Core alone would mean that all of the other platforms in the .NET ecosystem (.NET Framework, UWP, Unity, Mono, Xamarin, etc.) would have no support.

It would be a real shame to get all of this working only for .NET Core to the exclusion of all other platforms. Or have to target the original IKVM library and this one in order to support both .NET Framework and .NET Core, which would be a bad experience for library developers.

[ghost]

.NET Standard 2.0 is the best option to have a single-targeted library.

Maybe I misunderstand but if the .NET portability analyzer says the code I build with VisualStudio is compatible with .NET Core 3.1, then we're good on .NET Framework 4.6.1 and we're good on any platform supporting .NET Core 3.1.

That will be producing a single DLL that will run on both - correct?