New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Critial Failure - Trying to compile Apache Tika using .NET Core 3.1 Tools #85
Comments
Eh, that code that is loading WinForms is lame. That certainly needs to be addressed. We shouldn't be doing dialogs like that for critical failures. But that's going to take some reassessment and time I think. The actual error, the overriding an assembly thing, is probably going to take some digging into. You say it works fine on Framework? What's this library do? I see this in your stack:
This makes me think it's trying to do some runtime bytecode compilation. Do you know if this library is? |
@wasabii Thank you for the reply! Everything is working with Framework correct - the same Jar in .NET 6.0 is generating the stack trace from my original message. Apache Tika is used to determine a file type, metadata, and text contents. I'm not much of a Java developer and am unsure if it uses runtime bytecode compilation or not. My end goal was to utilize IKVM to compile Tika into a .NET library and implement its parser interface in .NET. I've got a test harness up on Github here (dylanlangston/IKVM-TikadotNet-Harness) that demonstrates the issue concisely and consistently. It contains two nearly identical projects that use the new |
I believe I've got this one. Tika is trying to generate some dynamic byte code. And what's happening is IKVM is trying to generate a corresponding DynamicAssembly at runtime, with access to the internal members of the Tiki assembly. To do this, the static compiler places a InternalVisibleTo attribute on the generate assembly, referring to the future possibility of a strong-named assembly coming along that matches, and thus has access to internal methods. However, Core is no longer able to use StrongNameKeyPair to sign assemblies. Throws a PlatformNotSupportedException. And thus the generation of the assembly fails. And then all this gets hidden by the WinForms error code stuff. So, strong names are not really a useful thing in Core. And thus, I've changed the Static Compiler on Core to not emit an InternalsVisibleTo attribute with teh public key, nor to generate a dynamic assembly with the key. InternalsVisibleTo is still required, it just doesn't have to match on public key anymore. I've left the code that does all this on Framework. Though, I'm pretty sure this is no longer required on Framework either. Need to develop a test case to confirm that. But the forged key pair stuff should be able to go away on .NET 4 as well. |
So, no. There's no security benefit here on .NET 4. All of the validation of this stuff at runtime is gone. However, there is still a requirement that InternalVisibleTo attributes contain strong names when installing an assembly into the GAC. So, as long as we want GAC support for our generated assemblies, this still needs to be here. I'd +1 for removing GAC support for our generated assemblies. I don't think we should waste time or effort catering to it in this day and age. Maybe unpopular opinion? I don't know. Either way, problem for another day. |
Hello, I am trying to use IKVM to compile a .NET version of Apache Tika (https://tika.apache.org/). Essentially the same goal as Tika on .NET but targeting .NET 6.0.
I am able to use the .NET Framework tools IKVM-8.2.0-prerelease.911-tools-net461-any without issue. When attempting the same procedure using the .NET Core 3.1 tools IKVM-8.2.0-prerelease.911-tools-netcoreapp3.1-win7-x64 I'm running into a bit of a snag.
To test compatibility I ran the following command against the .NET Framework tools:
C:\Users\dlangston\Downloads\IKVM-8.2.0-prerelease.911-tools-net461-any\ikvm.exe -jar C:\Users\dlangston\Downloads\Tika\tika-app-2.4.1.jar C:\Users\dlangston\Desktop\test.svg
This produced the expected output with no errors.
I repeated this using the .NET Core 3.1 tools but encounter an error related to loading WinForms (source of issue seen here):
C:\Users\dlangston\Downloads\IKVM-8.2.0-prerelease.911-tools-net461-any\ikvm.exe -jar C:\Users\dlangston\Downloads\Tika\tika-app-2.4.1.jar C:\Users\dlangston\Desktop\test.svg
Following that error I attempted to convert the Jar to a Library:
C:\Users\dlangston\Downloads\IKVM-8.2.0-prerelease.911-tools-netcoreapp3.1-win7-x64\ikvmc.exe -assembly:tika-app -classloader:ikvm.runtime.AppDomainAssemblyClassLoader -target:library C:\Users\dlangston\Downloads\Tika\tika-app-2.4.1.jar -nostdlib -reference:C:\Users\dlangston\Downloads\IKVM-8.2.0-prerelease.911-tools-netcoreapp3.1-win7-x64\refs\*.dll
I imported that library into a new C# project and attempted to create a new instance of Tika:
Initially this reproduced the same error from above referencing System.Windows.Forms. After adding WinForms to my project and running again I'm now seeing what I believe is the actually exception.
Unfortunately that was the end of my rope... Anything that can be done to continue troubleshooting? Any insight at this point is greatly appreciated!!
The text was updated successfully, but these errors were encountered: