Visual basic sur linux / Mac ?
Résolu/Fermé
A voir également:
- Visual basic sur linux / Mac ?
- Visual basic download - Télécharger - Langages
- Microsoft 365 basic - Guide
- Adresse mac - Guide
- @ Sur mac - Guide
- Nettoyer mac - Guide
1 réponse
ElementW
Messages postés
4816
Date d'inscription
dimanche 12 juin 2011
Statut
Contributeur
Dernière intervention
5 octobre 2021
1 225
25 mars 2015 à 13:42
25 mars 2015 à 13:42
'lut, le VB.NET utilise le runtime .NET, qui en principe est cross-platform. En l'occurrence, en installant Mono, tu pourras lancer des .EXE écrits en langages .NET (donc VB.NET, C#, ...), mais avec certaines restrictions: certaines fonctions spécifiques ne sont pas dispo dessus, comme par exemple les P/Invoke ou les forms WPF -- ce sont donc des choses à ne pas mettre dans ton appli.
Mono dispose d'un outil nommé MoMa, qui t'indique si ton programme marchera comme il faut sous Mono (donc Linux/OSX) et dans le cas contraire, ce qu'il faut changer pour.
Mono dispose d'un outil nommé MoMa, qui t'indique si ton programme marchera comme il faut sous Mono (donc Linux/OSX) et dans le cas contraire, ce qu'il faut changer pour.
25 mars 2015 à 13:58
Aucuns besoins que je modifie mon programme ?
Et pour les variables d'environnement (car le programme doit télécharger un fichier, et les noms d'endroit ou il sera téléchargé changent entre plateforme non ?), comment ça ce passe à ce niveau ?
Modifié par gravgun le 25/03/2015 à 14:30
Les variables d'environnement sont "compatibles" partout, par contre tu ne trouveras pas les mêmes selon les plate-formes: sous Windows tu dois télécharger dans un répertoire d'AppData par ex, sous Linux il faut suivre le standard XDG (XDG_RUNTIME_DIR si c'est très temporaire, XDG_CACHE_HOME si c'est considéré comme du cache, XDG_DATA_HOME si c'est supposé "permanent"), et pour OS X, cf cette réponse StackOverflow pour les chemins qui correspondent à ceux de XDG.
Tu peux détecter la plate-forme utilisée grâce à , plus particulièrement son membre qui est une énum PlatformID.
Aussi, veille bien a ne jamais utiliser les antislash () en tant que séparateur de chemin dans ton code: le standard c'est le slash , qui marche même sous Windows. Mieux encore, sers toi de la classe System.IO.Path qui permet la manipulation de chemins indépendamment de la plate-forme.
25 mars 2015 à 14:34