Tasks to Complete for .NET Core Support

[NightOwl888]

This is the official IKVM repository where efforts are being consolidated to add support for .NET Core/.NET 5/.NET 6, however we don't currently have a package on NuGet.org, which is a blocker for many people.

The latest release of IKVM is the package released by Windward Studios and is available on NuGet.org, however efforts to continue that work to port to .NET Core have been moved here.

• We don't own the official IKVM package on NuGet.org (although we do have permission to use the IKVM name). @jfrijters - could you provide us with access to upload a new IKVM package on NuGet.org?
• There is currently not a stable build that work for general use that we can package and release on NuGet.org.
  • At this point we would be willing to forego support for .NET Standard and move straight to .NET 5/6.
  • Ideally, there would still be a target for .NET Framework 4.5+ in the package so consumers don't have to target 2 different IKVM versions to multi-target.
  • This is blocked by the fact that the library structure keeps changing and to target each version of .NET Core, there needs to be a mechanism that can detect which external libraries are required so they can be referenced in the build.
    • There are some efforts to complete this work in Support native build on *nix/Windows/macOS using SDK project #23, Ikvm build #25, and Add JDBC support to ikvm-build branch #38.
• Strong naming is incomplete
  • We need to either get the original strong name key (preferred) or generate a new one for IKVM. See Tasks to Complete for .NET Core Support #40 (comment).
  • The strong name key is not in the public repo.
• NuGet Packaging is incomplete
  • We have already migrated to the new .csproj format, so this can be done by adding the MSBuild attributes
• Set up build automation piplines
  • Set up official Azure DevOps organization for ikvm-revivied - Now set up at https://dev.azure.com/ikvm-revived/
    • Note that I already have several multi-targeted class library builds set up on Azure DevOps that we can borrow configs from. See Tasks to Complete for .NET Core Support #40 (comment).
