问题
I ran a 3rd party Android library through CodenameOne's version of IKVM and successfully imported the output .dll as a reference to my UWP app in Visual Studio. Upon trying to compile the project I get a single build error:
(from the Error List window)
Cannot find type System.ApplicationException in module CommonLanguageRuntimeLibrary
(from the Output window)
Program Files (x86)\MSBuild\Microsoft\WindowsXaml\v14.0\8.2\Microsoft.Windows.UI.Xaml.Common.targets(352,5): Xaml Internal Error error WMC9999: Cannot find type System.ApplicationException in module CommonLanguageRuntimeLibrary.
From what I've read System.ApplicationException is depreciated in .Net for UWP and instead you're supposed to just use System.Exception
I don't know how to work around and/or correct this since it's coming from a library and not my own code.
Thanks in advance.
回答1:
Our port of IKVM isn't quite turn-key. IKVM is compiled using .Net 2.0, and some things (e.g. reflection stuff, some date things, threads, etc...) are factored out using interfaces that need to be included in the UWP project that uses it.
If you haven't implemented these interfaces, or you are using code paths that we don't need for CN1, then you may be embarking of parts of the JDK or IKVM runtime that use .Net 2.0 classes (e.g. this exception).
Currently there are only two interfaces that need to be implemented in your UWP project:
- RuntimeReflectionHelper.
- NativeThreadHelper
You can see, in the CN1 port how they are initialized here
Here are the implementations for the RuntimeReflectionHelper and NativeThreadHelper
Implementing these inside the UWP project gets around fact that IKVM is compiled for .Net 2.0, so that these implementations can use UWP APIs directly.
Even with this, you will probably run into issues. This port of IKVM is evolving along side the CN1 port, and it is really only tested for our uses cases. Some common methods may be unimplemented if we didn't require them for CN1.
Some other limitations you should be aware:
The IKVM-compiled code in a project needs to be part of a single .dll file if you want it to refer to each other. E.g. If you compile two libraries, lib1.jar and lib2.jar to lib1.dll and lib2.dll, then code from lib1 can't references classes from lib2 and vice versa. In CN1 I bundle all .class files into a single .jar before running it through IKVM so that isn't an issue for us (hence why I didn't spend much time trying to fix it).
If your goal is to publish to the Windows store, there is currently a bug in their DotNetNative toolchain that causes it to choke on synchronized methods that include try/catch blocks. This will likely be fixed by Microsoft in future releases, but I get around this by running a pre-transformation on all classes to convert all such methods into a form that is acceptable to their native toolchain. Here the part of our ANT task that applies this preprocessing. Here is the class preprocessor project for the ANT task that this uses to do the actual preprocessing.
As I said before, expect to run into difficulties if you're exploring outside the trails that have already been blazed.
来源：https://stackoverflow.com/questions/39683977/cannot-find-type-system-applicationexception-in-module-commonlanguageruntimelibr