Eto: Mac - Mono 6.4 exécute toutes les applications, les versions Mono supérieures ne le font pas

Créé le 28 mars 2020  ·  21Commentaires  ·  Source: picoe/Eto

Toutes les applications Mac que j'ai développées jusqu'à présent ont cessé de fonctionner après la mise à niveau de Mono vers 6.6 (même problème avec 6.8).

Revenir à une installation précédente de Mono 6.4 résout le problème.

Mes applications se compilent avec TargetFramework net461 (point d'entrée Mac) et netstandard2.0 (dll partagé) au cas où cela compte.

Comme toujours, l'erreur est probablement la mienne.

Merci pour votre patience.

Tous les 21 commentaires

@LaraSQP , merci pour les rapports, mais cela aiderait vraiment si vous incluiez des détails comme l'exception réelle (vérifiez Console.app) et ce que vous avez essayé.

En outre, une chose à noter est que lors de la compilation pour _release_, avec mono installé sur votre boîte de développement, il regroupera mono dans votre application afin qu'il ne nécessite pas l'installation de mono pour _exécuter_ votre application. Cela fera en sorte que vous ayez un temps d'exécution connu. Vous pouvez également utiliser .NET Core à la place et le regrouper dans votre application (ne nécessite pas l'installation de mono pour ce faire).

Merci pour la réponse rapide.

Je ne connaissais pas Console.app et signalera l'exception.

Je ne savais pas non plus comment installer Mono sur Windows. Merde chose. Quel installateur s'applique ? 64 bits (pas de GTK#) ou ai-je aussi besoin du GTK# ?

GTK# n'est pas nécessaire, il utilise uniquement mkbundle pour regrouper mono, ce qu'il fait en utilisant la propriété <MacBundleTarget> dans votre csproj. Il vaut par défaut mono-6.4.0-osx-10.9-x64 s'il n'est pas spécifié, et peut être n'importe quelle valeur répertoriée dans mkbundle -list-targets

En ce qui concerne Console.app, je n'ai que deux erreurs qui sont assez peu informatives (pour moi, au moins):

29 mars 06:19:01 my-MacBook-Air com.apple.xpc.launchd[1] (com.apple.xpc.launchd.oneshot.0x1000015e.MyApp1[10705]): Service terminé avec un code anormal : 78

29 mars 06:40:29 my-MacBook-Air com.apple.xpc.launchd[1] (com.example.MyApp1.4212[11362]): Service terminé avec un code anormal : 1

Essayer maintenant de recompiler avec Mono installé.

@LaraSQP Jetez un œil à la section « Rapports d'

"Rapports d'incident" est vide.

BTW, j'ai installé mono 6.8 et je ne vois pas le même problème.

Screen Shot 2020-03-28 at 3 30 34 PM

Une chose à considérer, c'est que si vous avez modifié Info.plist d'une manière ou d'une autre (à partir de l'un de vos autres problèmes), c'est qu'il _doit_ être uniquement LF, UTF-8 _sans BOM_, et non CRLF. Il supposera qu'il est corrompu dans le cas contraire.

Info.plist a été modifié par npp.

J'ai installé Mono sur ma machine de développement mais la recompilation n'ajoute pas Mono au bundle. Qu'est-ce que je rate?

En mode Release, il le fait par défaut. Sinon, définissez <MacBundleMono> sur true dans csproj.

Jetez un œil à BundleMono.targets et Mac.targets pour les différentes propriétés que vous pouvez définir.

J'espère ajouter ces options aux propriétés du projet VS pour faciliter à l'avenir leur découverte, mais hélas si peu de temps (libre) pour le faire.

L'ajout de <MacBundleMono>True</MacBundleMono> à csproj ne le fait pas.

À moins qu'il ne le fasse d'une manière qui ne m'est pas apparente, c'est-à-dire.

D'ACCORD.

Il s'avère qu'un dossier MonoBundle est inclus dans l'application uniquement lorsque MacBundleMono est défini sur False .