• Documentation on how to build needs to be updated (see Remove Old Nant Scripts #22).

It would be appreciated if others working on ikvm-revived help keep this list updated with the latest info (wiki style) so those willing to contribute know where to focus their efforts.

Discord

We have set up a Discord server to collaborate on the remaining work: https://discord.gg/MpzNd5Tk8P

[jfrijters]

I didn't create the IKVM package on NuGet.org. That was done by barchen. Could you please ask barchen for access first?

[NightOwl888]

@jfrijters - Thanks. I used the contact link on NuGet.org to try to get in touch with him. However, as long as you have administrative permissions there, you should be able to assign additional people as administrators. If you assign me, I can set up an ikvm-revived group so other members of the team can upload packages.

[ripenko]

I added you as owner of IKVM. Also I would like to help with something if I could be helpful.

[NightOwl888]

@ripenko - Thank you.

[NightOwl888]

Okay, now we are over that hurdle. If we are using the same name and same NuGet.org feed, it also follows to use the same strong name key as the identity of the package author. I haven't attempted to look for the original .snk file yet, but does everyone agree that is the correct decision?

[joniles]

Looking at the notes on strong names here, I'm not sure we'd lose anything by starting with a fresh .snk.

On a related topic, the notes also offer this advice:

If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.

which would definitely make builds simpler.

[AliveDevil]

We (as in our organization) would be open to provide the JDK8u312b07 update, once IKVM builds for .NET Framework and .NET 5/6.

In the current state I cannot get either the master nor the ikvm-build-branch to build anything successfully.

[NightOwl888]

Looking at the notes on strong names here, I'm not sure we'd lose anything by starting with a fresh .snk.

The main issue with not using the same key is for existing libraries that specify IKVM as a dependency. For example if an existing library has a package reference to IKVM 8.1.5717:

<PackageReference Include="IKVM" Version="8.1.5717" />

What this effectively means is:

IKVM (>= 8.1.5717)

If a different .snk is used for IKVM 9.0 and the consumer of the library that referenced 8.1.5717 decides to upgrade to IKVM 9.0, they are in for a nasty surprise because even if the API is exactly the same, the different .snk file means they are not binary compatible. The upgrade fails, and the only resolutions are:

1. Downgrade to 8.1.5717
2. Petition the owner of the library that referenced 8.1.5717 to upgrade to 9.0

This of course puts the owner of the library at odds because if they upgrade to 9.0 it may break some applications and if they don't upgrade other applications won't be able to upgrade IKVM. And there is no realistic solution that works for everyone.

This is moot if we actually will have breaking API changes, but we should avoid that if it is possible.

On a related topic, the notes also offer this advice:

If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.

which would definitely make builds simpler.

Agreed.

[NightOwl888]

We (as in our organization) would be open to provide the JDK8u312b07 update, once IKVM builds for .NET Framework and .NET 5/6.

In the current state I cannot get either the master nor the ikvm-build-branch to build anything successfully.

Thanks. Are you saying the JDK version affects your ability to build or if you are making 2 unrelated (but helpful) comments?

[NightOwl888]

@jfrijters, @ripenko

Since ikvm.net has gone offline, we are now missing binaries and documentation that could be valuable resources going forward. Is there any chance that one of you has a backup of the website files that we can put into a separate GitHub repo in the ikvm-revived organization for reference purposes?

[NightOwl888]

@jfrijters, @ripenko

Since ikvm.net has gone offline, we are now missing binaries and documentation that could be valuable resources going forward. Is there any chance that one of you has a backup of the website files that we can put into a separate GitHub repo in the ikvm-revived organization for reference purposes?

Oops, I see we have the HTML files. But if there is a backup of the binaries that you were hosting, it would definitely be helpful for support purposes.

[jfrijters]

My ISP decided they wanted back the IPv4 subnet they were selling me and since (ICYMI) I have metastatic prostate cancer the site was going to go down eventually anyway and because I have different priorities nowadays I didn't bother looking for an alternative.

I still have the binaries. Is there anything specific you are looking for?

[ams-tschoening]

[...]But if there is a backup of the binaries that you were hosting, it would definitely be helpful for support purposes.

I have collected everything I found somewhat useful when dealing with IKVM. Feel free to have a look and fork or I might transfer repos into ikvm-revived and fork myself. Whatever makes more sense...

https://github.com/ams-ts-ikvm/ikvm-bin
https://github.com/ams-ts-ikvm

[AliveDevil]

Thanks. Are you saying the JDK version affects your ability to build or if you are making 2 unrelated (but helpful) comments?

I can build the current JDK version with our fork of IKVM (that is: with nant-0.95, targeting .NET 3.5), but applying the very same changes (that are all part of either C# or Java sources), but it's unclear which one of the branches in this repo is supposed to work.

[ApaulMyLittleAirport]

How long will it take to migrate to.Netcore?

[NightOwl888]

@ApaulMyLittleAirport

The main issues are:

• Nobody is currently working on it
• Those who wish to contribute are confused about how to contribute (which branch to fork to help out)

I opened this issue because there are several people willing to help, but they are having trouble navigating the confusing branch and repository history of this project since it stopped being maintained by @jfrijters.

While I can say for sure that the master branch is where we are doing the work, we have some open PRs (#23 and #25) but it isn't clear whether these are ready to be merged or whether there is more to be done on them before they can be merged. It would certainly help if someone would review these PRs. Unfortunately, I haven't looked deep enough into the code to make this determination myself and don't have much bandwidth to contribute here.

[asbjornu]

@NightOwl888, thanks for the clarification. If people agree that this is now the official repository for future work on IKVM, perhaps a PR that updates the README.md file with this information and removal of all irrelevant and outdated information would be a good idea?

As for pull requests with unclear status; adding some status checks with GitHub Actions would greatly improve that situation. The code should at least be compiled in an action to ensure that a PR doesn't break anything. Unless we are currently in a state where this thing doesn't even build?

I'm sure there are people (including me) that can help with tasks such as this, but it's still difficult to understand what needs to be done, in which order and to figure out the general direction of this project.

[joniles]

I've built IKVM locally to get a .Net Core version of my own project and it works beautifully. (I used a strong name key I generated and a couple of manual updates to the build files).

As per the list of tasks at the top of this conversation, we're relatively close to being able to formally release a new built. I'm happy to put time into getting these tasks done.

We should probably focus our efforts on one thing at at time. The first task I'd like to try and tick off is the snk file. As per Microsoft's recommendation, I'd like to get an snk file checked in to this repo.

To that end, we need to make a decision about compatibility. @jfrijters you've been very generous with your time in responding here, and I don't want to impose: if you do have the original snk file and would be comfortable posting it here that should make for a smoother upgrade process for IKVM users. If that's not possible, I will generate a new snk file and create a PR to include it here. In that case we'll have to accept that a minority. of users may face compatibility issues as projects update to use newer versions of IKVM, and move on.

I'm very excited about getting this moving forward!

[jfrijters]

ikvm-key.zip
It's been long enough since Microsoft deprecated using strong names for security that I think it is fine to share my key. So here it is.

[NightOwl888]

I've built IKVM locally to get a .Net Core version of my own project and it works beautifully. (I used a strong name key I generated and a couple of manual updates to the build files).

As per the list of tasks at the top of this conversation, we're relatively close to being able to formally release a new built. I'm happy to put time into getting these tasks done.

We should probably focus our efforts on one thing at at time. The first task I'd like to try and tick off is the snk file. As per Microsoft's recommendation, I'd like to get an snk file checked in to this repo.

To that end, we need to make a decision about compatibility. @jfrijters you've been very generous with your time in responding here, and I don't want to impose: if you do have the original snk file and would be comfortable posting it here that should make for a smoother upgrade process for IKVM users. If that's not possible, I will generate a new snk file and create a PR to include it here. In that case we'll have to accept that a minority. of users may face compatibility issues as projects update to use newer versions of IKVM, and move on.

I'm very excited about getting this moving forward!

@joniles - That's great. Thanks for stepping up.

First of all, when you say you "built it for .NET Core", which branch(es) did you build? And which version of .NET Core?

I have developed a common solution setup for class libraries that I use on 6 different projects. I integrated some of the features here, but there are still other features that can be migrated here. Here is a list (off the top of my head).

• Source Link support
• Nerdbank.GitVersioning to version dev builds based on the commit hash (patched in version.ps1 to support 4 segment version numbers)
• InternalsVisibleTo generation via MSBuild (switching to public key hash if it exists in <PublicKey>). Storing the public key in the MSBuild file eliminates the dependency on sn.exe, so the build will work on any OS.
• dependencies.props contains all NuGet package versions for the entire solution
• nuget.props contains most common NuGet package settings
• Reference Assemblies added globally, so we can build without the .NET Framework Developer Pack
• Azure DevOps templates for building, publishing, testing on multiple operating systems in parallel, and reporting any errors under a heading that includes target framework, platform, and OS
• Bootstrap build.bat and build (for BASH)
• PowerShell build.ps1 for parsing parameters, choosing defaults, and calling runbuild.ps1, which uses Psake build automation to do a local build and test
• How to build documentation (*this will need to be customized for this project)
• How to release documentation

I agree we should tick things off one item at a time. You are welcome to migrate these build features from the following projects:

• RandomizedTesting
• ICU4N
• J2N
• Morfologik.Stemming
• Spatial4n
• Lucene.Net

Let me know if you need assistance migrating any of these features or if you feel something is out of your depth.

[NightOwl888]

@NightOwl888, thanks for the clarification. If people agree that this is now the official repository for future work on IKVM, perhaps a PR that updates the README.md file with this information and removal of all irrelevant and outdated information would be a good idea?

As for pull requests with unclear status; adding some status checks with GitHub Actions would greatly improve that situation. The code should at least be compiled in an action to ensure that a PR doesn't break anything. Unless we are currently in a state where this thing doesn't even build?

I'm sure there are people (including me) that can help with tasks such as this, but it's still difficult to understand what needs to be done, in which order and to figure out the general direction of this project.

@asbjornu

Well, this is just as much of a discovery for me as it is for you. Several people have provided feedback that they were able to create a local build, but they unfortunately have never elaborated which branch they built (or branches they merged) or provided any kind of instructions, so I am in the dark just as much as you are. Unfortunately, I can't provide info that I don't have, and I am hesitant to remove information that might still have relevance from the README, as it may be required info to come up with the "new" way of doing things even if it doesn't currently work. Of course, if someone were willing to do the research, update documentation, or submit other PRs to bring this project forward such as investigating more about the specifics of what needs to be done, they are welcome to. But please don't wait for me to do the research if you expect a release soon, as I have my hands full with other projects and consider this dependency to be very low in priority at this point.

As for setting up status checks, we need a working build first before we can put in the automation. I have recently setup an Azure DevOps organization at https://dev.azure.com/ikvm-revived/ and completed the integration and approval steps for parallel jobs, so we only need to bring the templates over from our other projects once we have a build. And of course, @ripenko was kind enough to provide permission to the NuGet.org package so it can be uploaded and and @jfrijters was kind enough to provide the snk file for the build.

[joniles]

A quick note to provide some missing information from me, here are the instructions to reproduce the build of IKVM I'm using in my project (MPXJ):

The version of IKVM used to build MPXJ for .Net Core is from this branch of ikvm-revived/ikvm.

Build instructions:

1. Clone the repo and ensure the correct branch is checked out
2. Ensure .Net Core 3.1 SDK is installed
3. Ensure JDK 8 tools (javac etc) are on the path
4. Download openjdk-8u45-b14-stripped.zip and unzip in the same directory as your ikvm directory.
5. In your ikvm directory run build.core.cmd

Note that the native DLLs aren't built by the instructions above.
The Windows DLLS from IKVM 8.1 distribution will work fine.
I've manually built the Linux and OSX versions of these libraries,
which you'll find in the MPXJ distribution.

[NightOwl888]

@joniles - Thanks.

So, if I understand correctly, #25 and #38 can be merged, correct?

Although, I took a peek at #25 and noticed that the <InternalsVisibleTo> MSBuild settings were changed so they may not automatically output the public key when the snk is added. Did you have to account for this when you did a build?

The only one of the open tasks I am unsure about is "building missing parts for the core", but I suppose putting a prerelease on NuGet will start people reporting what isn't working, which can only help move us along.

[joniles]

@NightOwl888: yes #38 is definitely good to go. With regard to #25, do we want to keep developing against/merging into this branch until we're ready to release, or are we happy to start working against master now? Using master feels like it would reduce confusion about the direction this repo is heading in!

Regarding <InternalsVisibleTo> and use of the snk generally, I made a hacky change to the build locally (which you can see here) to get the strong name stuff working. I was going to open a PR for it, but I then realised that some of the work already seemed to be in place in some of the build files, so I dropped it. I was going to revisit this in the PR which adds the snk file.

[NightOwl888]

@NightOwl888: yes #38 is definitely good to go. With regard to #25, do we want to keep developing against/merging into this branch until we're ready to release, or are we happy to start working against master now? Using master feels like it would reduce confusion about the direction this repo is heading in!

Agreed I think it would be better to keep PRs short lived so we can pool resources on master.

So are we good to go right now? Or do you have open work that targets one of these branches?

Regarding <InternalsVisibleTo> and use of the snk generally, I made a hacky change to the build locally (which you can see here) to get the strong name stuff working. I was going to open a PR for it, but I then realised that some of the work already seemed to be in place in some of the build files, so I dropped it. I was going to revisit this in the PR which adds the snk file.

Alright, that makes sense.

The way it was set up here originally, the root Directory.Build.targets file has a target to automatically output the attributes during the build. But one of the .NET SDK releases broke this target because the event no longer fires at the right time. It was originally setup like

BeforeTargets="CoreCompile"

but now that needs to be changed to

BeforeTargets="BeforeCompile"

Then each project can simply add a list like below, and the attributes will be output automatically.

  <ItemGroup>
    <InternalsVisibleTo Include="IKVM.Runtime.JNI" />
    <InternalsVisibleTo Include="IKVM.OpenJDK.Core" />
    <InternalsVisibleTo Include="IKVM.OpenJDK.Util" />
    <InternalsVisibleTo Include="IKVM.OpenJDK.Security" />
    <InternalsVisibleTo Include="IKVM.OpenJDK.Management" />
    <InternalsVisibleTo Include="IKVM.OpenJDK.Media" />
    <InternalsVisibleTo Include="IKVM.OpenJDK.Misc" />
    <InternalsVisibleTo Include="IKVM.OpenJDK.Remoting" />
    <InternalsVisibleTo Include="IKVM.OpenJDK.SwingAWT" />
  </ItemGroup>

Does build.core.cmd need to own the sn key? Or can we just set the MSBuild properties in the root Directory.Build.props file?

Dotnet Tools

Some of the command line tools either were (or could be) converted to dotnet tools so they can be installed a NuGet package simply by using the dotnet commands. While we should take things one step at a time, this pertains to setting up the NuGet packaging, so should be taken into account when that is done. There are examples here of dotnet tools. Converting a command line tool to a dotnet tool generally isn't very complicated and allows leveraging the same deployment mechanism as the DLLs so the build and deployment is simpler.

https://docs.microsoft.com/en-us/dotnet/core/tools/global-tools-how-to-create

That being said, I am 100% sure that will work on the .NET Core side, but not sure whether there are any blocking issues that will prevent a .NET Core-based command line tool to build the .NET Framework bits, or whether we will need a separate assembly for .NET Framework. Do you think you could find an answer to whether a single set of tools will work for building IKVM assemblies on both .NET Framework and .NET Core or whether separate assemblies are required?

I also just discovered that it is possible to multi-target dotnet tools, which I have confirmed several of the projects on the above list are doing. So, we can add targets so the tools will work across major versions of .NET depending on which version is installed on the target machine. Of course, I suspect this doesn't have any .NET Framework support, but if we need a separate tool version for .NET Framework, we might be able to include it in the package, anyway.

[joniles]

So are we good to go right now? Or do you have open work that targets one of these branches?

I think so, I don't have any further changes to make to those branches.

Does build.core.cmd need to own the sn key? Or can we just set the MSBuild properties in the root Directory.Build.props file?

I think keeping the build.*.cmd scripts as simple as possible is preferable, so if we can add the snk details as properties and reference those that would be great.

Dotnet Tools

This is an interesting question. For my own use case when I'm packaging my project for distribution, I only really need the command line tools, which historically I'd have retrieved and unpacked from a zip file, so I'm hoping we retain that option and host simple zipped up releases here on GitHub. Arguably retrieving the IKVM tools as part of a Nuget package doesn't offer me much, particularly if there is an extra step for me to install the tools from the package before I can use them. Stable Nuget packages for me will be the big benefit for my downstream consumers as I won't have to bundle the IKVM assemblies, I can just reference them from the package I build. I appreciate my use case may be a bit odd though!

[NightOwl888]

Dotnet Tools

This is an interesting question. For my own use case when I'm packaging my project for distribution, I only really need the command line tools, which historically I'd have retrieved and unpacked from a zip file, so I'm hoping we retain that option and host simple zipped up releases here on GitHub. Arguably retrieving the IKVM tools as part of a Nuget package doesn't offer me much, particularly if there is an extra step for me to install the tools from the package before I can use them. Stable Nuget packages for me will be the big benefit for my downstream consumers as I won't have to bundle the IKVM assemblies, I can just reference them from the package I build. I appreciate my use case may be a bit odd though!

Actually, I am not sure whether putting the tool into the IKVM NuGet package is possible (I guess nothing would prevent it if you wanted to do that, though). What I meant was create 1 NuGet package per executable. In general, it is usually best to keep 1 DLL in each NuGet package also, but maybe that wouldn't be the best approach for this project.

Of course, to convert it to a dotnet tool, it would make more sense to have 1 executable that contains several different commands rather than having multiple executables. Then every command could be ikvm <command> [<subcommand>] [options]. We used a template that Microsoft created to build this tool with multiple commands and subcommands. Having multiple executables is fine, but the downside is the user would have to do multiple installations and we would have to maintain multiple NuGet packages.

The workflow doesn't require you to install the tool every time you use it. You can install it globally on the machine and then use it as many times as you like. I don't know whether this project will drift enough to require the versions to match between executable and DLLs, but it is something that can probably be automated.

A huge advantage of using a dotnet tool is that automation is simpler. Since the dotnet tool install command knows how to download the package (including switching TLS version) and unzip it to the install location, there is much less code to write to install it on a build machine than to download it from a GitHub release - just 1 line. And it is possible to write scripts to install the tool locally so it won't crash if the tool is already installed globally and even uninstall the tool to clean up. See this example. There is no need to work out which OS you are downloading the tool for and selecting the version is as simple as including the --version parameter. And there is no need to check the binaries into your repo to make them part of your build.

As for downloading the binaries:

1. .nupkg files are simply zip files with a different extension, so you could technically download the package from NuGet.org and unzip it yourself if you wanted a manual install.
2. The binaries will also be available as artifacts on the Azure DevOps build pipeline, and they are public so anyone can download them.

Keep in mind that executables on .NET Core are no longer xCopy - they need to be published before they can be deployed. The dotnet pack command automatically makes the tool portable, so no publish is required.

Of course there is nothing wrong with publishing the files and including them for download on the GitHub releases page for those who want to use the old school download approach, it is just extra steps for the release procedure. Unfortunately, while the APIs are there to automate creating a GitHub release, I haven't yet discovered a way to automate "release notes" (as the commit log usually contains commits that need to be summarized better than the commit message), so for now I do that step manually. But we could probably add a build step to automate a GitHub draft release that pushes all of the relevant binaries so it doesn't take extra manual work to upload them to GitHub.

InternalsVisibleTo

I am in the process of creating a PR to fix this on the ikvm-build branch before it is merged. There was another condition that was added since I contributed it that I didn't mention above which prevents it from firing for packages that don't have <SignAssembly> set to true, which makes it possible to have unsigned assemblies in the solution.

[viceice]

We have a really cool bot, which can manage and suggest updates the installed versions you reference in your projects.

Checkout renovate, i use it for daily work for our dotnet and npm projects. It can do more languages too.

So to install your simply do dotnet tool restore && dotnet restore on ci to have all build stuff available.

Renovate will just send you Pr's (like dependabot) to suggest the right updates.

[NightOwl888]

@joniles

I have submitted #41 with some updates, but unfortunately specifying an snk using the file path doesn't seem to function like it does when putting the snk in the keystore. I couldn't find a solution. But I have confirmed all but the last commit (enabling the snk) will compile on .NET Core by checking out the one prior.

This post was somewhat helpful: https://ikvm-developers.narkive.com/0VenMex7/ikvmc-cannot-sign-with-strong-name-key

I also noticed that the build.framework.cmd is complaining about missing runtime identifiers, but didn't do much investigation on how to resolve it.

I will leave this in your capable hands. Please base your changes on the ikvm-build-2 branch and target it when submitting a PR. I will merge everything back to master when we have functioning builds on both .NET Core and .NET Framework.

Dotnet Tools

After poking around a bit, I can see this is going to take more work than I thought. Even using the simple approach of using the template as a wrapper to convert parameters from the newer format to the original won't quite work because I noticed that some fields that expect file paths don't seem to have a way to escape if they have a space in the path.

I still think it is worth the effort to do this, but I concede that it isn't required for the first prerelease(s) that we publish. It is something that can be added to the build later.

[AliveDevil]

Moved #45

[ams-tschoening]

You should document that as individual issue and link here only.

[hfickes]

Is there a zip file somewhere that has all the binaries, both dlls and the ikvmc.exe? We're targeting .Net Framework 4.8 and have been using the ikvm 7 for years but need Java 8 support now.

Thanks

[NightOwl888]

We have released our first preview version of IKVM with .NET Core support. Please run it through its paces and report any issues you are seeing by opening a new issue.

https://www.nuget.org/packages/IKVM/8.2.0-prerelease0379

[burakglc]

Hello.

Version 8.2.0-prerelease0379

cipher cipher = null;,

I define it as Cipher.getInstance("AES/ECB/PKCS5Padding"); I am getting error in method.
the error message is "The type initializer for 'javax.crypto.JceSecurity' threw an exception.' shaped.

[NightOwl888]

Hello.

Version 8.2.0-prerelease0379

cipher cipher = null;,

I define it as Cipher.getInstance("AES/ECB/PKCS5Padding"); I am getting error in method. the error message is "The type initializer for 'javax.crypto.JceSecurity' threw an exception.' shaped.

Could you please open a new issue with that info so we can track it separately?

[burakglc]

A new issue has been opened.

[burakglc]

#70

[gglyggly]

First, thanks very much for your work on the .NET core version. I wonder where I can find the ikvmc.exe in prerelease.809?

[NightOwl888]

All of the tools are available in .zip files on the Releases page. The DLL references are available on NuGet.

[gglyggly]

Thanks, the tools has ikvmc.exe. However, when I launched it, it has below error, anyone knows how to resolve? Is it SDK version related? I google but with no clue...

C:\Downloads\IKVM-8.2.0-prerelease.809-tools-netcoreapp3.1-win7-x64>ikvmc -out:lm.dll lm.jar
IKVM.NET Compiler (8.2.0-prerelease.809)
Copyright c 2022 Jeroen Frijters, Windward Studios, Jerome Haltom, Shad Storhaug

*** INTERNAL COMPILER ERROR ***

PLEASE FILE A BUG REPORT FOR IKVM.NET WHEN YOU SEE THIS MESSAGE

ikvmc, Version=8.2.0.0, Culture=neutral, PublicKeyToken=13235d27fcbfff58
C:\Downloads\IKVM-8.2.0-prerelease.809-tools-netcoreapp3.1-win7-x64
3.1.25 64-bit

System.IO.FileNotFoundException: netstandard
at IKVM.Reflection.Universe.Load(String refname, Module requestingModule, Boolean throwOnError) in D:\a\ikvm\ikvm\IKVM.Reflection\Universe.cs:line 828
at IKVM.Internal.AssemblyResolver.Init(Universe universe, Boolean nostdlib, IList1 references, IList1 userLibPaths) in D:\a\ikvm\ikvm\ikvmc\IKVM\Internal\AssemblyResolver.cs:line 93
at ikvmc.IkvmcCompiler.Compile(String[] args) in D:\a\ikvm\ikvm\ikvmc\IkvmcCompiler.cs:line 178
at ikvmc.IkvmcCompiler.Main(String[] args) in D:\a\ikvm\ikvm\ikvmc\IkvmcCompiler.cs:line 112

[NightOwl888]

Thanks, the tools has ikvmc.exe. However, when I launched it, it has below error, anyone knows how to resolve? Is it SDK version related? I google but with no clue...

C:\Downloads\IKVM-8.2.0-prerelease.809-tools-netcoreapp3.1-win7-x64>ikvmc -out:lm.dll lm.jar
IKVM.NET Compiler (8.2.0-prerelease.809)
Copyright c 2022 Jeroen Frijters, Windward Studios, Jerome Haltom, Shad Storhaug
*** INTERNAL COMPILER ERROR ***
PLEASE FILE A BUG REPORT FOR IKVM.NET WHEN YOU SEE THIS MESSAGE
ikvmc, Version=8.2.0.0, Culture=neutral, PublicKeyToken=13235d27fcbfff58
C:\Downloads\IKVM-8.2.0-prerelease.809-tools-netcoreapp3.1-win7-x64
3.1.25 64-bit
System.IO.FileNotFoundException: netstandard
at IKVM.Reflection.Universe.Load(String refname, Module requestingModule, Boolean throwOnError) in D:\a\ikvm\ikvm\IKVM.Reflection\Universe.cs:line 828
at IKVM.Internal.AssemblyResolver.Init(Universe universe, Boolean nostdlib, IList1 references, IList1 userLibPaths) in D:\a\ikvm\ikvm\ikvmc\IKVM\Internal\AssemblyResolver.cs:line 93
at ikvmc.IkvmcCompiler.Compile(String[] args) in D:\a\ikvm\ikvm\ikvmc\IkvmcCompiler.cs:line 178
at ikvmc.IkvmcCompiler.Main(String[] args) in D:\a\ikvm\ikvm\ikvmc\IkvmcCompiler.cs:line 112

Please report this as a new issue so we can track it individually.

[gglyggly]

here it is #74

[viceice]

Which is the latest release on github? From releases page it's not clear

[viceice]

it seems 809 is latest, but on nuget.org 911 is latest, so there are also some github releases missing.

https://www.nuget.org/packages/IKVM/8.2.0-prerelease0911

[NightOwl888]

Looks like the last 3 GitHub releases are still in "draft" status. They all have the same "what's changed" section, though (all of them are pointing to prerelease.809 for the beginning of the changelog).

@wasabii - I know I can change them to "real" releases through the control panel, but is there some compelling reason why they are still draft releases? Like maybe you were planning to change the release notes first?

[viceice]

@NightOwl888 I created #84 to fix it

[wasabii]

Hiya.

I thought it would be good to do it manually, after verifying everything was okay and to fix the release notes.

[viceice]

@wasabii But it seems the verify step got forgotten for latest releases 🙃

So i would suggest to publish them right away. Missing releases are more worth than wrong release notes 🤷‍♂️