Impossible de trouver le type System.ApplicationException dans le module CommonLanguageRuntimeLibrary

Question

J'ai exécuté une bibliothèque Android tierce par le biais de la version IKVM de CodenameOne et j'ai importé avec succès la sortie .dll en tant que référence de mon application UWP dans Visual Studio. Lors d'essayer de compiler le projet, je reçois une seule erreur de construction:

(à partir de la fenêtre Liste d'erreurs)

Cannot find type System.ApplicationException in module CommonLanguageRuntimeLibrary

(à partir de la fenêtre de sortie)

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.

D'après ce que j'ai lu System.ApplicationException est déprécié dans .Net pour UWP et à la place, vous êtes censé utiliser simplement System.Exception

Je ne sais pas comment contourner et/ou corriger cela depuis ça vient d'une bibliothèque et pas de mon propre code.

Merci d'avance.

Answer 1

Notre port d'IKVM n'est pas tout à fait clé en main. IKVM est compilé en utilisant .Net 2.0, et certaines choses (par exemple, des éléments de réflexion, des éléments de date, des threads, etc ...) sont factorisées à l'aide d'interfaces qui doivent être incluses dans le projet UWP qui l'utilise. Si vous n'avez pas implémenté ces interfaces, ou si vous utilisez des chemins de code dont nous n'avons pas besoin pour CN1, alors vous pouvez vous lancer dans des parties du runtime JDK ou IKVM qui utilisent des classes .Net 2.0 (par ex. exception).

Actuellement, il n'y a que deux interfaces qui doivent être mises en œuvre dans votre projet UWP:

1. RuntimeReflectionHelper.
2. NativeThreadHelper

Vous pouvez voir, dans le port CN1 comment ils sont initialisés here

Voici les mises en œuvre pour la RuntimeReflectionHelper et NativeThreadHelper

La mise en œuvre de ces à l'intérieur du projet UWP se déplace fait IKVM est compilé pour .Net 2.0, afin que ces implémentations puissent utiliser directement les API UWP.

Même avec cela, vous rencontrerez probablement des problèmes. Ce port d'IKVM évolue parallèlement au port CN1, et il n'est vraiment testé que pour nos cas d'utilisation. Certaines méthodes courantes peuvent ne pas être implémentées si nous ne les avons pas requises pour CN1.

D'autres limitations que vous devez savoir:

1. Le code compilé IKVM dans un projet doit faire partie d'un seul fichier .dll si vous voulez faire référence à l'autre. Par exemple. Si vous compilez deux bibliothèques, lib1.jar et lib2.jar à lib1.dll et lib2.dll, le code de lib1 ne peut pas référencer les classes de lib2 et vice versa. Dans CN1, je regrouper tous les fichiers .class dans un fichier .jar avant de l'exécuter via IKVM, ce qui n'est pas un problème pour nous (c'est pourquoi je n'ai pas passé beaucoup de temps à essayer de le réparer). Si votre objectif est de publier sur le Windows Store, il existe actuellement un bogue dans leur chaîne d'outils DotNetNative qui provoque l'obstruction des méthodes synchronisées qui incluent des blocs try/catch.Cela sera probablement corrigé par Microsoft dans les prochaines versions, mais je contourne cela en exécutant une pré-transformation sur toutes les classes pour convertir toutes ces méthodes dans une forme acceptable pour leur chaîne d'outils native. Here la partie de notre tâche ANT qui applique ce prétraitement. Here est le projet de préprocesseur de classe pour la tâche ANT utilisée pour effectuer le prétraitement proprement dit.

Comme je l'ai déjà dit, attendez-vous à rencontrer des difficultés si vous explorez en dehors des sentiers qui ont déjà été flambés.