De plus, Info.plist est modifié par le processus de construction pour inclure à la fois UTF-8 BOM et CRLF , ils doivent donc être corrigés manuellement par la suite.

De plus, Info.plist est modifié par le processus de génération pour inclure à la fois la nomenclature UTF-8 et le CRLF, ils doivent donc être corrigés manuellement par la suite.

Cela ne devrait pas être le cas.. pourriez-vous joindre votre fichier Info.plist que vous utilisez (pas celui compilé).

Il s'avère qu'un dossier MonoBundle est inclus dans l'application uniquement lorsque MacBundleMono est défini sur False.

Oui, un dossier MonoBundle ne signifie pas que mono est groupé.. bizarrement.. l'absence de ce dossier signifie que mono est « groupé » et que tout est inclus dans l'exécutable natif.

MacBundleMono est un buste. Mono n'est pas inclus quoi qu'il arrive.

Et toute version de Mono supérieure à 6.4.0.137 continue de planter mes applications.

J'examinerai les cibles de construction plus tard.

Merci pour votre patience.

Recevez-vous toujours cet avertissement lors de la construction ?

Couldn't find mkbundle, so app bundle will require mono to be installed! Install mono from https://mono-project.com to bundle it with your app or set MonoPath to where it is installed.

Si c'est le cas, vous devrez peut-être redémarrer ou pointer spécifiquement vers l'endroit où mono a été installé à l'aide de <MonoPath> .

Pourriez-vous également m'envoyer le dmg de votre application (en supposant que vous soyez prêt à le faire ?). Je pourrais essayer de diagnostiquer plus loin.

Je ne reçois pas d'avertissement concernant mkbundle alors je vais essayer le MonoPath ensuite.

Ci-joint un projet simple que j'ai utilisé pour tester ceci et cela. Il ne démarre même pas au-dessus de Mono 6.4 sous Mac et il n'y a pas de rapport de plantage dans Console.app

MacFileTest.zip

J'avais ajouté Mono au environment variables , donc mkbundle est accessible sans problème. MonoPath n'est pas le problème ici.

En fait, j'ai pu exécuter mkbundle manuellement via...

mkbundle --simple --cross mono-6.4.0-osx-10.9-x64 MacFileTest.exe -o MacFileTest

... qui a semblé réussir sauf qu'il ne fonctionnera pas sur Mac.

Puisqu'il n'y a aucune référence à mkbundle dans mon projet (ci-dessus), il est évident qu'il me manque beaucoup de choses.

Il semble que mon dernier message ne l'ait pas fait, ou je ne le trouve pas, ou il a été supprimé d'une manière ou d'une autre.

Tout d'abord, l'utilisation de netcoreapp3.1 effet résolu le problème. Merci beaucoup.

J'ai désinstallé Mono et toutes les applications fonctionnent maintenant sur net core . Je suis un peu surpris depuis que la commande dotnet dans les Terminal :

zsh : commande introuvable : dotnet

Je suppose qu'une chose n'a pas à voir avec l'autre (?).

Il reste deux petits problèmes que vous voudrez peut-être connaître :

  1. Le processus de construction inclut toujours un fichier .pdb dans le dossier MacOS du bundle.

  2. Le processus de construction modifie toujours Info.plist pour inclure une clé CFBundleExecutable , dupliquant celle existante si elle est présente. Il en résulte que BOM et CRLF doivent être inclus bien qu'ils ne soient pas présents dans le Info.plist d'origine du projet.

La solution de contournement à ces deux problèmes est un simple fichier batch pour supprimer 1 et remplacer 2, qui doit malheureusement être exécuté manuellement car il ne peut pas être ajouté au post-build events car malgré le fait qu'il soit post-build il s'exécute toujours trop tôt , pour autant que je sache.

Merci encore pour votre infinie patience.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

katatunix picture katatunix  ·  12Commentaires

Serg-Norseman picture Serg-Norseman  ·  5Commentaires

ArsenShnurkov picture ArsenShnurkov  ·  17Commentaires

jzlhll picture jzlhll  ·  14Commentaires

voronoipotato picture voronoipotato  ·  16Commentaires