Open jollescott opened 5 years ago
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.
Doesn't at least UWP uses .Net Core as well? Otherwise I wouldn't have run into trouble at all.
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?
I haven't tried .NET portability analyzer, but given the fact that IKVM already runs on .NET Framework and the tool says it will support up to .NET Core 3.1, there should be no issue with creating a single-targeted .NET Standard 2.0 library that will run on both .NET Framework 4.6.1+ and .NET Core 2.0+.
I haven't looked at the source, though. There may be a little bit of grunt work to get there. But if you want a single target that can support all current platforms as well as .NET Framework, then .NET Standard 2.0 is the best choice.
Keep in mind, the idea for library development is to support the lowest version you can, so you get as much coverage as possible. That said, there is practically no reason to support .NET Standard 1.x anymore.
Doesn't at least UWP uses .Net Core as well? Otherwise I wouldn't have run into trouble at all.
Just so we are clear, .NET Core and .NET Standard were released together. .NET Core is a runtime. .NET Standard is not - it is simply a way to target multiple runtimes, and it is a replacement for Portable Class Libraries.
While I haven't ever setup a UWP project, it would seem according to this UWP document that your only 2 choices are targeting UWP directly and targeting .NET Standard. It may be possible to target .NET Core and run on UWP (just like it is possible to target .NET Framework and run on Mono), but if it is, it certainly isn't the normal way to do it :)
If you take a look at the up-to-date packages on NuGet.org, you will note most of them target .NET Standard 2.0 if they are single-targeted. And .NET Standard is usually included if they are multi-targeted.
BTW - no objections if you want to multi-target - it is actually much easier than it used to be to get that done. I'd be willing to make a contribution if it helps.
@DavidThi808 Are there any updates on your effort to create a single repo and nuget package for a .NET Standard 3.1 compliant IKVM? There is a large community of IKVM users that will benefit from the work that you are doing.
We're making progress.
@timotei I used your binaries for .netstandard as per this comment .But when i am converting the jar to dll i am getting Warning IKVMC0108: not a class file xyz.class, including it as resource (class format error "52.0") if i use IKVM 8.1.5717 i am able to generate the dll. Please let me know anything else i have to do.
@DavidThi808 Are there any updates on your effort to create a single repo and nuget package for a .NET Standard 3.1 compliant IKVM? There is a large community of IKVM users that will benefit from the work that you are doing.
Following. Any Updates? Looking at Repo now for recent updates. I haven't pulled yet, but are the updates from 5 months ago workable? TIA!
The most current thread about most current code is most likely the following:
https://github.com/ikvm-revived/ikvm/issues/20 https://github.com/ikvm-revived/ikvm/issues/20#issuecomment-668110864
Was this work transferred over to IKVM-revived? It's a bit of a shame because IKVM-revived is a strange repo. There's no readme file over there, and it looks like .NET Core support just sort of hangs out on its own branch, completely independent of work done by others. I'm not sure what to make of it, really.
Was this work transferred over to IKVM-revived?
That depends on what "this" work is for you. A lot of comments are simply about my branch net_core_compat
and that is available in ikvm-revived
, as you already recognized.
There's no readme file over there,
There is, because I merged things coming from WWRD as well: https://github.com/ikvm-revived/ikvm/blob/master/README.md
and it looks like .NET Core support just sort of hangs out on its own branch, completely independent of work done by others.
Because it is/was work done independent of any other work done LATER. net_core_compat
was an internal PoC made by me to test things for an UWP-app, afterwards others tried to do things "right" in different branches and PRs. So net_core_compat
might be a misleading name right now, but as it is referenced and other work doesn't seem to be finished yet as well, I don't think it makes sense to rename that branch.
So you simply have the choice which of the available work you look at and try to get things running for your project.
All, I was wondering which github repo and discussion thread is the latest one to track the progress of this project? Thanks.
I agree with @qwertie, the current situation seems a bit chaotic. Not being heavily involved in the code it's at least difficult to understand what's going on.
We have windward-studios/ikvm8 as well as windward-studios/ikvm where .NET Core compatibility is absent and whose
master
branches last changed on Apr 3, 2019 and on Jul 3, 2018 respectively.
Then we have IKVM-Revived with no obvious connection to this repository (it's not forked from here) and with a master
branch that changed last on May 25, 2020. IKVM-Revived also has the branch net_core_compat
which is is 5 commits ahead, 98 commits behind its own master
. Then there's net_core_compat_to_master
which is 7 commits ahead, 73 commits behind its own master
. No branch mentions .NET Core support or how to build with dotnet build
. There's also no consumable NuGet package anywhere to be found.
I understand that this is hard work, but there seem to be quite a few people working on this. From the outset, the main problem appears to be a loss of clear direction as well as where and how to cooperate. If what @NightOwl888 writes in https://github.com/windward-studios/ikvm8/issues/3#issuecomment-588359214 is correct, the name IKVM
would be best avoided and something like OpenJDK.NET
would be better.
Either way, I kindly ask you all to please collect your efforts around a single default branch in a single repository and make it the "official" community effort where we can pour all of our resources into getting a .NET Core or .NET 5 compatible IKVM alternative up on its feet. 🙏🏼
If you need any assistance in the managementarial aspects of setting this up, please let me know.
@asbjornu
Thanks for pointing out how confusing this is. I don't know everything going on with this project, but I do know that the effort to maintain it has been consolidated at ikvm-revived. I have added https://github.com/ikvm-revived/ikvm/issues/40 to clarify this.
@DavidThi808 - it would be helpful if you pin an issue at the top of the issues list and/or update the docs for this repo to reflect that the official effort has moved, so any potential contributors know where to focus their efforts.
The fact that this repo was never merged to ikvm-revived is a bit of a mystery to me (and is certainly cause for confusion). How do we know whether the patches applied here were applied to ikvm-revived?
Another thing that is confusing is the fact that ikvm-revived doesn't have a package on NuGet.org yet (which is why I added the above issue to clarify what is blocking that). But we definitely need some more contributions to get there.
The fact that this repo was never merged to ikvm-revived is a bit of a mystery to me (and is certainly cause for confusion). How do we know whether the patches applied here were applied to ikvm-revived?
WWRD and ikvm-revived started with different repos, because I found it important to have the original history and therefore created my own forks. Though, when doing so, I wasn't even aware of WWRD and this discussion, recognized it only afterwards and made my fork available as ikvm-revived. There's a PR containing all the changes applied by WWRD:
The dll that can be operated on the .net core app 5.0 Can I get it through jar?
thank you
You need to give net_core_compat
a try and if things work, fine. If not, you need to follow the following thread and build on your own:
https://github.com/ikvm-revived/ikvm/issues/40
net_core_compat
was chosen as name of an internal PoC with pretty limited focus, so it's expected to not work for everyone and only provided as-is.
Hi, just wondering if you have done any testing on .net core yet?