mono - En ligne dans le Cloud

PROGRAMME:

Nom

mono - Générateur de code natif ECMA-CLI de Mono (Just-in-Time et Ahead-of-Time)

SYNOPSIS

mono [choix] filet [arguments...]

mono-sgen [choix] filet [arguments...]

DESCRIPTION

mono est une implémentation d'exécution de l'infrastructure de langage commun ECMA. Cela peut être
utilisé pour exécuter les applications ECMA et .NET.

Le runtime contient un générateur de code natif qui transforme le Common Intermediate
Langue en code natif.

Le générateur de code peut fonctionner selon deux modes : compilation juste à temps (JIT) ou en amont de
compilation de temps (AOT). Étant donné que le code peut être chargé dynamiquement, l'environnement d'exécution et
les JIT sont toujours présents, même si le code est compilé à l'avance.

Le runtime charge le spécifié filet et passe éventuellement le arguments à cela. Les filet
est une assemblée ECMA. Ils ont généralement une extension .exe ou .dll.

L'environnement d'exécution fournit un certain nombre d'options de configuration pour l'exécution d'applications, par exemple
développer et déboguer, et pour tester et déboguer le runtime lui-même.

La mono La commande utilise le ramasse-miettes conservateur Boehm tandis que la commande mono-sgen commander
utilise un ramasse-miettes mouvant et générationnel.

PORTABILITÉ

Sur les systèmes basés sur Unix, Mono fournit un mécanisme pour émuler l'accès aux fichiers de style Windows,
cela inclut la fourniture d'une vue insensible à la casse du système de fichiers, du séparateur de répertoire
mappage (de \ à /) et suppression des lettres de lecteur.

Cette fonctionnalité est activée en définissant le MONO_IOMAP variable d'environnement à l'un des
tous, motivation et Cas.

Voir la description pour MONO_IOMAP dans la section variables d'environnement pour plus de détails.

DURÉE OPTIONS

Les options suivantes sont disponibles:

--aot, --aot[=options]
Cette option est utilisée pour précompiler le code CIL dans l'assembly spécifié en natif
code. Le code généré est stocké dans un fichier avec l'extension .so. Ce fichier
sera automatiquement récupéré par le runtime lors de l'exécution de l'assembly.
La compilation en amont est plus utile si vous l'utilisez en combinaison avec le
-O=all,-shared flag qui permet à toutes les optimisations du générateur de code de
être effectuée. Certaines de ces optimisations ne sont pas pratiques pour le juste-à-temps
compilation car elles peuvent prendre beaucoup de temps. Contrairement au .NET Framework,
La compilation en amont ne générera pas de code indépendant du domaine : elle génère
le même code que le compilateur Just-in-Time produirait. Puisque la plupart
les applications utilisent un seul domaine, c'est très bien. Si vous souhaitez optimiser le
code généré pour une utilisation dans des applications multi-domaines, envisagez d'utiliser le -O=shared
drapeau. Cela précompile les méthodes, mais l'assemblage d'origine est toujours requis
à exécuter car celui-ci contient les métadonnées et les informations d'exception qui ne sont pas
disponible sur le fichier généré. Lors de la précompilation du code, vous souhaiterez peut-être compiler
avec toutes les optimisations (-O=all). Le code précompilé est un code indépendant de la position.
La pré-compilation n'est qu'un mécanisme pour réduire le temps de démarrage, augmenter le partage de code
sur plusieurs processus mono et éviter le démarrage du programme de compilation juste à temps
frais. L'assembly d'origine doit toujours être présent, car les métadonnées sont contenues
là. Le code AOT ne peut généralement pas être déplacé d'un ordinateur à un autre (CPU-
optimisations spécifiques détectées lors de l'exécution), vous ne devez donc pas essayer de déplacer
les assemblages pré-générés ou emballer les assemblages pré-générés pour
déploiement. Quelques options sont disponibles en tant que paramètre pour le --aot ligne de commande
option. Les options sont séparées par des virgules et plusieurs peuvent être spécifiées :

enregistrement automatique
Le compilateur AOT émettra un initialiseur de bibliothèque (ELF uniquement) pour
enregistrez le module compilé aot avec le runtime. Ceci n'est utile que dans
mode statique

asmonly
Demande au compilateur AOT de produire du code assembleur au lieu d'un objet
fichier.

lier à la version d'exécution
Si spécifié, force les fichiers AOT générés à être liés au runtime
version de la compilation Mono. Cela empêchera les fichiers AOT d'être
consommé par un autre runtime Mono. plein Il s'agit actuellement d'un
fonctionnalité expérimentale car elle n'est pas complète. Cela indique à Mono de
code de précompilation qui n'a historiquement pas été précompilé avec AOT.

rappel direct
Lorsque cette option est spécifiée, les méthodes P/Invoke sont invoquées directement à la place
de passer par l'opération de recherche de symboles du système d'exploitation.

chemin-llvm=
Idem pour les outils llvm 'opt' et 'llc'.

triple=
Utiliser le triple cible de style GNU pour déterminer une génération de code
options, c'est-à-dire --mtriple=armv7-linux-gnueabi va générer du code qui cible
ARMv7. Ceci n'est actuellement pris en charge que par le backend ARM. En mode LLVM,
ce triplet est transmis au compilateur LLVM llc.

nimt-trampolines=[nombre]
Lors de la compilation en mode aot complet, les trampolines IMT doivent être précréés dans
l'image AOT. Vous pouvez ajouter des trampolines de méthode supplémentaires avec ce
argument. La valeur par défaut est 128.

nodebug
Indique au compilateur AOT de ne sortir aucune information de débogage.

pas d'appels directs
Cela empêche le compilateur AOT de générer des appels directs à une méthode.
Le compilateur AOT génère généralement des appels directs pour certaines méthodes qui ne
pas besoin de passer par le PLT (par exemple, les méthodes connues pour
pas besoin d'un crochet comme un constructeur statique) ou d'un appel interne simple
appels.

naindebug
Demande au compilateur AOT d'émettre des informations de débogage DWARF. Lorsqu'elle est utilisée
avec l'option nodebug, seules les informations de débogage DWARF sont
émis, mais pas les informations qui peuvent être utilisées lors de l'exécution.

nrgctx-trampolines=[nombre]
Lors de la compilation en mode aot complet, les trampolines génériques de partage doivent être
précréé dans l'image AOT. Vous pouvez ajouter des trampolines de méthode supplémentaires avec
cet argument. La valeur par défaut est 1024.

ntrampolines=[nombre]
Lors de la compilation en mode aot complet, la méthode trampolines doit être précréée
dans l'image AOT. Vous pouvez ajouter des trampolines de méthode supplémentaires avec ce
argument. La valeur par défaut est 1024.

outfile=[nom de fichier]
Demande au compilateur AOT d'enregistrer la sortie dans le fichier spécifié.

méthodes-d'impression-sautées
Si le compilateur AOT ne peut pas compiler une méthode pour une raison quelconque, l'activation de cette
flag affichera les méthodes ignorées sur la console.

readonly-value=namespace.typename.fieldname=type/valeur
Remplacez la valeur d'un champ statique en lecture seule. Habituellement, pendant le JIT
compilation, le constructeur statique est exécuté avec impatience, donc la valeur d'un static
le champ en lecture seule est connu au moment de la compilation et le compilateur peut faire un certain nombre
d'optimisations basées sur celui-ci. Pendant AOT, à la place, le constructeur statique
ne peut pas être exécuté, donc cette option peut être utilisée pour définir la valeur d'un tel champ
et activer le même ensemble d'optimisations. Le type peut être l'un des i1, i2, i4 pour
entiers des tailles respectives (en octets). Notez que signé/non signé
les chiffres n'ont pas d'importance ici, juste la taille de stockage. Cette option peut être
spécifié plusieurs fois et cela n'empêche pas le constructeur statique pour
le type définissant le champ à exécuter avec les règles habituelles à l'exécution
(donc éventuellement en calculant une valeur différente pour le champ).

enregistrer-temps,garder-temps
Demande au compilateur AOT de conserver les fichiers temporaires.

débogage logiciel
Cela indique au compilateur de générer des vérifications de point de séquence qui permettent
Le débogueur logiciel de Mono pour déboguer des applications même sur des systèmes où il ne l'est pas
possible de définir des points d'arrêt ou à pas unique (certains matériels
configurations comme les téléphones portables et les consoles de jeux vidéo).

statique Créez un fichier objet ELF (.o) ou un fichier .s qui peut être lié de manière statique
dans un exécutable lors de l'intégration du runtime mono. Lorsque cette option est
utilisé, le fichier objet doit être enregistré avec le runtime intégré à l'aide
la fonction mono_aot_register_module qui prend comme argument le
mono_aot_module_ _info symbole global du fichier objet :

vide externe * mono_aot_module_hello_info ;

mono_aot_register_module (mono_aot_module_hello_info);

stats Imprimez diverses statistiques collectées lors de la compilation AOT.

fils=[nombre]
Il s'agit d'une option expérimentale permettant au compilateur AOT d'utiliser plusieurs threads
lors de la compilation des méthodes.

préfixe-outil=
Préfixe au nom des outils exécutés par le compilateur AOT, c'est-à-dire
'comme'/'ld'. Par exemple, --tool=prefix=arm-linux-gnueabi- fera l'AOT
exécution du compilateur

écrire-symboles
Demande au compilateur AOT d'émettre des informations sur les symboles de débogage.

Pour plus d'informations sur l'AOT, consultez : http://www.mono-project.com/docs/advanced/aot/

--attache=[options]
Actuellement, la seule option prise en charge par cet argument de ligne de commande est désactiver qui
désactive la fonctionnalité de connexion.

--config nom de fichier
Chargez le fichier de configuration spécifié au lieu du ou des fichiers par défaut. Le défaut
les fichiers sont /etc/mono/config et ~/.mono/config ou le fichier spécifié dans le
Variable d'environnement MONO_CONFIG, si elle est définie. Voir le mono-config(5) page de manuel pour
détails sur le format de ce fichier.

--debugger-agent=[options]
Cela indique au runtime Mono de démarrer un agent de débogage dans le runtime Mono
et le connecter à une interface utilisateur client contrôlera le processus Mono. Cette
L'option est généralement utilisée par les IDE, comme l'IDE MonoDevelop.

La configuration est spécifiée à l'aide d'une ou plusieurs des options suivantes :

adresse=hôte:port
Utilisez cette option pour spécifier l'adresse IP où se trouve votre client de débogage
écouter.

loglevel=NIVEAU
Spécifie le niveau de journal des diagnostics pour

logfile=nom de fichier
Utilisé pour spécifier le fichier où le journal sera stocké, il vaut par défaut
sortie standard.

serveur=[o/n]
La valeur par défaut est non, avec l'option par défaut, Mono se connectera activement au
hôte/port configuré avec le propos option. Si vous le définissez sur « y », il
indique à l'environnement d'exécution Mono de commencer le débogage en mode serveur, où Mono
attend activement que le frontal du débogueur se connecte au processus Mono.
Mono imprimera sur stdout l'adresse IP et le port où il écoute.

setpgid=[o/n]
Si défini sur oui, Mono appellera setpgid(0, 0) on démarrage, if qui fonction is
disponibles on le système. Cette is incontournable pour assurer qui signaux livré
à a processus qui is exécution le débogueur are pas propagé à le
débogueur, par exemple quand Ctrl-C envoie SIGINT à le sdb outil.

suspendre=[o/n]
La valeur par défaut est oui, avec l'option par défaut, Mono suspendra la machine virtuelle au démarrage
jusqu'à ce qu'il se connecte avec succès à un frontal de débogueur. Si vous le réglez sur
'n', en conjonction avec serveur=y, il demande à l'environnement d'exécution Mono de s'exécuter comme
normal, tout en mettant en cache les métadonnées à envoyer au frontal du débogueur sur
connexion..

transport=nom_transport
Ceci est utilisé pour spécifier le transport que le débogueur utilisera pour
communiquer. Il doit être spécifié et nécessite actuellement que cela soit
'dt_socket'.

--bureau
Configure la machine virtuelle pour qu'elle soit mieux adaptée aux applications de bureau.
Actuellement, cela définit le système GC pour éviter d'agrandir le tas autant que possible
au détriment de ralentir un peu la collecte des ordures.

--plein-aot
Il s'agit d'un indicateur expérimental qui indique à l'environnement d'exécution Mono de ne générer aucun
code à l'exécution et dépendent exclusivement du code généré à partir de l'utilisation de mono
--aot=complet précédemment. Ceci est utile pour les plates-formes qui n'autorisent pas les
génération de code. Notez que cette fonctionnalité interrompra l'exécution au moment de l'exécution si un
codepath dans votre programme, ou les bibliothèques de classes de Mono tentent de générer du code
dynamiquement. Vous devez tester votre logiciel en amont et vous assurer que vous ne
utiliser toutes les fonctionnalités dynamiques.

--gc=boehm, --gc=sgén
Sélectionne le moteur Garbage Collector pour Mono à utiliser, Boehm ou SGen. Actuellement
cela garantit simplement que vous exécutez soit le mono or mono-sgen les commandes.
Ce drapeau peut être défini dans le MONO_ENV_OPTIONS variable d'environnement pour forcer tout
votre enfant traite pour utiliser un type particulier de GC avec le runtime Mono.

--Aidez-moi, -h
Affiche les instructions d'utilisation.

--llvm Si le runtime Mono a été compilé avec le support LLVM (non disponible dans tous
configurations), Mono utilisera le moteur d'optimisation et de génération de code LLVM pour
Compilation JIT ou AOT. Pour plus d'informations, consultez : http://www.mono-
project.com/docs/advanced/mono-llvm/

--nollvm
Lorsque vous utilisez un Mono qui a été compilé avec le support LLVM, cela force Mono à
se replier sur son moteur JIT et ne pas utiliser le backend LLVM.

--optimize=MODE, -O=MODE
MODE est une liste d'optimisations séparées par des virgules. Ils permettent également des optimisations pour
être désactivé en préfixant le nom de l'optimisation d'un signe moins. En général,
Mono a été réglé pour utiliser l'ensemble d'indicateurs par défaut, avant d'utiliser ces indicateurs pour un
paramètre de déploiement, vous souhaiterez peut-être mesurer les avantages de leur utilisation.
Les indicateurs d'optimisation suivants sont implémentés dans le moteur principal :
abcrem Array bind checks suppression
All Activer toutes les optimisations
aot Utilisation du code compilé Ahead Of Time
branche Optimisations des branches
cfold Pliage constant
cmov Mouvements conditionnels [arch-dépendance]
deadce élimination du code mort
consprop Propagation constante
copyprop Copie de propagation
fcmov Fast x86 FP compare [arch-dépendance]
float32 Effectuer une arithmétique flottante 32 bits à l'aide d'opérations 32 bits
gshared Activer le partage de code générique.
Appels de méthode en ligne
intrins Implémentations de méthodes intrinsèques
linears Balayage linéaire reg allocation globale
leaf Optimisations des procédures Leaf
boucle Optimisations liées à la boucle
judas judas postpass
precomp Précompiler toutes les méthodes avant d'exécuter Main
sched Ordonnancement de l'instruction
Partagé Émettre le code par domaine
sse2 Instructions SSE2 sur x86 [arch-dépendance]
tailc Récursivité et appels de queue
Par exemple, pour activer toutes les optimisations à l'exception de l'élimination du code mort et de l'incorporation,
vous pouvez utiliser:
-O=tout,-mort,-en ligne
Les drapeaux qui sont marqués avec [arch-dependency] indiquent que l'option donnée si
utilisé en combinaison avec la compilation Ahead of Time (--aot flag) produirait des pré-
code compilé qui dépendra du processeur actuel et pourrait ne pas être déplacé en toute sécurité vers
un autre ordinateur.

Les optimisations suivantes sont prises en charge

float32
Demande à l'environnement d'exécution d'effectuer des opérations à virgule flottante 32 bits à l'aide de
seulement 32 bits. Par défaut, le runtime Mono essaie d'utiliser le plus
précision disponible pour les opérations en virgule flottante, mais bien que cela puisse
rendre de meilleurs résultats, le code peut s'exécuter plus lentement. Cette option aussi
affecte le code généré par le backend LLVM.

en ligne Contrôle si le runtime doit tenter de s'intégrer (valeur par défaut) ou non
appels de méthodes en ligne

--runtime=VERSION
Mono prend en charge différentes versions d'exécution. La version utilisée dépend du programme
qui est en cours d'exécution ou sur son fichier de configuration (nommé program.exe.config). Cette
L'option peut être utilisée pour remplacer une telle détection automatique, en forçant un runtime différent
version à utiliser. Notez que cela ne doit être utilisé que pour sélectionner une version ultérieure compatible
version d'exécution que celle avec laquelle le programme a été compilé. Une utilisation typique est
pour exécuter un programme 1.1 sur une version 2.0 :
mono --runtime=v2.0.50727 programme.exe

--Sécurité, --sécurité=mode
Activez le gestionnaire de sécurité, une fonctionnalité actuellement expérimentale dans Mono et il est
OFF par défaut. Le nouveau vérificateur de code peut également être activé avec cette option.

Utiliser la sécurité sans paramètres équivaut à l'appeler avec le "cas"
paramètre.

Les modes suivants sont pris en charge :

noyau-clr
Active le système de sécurité core-clr, généralement utilisé pour
Applications Moonlight/Silverlight. Il offre une sécurité beaucoup plus simple
système que CAS, voir http://www.mono-project.com/docs/web/moonlight/ pour
plus de détails et des liens vers les descriptions de ce nouveau système.

valide
Active le nouveau vérificateur et effectue une vérification de base pour la validité du code.
Dans ce mode, le code non sécurisé et P/Invoke sont autorisés. Ce mode offre un
meilleure garantie de sécurité mais il est toujours possible que le code managé se bloque
Mono.

vérifiable
Active le nouveau vérificateur et effectue une vérification complète du code en cours
réalisé. Il permet uniquement l'exécution de code vérifiable. Le code dangereux est
non autorisé mais P/Invoke l'est. Ce mode ne doit pas permettre au code managé de
crash mono. La vérification n'est pas aussi stricte que la norme ECMA 335 afin
pour rester compatible avec le runtime MS.

Le système de sécurité agit sur le code utilisateur : code contenu dans mscorlib ou le
le cache d'assembly est toujours approuvé.

--serveur
Configure la machine virtuelle pour qu'elle soit mieux adaptée aux opérations du serveur
(actuellement, permet une initialisation de threadpool plus lourde).

--vérifier-tout
Vérifie mscorlib et les assemblys dans le Global Assembly Cache pour un IL valide, et tout
code utilisateur pour la vérifiabilité IL.

C'est différent de --Sécuritéest vérifiable ou valide en ce que ces options
vérifier uniquement le code utilisateur et ignorer mscorlib et les assemblys situés sur le global
cache d'assemblage.

-V, --version
Imprime les informations de version JIT (configuration du système, numéro de version et branche
noms si disponibles).

PREMIUM OPTIONS

Les options suivantes sont utilisées pour vous aider lors du développement d'une application JITed.

--déboguer, --debug=OPTIONS
Active le mode de débogage dans le runtime. Si un assembly a été compilé avec
informations de débogage, il produira des informations de numéro de ligne pour les traces de pile.

L'argument facultatif OPTIONS est une liste d'options de débogage séparées par des virgules.
Ces options sont désactivées par défaut car elles génèrent beaucoup plus et plus lentement
code à l'exécution.

Les options suivantes sont prises en charge :

jette Produit une erreur détaillée lors de la levée d'une InvalidCastException. Cette
l'option doit être activée car cela génère un code plus détaillé à l'exécution
le temps.

mdb-optimisations
Désactiver certaines optimisations JIT qui ne sont généralement désactivées que lors de l'exécution
à l'intérieur du débogueur. Cela peut être utile si vous souhaitez joindre au
processus en cours avec mdb.

gdb Générez et enregistrez les informations de débogage avec gdb. Ceci est uniquement pris en charge
sur certaines plates-formes, et uniquement lors de l'utilisation de gdb 7.0 ou version ultérieure.

--profile[=profiler[:profiler_args]]
Active le profilage. Pour plus d'informations sur le profilage des applications et du code
couverture, voir les sections « PROFILAGE » et « COUVERTURE DU CODE » ci-dessous.

Cette option peut être utilisée plusieurs fois, chaque fois chargera un
profileur supplémentaire. Cela permet aux développeurs d'utiliser des modules qui étendent le JIT
via l'interface de profilage Mono.

--trace[=expression]
Affiche les noms de méthode au fur et à mesure qu'ils sont appelés. Par défaut, toutes les méthodes sont tracées. Les
trace peut être personnalisé pour inclure ou exclure des méthodes, des classes ou des assemblys. UNE
l'expression de trace est une liste de cibles séparées par des virgules, chaque cible peut être préfixée
avec un signe moins pour désactiver une cible particulière. Les mots « programme », « tous » et
« handicapé » a une signification particulière. « programme » fait référence au programme principal en cours
exécuté, et 'all' signifie tous les appels de méthode. L'option 'désactivé' est utilisée pour
démarrer avec le traçage désactivé. Il peut être activé ultérieurement dans le
programme en envoyant le signal SIGUSR2 au runtime. Les assemblages sont spécifiés par
leur nom, par exemple, pour tracer tous les appels dans l'assembly System, utilisez :

mono --trace=Système app.exe

Les classes sont spécifiées avec le préfixe T:. Par exemple, pour tracer tous les appels vers le
Classe System.String, utilisez :

mono --trace=T:System.String app.exe

Et les méthodes individuelles sont référencées avec le préfixe M:, et la méthode standard
notation:

mono --trace=M:System.Console:WriteLine app.exe

Des exceptions peuvent également être tracées, cela entraînera l'impression d'une trace de pile à chaque fois
une exception du type spécifié est levée. Le type d'exception peut être spécifié
avec ou sans l'espace de noms, et pour tracer toutes les exceptions, spécifiez 'all' comme
tapez le nom.

mono --trace=E:System.Exception app.exe

Comme indiqué précédemment, différentes règles peuvent être spécifiées à la fois :

mono --trace=T:System.String,T:System.Random app.exe

Vous pouvez exclure des morceaux, l'exemple suivant trace les appels à System.String sauf pour
la méthode System.String:Concat.

mono --trace=T:System.String,-M:System.String:Concat

Vous pouvez suivre les transitions gérées vers non gérées à l'aide du qualificatif wrapper :

mono --trace=wrapper app.exe

Enfin, les espaces de noms peuvent être spécifiés à l'aide du préfixe N : :

mono --trace=N:System.Xml

--no-x86-stack-align
N'alignez pas les cadres de pile sur l'architecture x86. Par défaut, Mono aligne la pile
trames à 16 octets sur x86, de sorte que les variables locales à virgule flottante et SIMD peuvent être
correctement aligné. Cette option désactive l'alignement, ce qui économise généralement un
instruction par appel, mais peut entraîner une virgule flottante nettement inférieure et
Performances SIMD.

--jitmap
Générez une carte de méthode JIT dans un fichier /tmp/perf-PID.map. Ce fichier est ensuite utilisé, pour
exemple, par l'outil perf inclus dans les noyaux Linux récents. Chaque ligne du fichier
a:

HEXADDR HEXSIZE nom de la méthode

Actuellement, cette option n'est prise en charge que sous Linux.

JIT MAINTAINER OPTIONS

Les options du responsable ne sont utilisées que par ceux qui développent le runtime lui-même, et non
généralement d'intérêt pour les utilisateurs d'exécution ou les développeurs.

--Pause méthode
Insère un point d'arrêt avant la méthode dont le nom est 'méthode'
(espace de noms.class:nom de la méthode). Utilisez `Main' comme nom de méthode pour insérer un point d'arrêt sur
la méthode principale de l'application. Vous pouvez l'utiliser aussi avec des génériques, par exemple
"System.Collections.Generic.Queue`1:Peek"

--breakonex
Insère un point d'arrêt sur les exceptions. Cela vous permet de déboguer votre application avec
un débogueur natif lorsqu'une exception est levée.

--compiler prénom
Cela compile une méthode (namespace.name:methodname), elle est utilisée pour tester le
performances du compilateur ou pour examiner la sortie du générateur de code.

--compiletout
Compile toutes les méthodes d'un assembly. Ceci est utilisé pour tester le compilateur
performances ou pour examiner la sortie du générateur de code

--graph=TYPE MÉTHODE
Cela génère un fichier postscript avec un graphique avec les détails sur le spécifié
méthode (namespace.name:methodname). Cela nécessite que `dot' et ghostview soient
installé (il s'attend à ce que Ghostview s'appelle "gv"). Les graphiques suivants sont
disponible:
cfg Graphique de flux de contrôle (CFG)
dtree Arbre dominant
code CFG montrant le code
ssa CFG affichant le code après la traduction SSA
optcode CFG affichant le code après les optimisations IR
Certains graphiques ne seront disponibles que si certaines optimisations sont activées.

--ncompile
Instruisez le runtime sur le nombre de fois que la méthode spécifiée par --compile
(ou toutes les méthodes si --compileall est utilisé) à compiler. Ceci est utilisé pour
tester les performances du générateur de code.

--Statistiques
Affiche des informations sur le travail effectué par le runtime pendant l'exécution d'un
.

--wapi=hps|semdel
Effectuer la maintenance des données partagées du processus. semdel supprimera le global
sémaphore. hps listera les poignées actuellement utilisées.

-v, --verbeux
Augmente le niveau de verbosité, chaque fois qu'il est répertorié, augmente la verbosité
niveau pour inclure plus d'informations (y compris, par exemple, un démontage du
code natif produit, informations sur le sélecteur de code, etc.).

ATTACHER SUPPORT

Le runtime Mono permet aux processus externes de s'attacher à un processus en cours d'exécution et de le charger
assemblys dans le programme en cours d'exécution. Pour s'attacher au processus, un protocole spécial est
implémenté dans l'assembly Mono.Management.

Avec ce support, il est possible de charger des assemblages qui ont un point d'entrée (ils sont
créé avec -target:exe ou -target:winexe) pour être chargé et exécuté dans le processus Mono.

Le code est chargé dans le domaine racine et il démarre l'exécution sur le runtime spécial
attacher le fil. Le programme attaché doit créer ses propres threads et revenir après
invocation.

Ce support permet par exemple de déboguer des applications en faisant attacher le shell csharp
aux processus en cours d'exécution.

PROFILAGE

Le runtime mono comprend un profileur qui peut être utilisé pour explorer diverses performances
problèmes connexes dans votre application. Le profileur est activé en passant le --profile
argument de ligne de commande au runtime Mono, le format est :

--profile[=profiler[:profiler_args]]

Mono a un profileur intégré appelé 'default' (et est également la valeur par défaut si aucun argument n'est
spécifié), mais les développeurs peuvent écrire des profileurs personnalisés, voir la section "PROFILERS PERSONNALISÉS"
pour plus de détails.

Si un profileur n'est pas spécifié, le profileur par défaut est utilisé. Les profileur_args est une
chaîne d'options spécifique au profileur pour le profileur lui-même. Le profileur par défaut accepte
les options suivantes « alloc » pour profiler la consommation de mémoire par l'application ; 'temps de
profiler le temps consacré à chaque routine ; « jit » pour collecter le temps passé à compiler les méthodes JIT
et « stat » pour effectuer un profilage statistique de l'échantillon. Si aucune option n'est fournie, le
la valeur par défaut est 'alloc,time,jit'.

Par défaut, les données du profil sont imprimées sur stdout : pour changer cela, utilisez le 'file=filename'
option pour exporter les données vers le nom de fichier. Par exemple:

mono --profile programme.exe

Cela exécutera le programme avec le profileur par défaut et fera le temps et l'allocation
profilage.

mono --profile=default:stat,alloc,file=prof.out program.exe

Échantillonnera le profilage statistique et le profilage d'allocation sur program.exe. Le profil
les données sont mises dans prof.out. Notez que le profileur statistique a une très faible surcharge et
devrait être le profileur préféré à utiliser (pour une meilleure sortie, utilisez le chemin complet vers le mono
binaire lors de l'exécution et assurez-vous que vous avez installé l'utilitaire addr2line qui vient de
le paquet binutils).

Se Connecter PROFILEUR

C'est le profileur le plus avancé.

le mono enregistrer profileur peut être utilisé pour collecter beaucoup d'informations sur un programme en cours d'exécution
dans l'environnement d'exécution Mono. Ces données peuvent être utilisées (à la fois pendant l'exécution du processus et plus tard)
pour faire des analyses du comportement du programme, déterminer l'utilisation des ressources, les problèmes de performance ou
même rechercher des modèles d'exécution particuliers.

Ceci est accompli en enregistrant les événements fournis par l'environnement d'exécution Mono via le
interface de profilage et les écrire périodiquement dans un fichier qui peut être inspecté ultérieurement
couplé à mprof-rapport(1) outil.

Plus d'informations sur l'utilisation du profileur de journaux sont disponibles sur le mprof-rapport(1)
.

SUR MESURE PROFILEURS

Mono fournit un mécanisme pour charger d'autres modules de profilage qui, sous la forme de
bibliothèques. Ces modules de profilage peuvent se connecter à diverses parties du runtime Mono pour
recueillir des informations sur le code en cours d'exécution.

Pour utiliser un profileur tiers, vous devez transmettre le nom du profileur à Mono, comme ceci :

mono --profile=programme personnalisé.exe

Dans l'exemple ci-dessus, Mono chargera le profileur défini par l'utilisateur à partir de la bibliothèque partagée
`mono-profiler-custom.so'. Ce module de profileur doit être sur votre bibliothèque d'éditeurs de liens dynamiques
chemin.

Une liste d'autres profileurs tiers est disponible sur le site Web de Mono (www.mono-
project.com/docs/advanced/performance-tips/)

Les profils personnalisés sont écrits en tant que bibliothèques partagées. La bibliothèque partagée doit être appelée `mono-
profiler-NAME.so' où 'NAME' est le nom de votre profileur.

Pour un exemple de la façon d'écrire votre propre profileur personnalisé, regardez dans l'arborescence des sources Mono pour in
les échantillons/profiler.c.

CODE COUVERTURE

Mono est livré avec un module de couverture de code. Ce module est activé en utilisant le Mono
--profile=option cov. Le format est : --profile=cov[:nom-assemblage[/espace-noms]] test-
suite.exe

Par défaut, la couverture du code s'appliquera par défaut à tous les assemblys chargés, vous pouvez limiter cela en
en spécifiant le nom de l'assembly, par exemple pour effectuer une couverture de code dans les routines de votre
l'utilisation du programme, par exemple la ligne de commande suivante limite la couverture du code aux routines
dans l'assemblage "démo":

mono --profile=cov:demo demo.exe

Notez que le nom_assembly n'inclut pas l'extension.

Vous pouvez restreindre davantage la sortie de couverture de code en spécifiant un espace de noms :

mono --profile=cov:demo/My.Utilities demo.exe

Ce qui n'effectuera la couverture de code que dans l'assembly et l'espace de noms donnés.

La sortie typique ressemble à ceci :

Non couvert : Classe : .ctor ()
Non couvert : Classe : A ()
Non couvert : Driver:.ctor ()
Non couvert : Pilote : méthode ()
Couverture partielle : Conducteur : principal ()
décalage 0x000a

Les décalages affichés sont des décalages IL.

Un outil de couverture plus puissant est disponible dans le module 'monocov'. Voir le monocoque(1)
page de manuel pour plus de détails.

DÉBOGAGE SIDA

Pour déboguer les applications gérées, vous pouvez utiliser le mdb commande, un débogueur en ligne de commande.

Il est possible d'obtenir une trace de pile de tous les threads actifs dans Mono en envoyant le
QUITTER le signal à Mono, vous pouvez le faire à partir de la ligne de commande, comme ceci :

tuer -QUIT pid

Où pid est l'ID de processus du processus Mono que vous souhaitez examiner. Le processus va
continuer à fonctionner par la suite, mais son état n'est pas garanti.

Important: il s'agit d'un mécanisme de dernier recours pour le débogage des applications et ne doit pas être
utilisé pour surveiller ou sonder une application de production. L'intégrité du runtime après
l'envoi de ce signal n'est pas garanti et l'application peut planter ou se terminer à tout
point donné par la suite.

La --debug=diffuse L'option peut être utilisée pour obtenir des informations plus détaillées sur la diffusion invalide
opérations, il fournira des informations sur les types impliqués.

Vous pouvez utiliser les variables d'environnement MONO_LOG_LEVEL et MONO_LOG_MASK pour obtenir des informations détaillées
sortie de débogage sur l'exécution de votre application dans Mono.

La MONO_LOG_LEVEL variable d'environnement si elle est définie, le niveau de journalisation est remplacé par l'ensemble
valeur. Les valeurs possibles sont "error", "critical", "warning", "message", "info", "debug". Les
la valeur par défaut est "erreur". Messages avec un niveau de journalisation supérieur ou égal au journal
level sera imprimé sur stdout/stderr.

Utilisez « info » pour suivre le chargement dynamique des assemblages.

Utilisez l'option MONO_LOG_MASK variable d'environnement pour limiter l'étendue des messages que vous obtenez : Si
défini, le masque de journal est remplacé par la valeur définie. Les valeurs possibles sont "asm" (assembly
loader), "type", "dll" (chargeur de bibliothèque natif), "gc" (garbage collector), "cfg" (config
chargeur de fichiers), « aot » (précompilateur), « sécurité » (par exemple, la prise en charge de Moonlight CoreCLR) et « all ».
La valeur par défaut est "tout". La modification de la valeur du masque vous permet d'afficher uniquement les messages
pour un certain composant. Vous pouvez utiliser plusieurs masques en les séparant par des virgules. Par exemple
pour voir les messages du fichier de configuration et les messages du chargeur d'assembly, définissez votre masque sur "asm, cfg".

Ce qui suit est une utilisation courante pour localiser les problèmes avec P/Invoke :

$ MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono glue.exe

DÉBOGAGE avec LLDB

Si vous utilisez LLDB, vous pouvez utiliser le mono.py script pour imprimer des données internes
structure avec elle. Pour l'utiliser, ajoutez ceci à votre $HOME/.lldbinit fichier:
importation de script de commande $PREFIX/lib/mono/lldb/mono.py

Où $PREFIX est la valeur de préfixe que vous avez utilisée lorsque vous avez configuré Mono (généralement / usr).

Une fois cela fait, vous pouvez inspecter certaines structures de données Mono Runtime, par exemple :
(lldb) méthode p

(MonoMethod *) $0 = 0x05026ac0 [mscorlib]System.OutOfMemoryException :.ctor()

SÉRIALISATION

Le moteur de sérialisation XML de Mono utilisera par défaut une approche basée sur la réflexion pour
sérialiser ce qui peut être lent pour un traitement continu (applications de service Web). Les
moteur de sérialisation déterminera quand une classe doit utiliser un sérialiseur réglé à la main basé sur
quelques paramètres et, si nécessaire, il produira un sérialiseur C# personnalisé pour vos types
à l'exécution. Ce sérialiseur personnalisé est ensuite chargé dynamiquement dans votre
.

Vous pouvez contrôler cela avec la variable d'environnement MONO_XMLSERIALIZER_THS.

Les valeurs possibles sont 'non' pour désactiver l'utilisation d'un sérialiseur personnalisé C#, ou d'un
entier qui est le nombre minimum d'utilisations avant que le runtime ne produise un
sérialiseur (0 produira un sérialiseur personnalisé au premier accès, 50 produira un
sérialiseur à la 50e utilisation). Mono se repliera sur un sérialiseur interprété si le
la génération du sérialiseur échoue en quelque sorte. Ce comportement peut être désactivé en définissant l'option
"pas de repli" (par exemple : MONO_XMLSERIALIZER_THS=0, pas de repli).

ENVIRONNEMENT VARIABLES

GC_DONT_GC
Désactive le ramassage des ordures dans Mono. Cela ne devrait être utilisé que pour le débogage
des fins

LVM_COUNT
Lorsque Mono est compilé avec le support LLVM, cela indique au runtime d'arrêter d'utiliser
LLVM après le nombre spécifié de méthodes sont JITed. Il s'agit d'un outil utilisé dans
diagnostics pour aider à isoler les problèmes dans le backend de génération de code. Par exemple
LLVM_COUNT=10 ne compilerait que 10 méthodes avec LLVM, puis passerait au Mono
Moteur JIT. LLVM_COUNT=0 désactiverait complètement le moteur LLVM.

MONO_AOT_CACHE
Si elle est définie, cette variable demandera à Mono de compiler à l'avance de nouveaux assemblys sur
demander et stocker le résultat dans un cache dans ~/.mono/aot-cache.

MONO_ASPNET_INHIBIT_SETTINGSMAP
Mono contient une fonctionnalité qui permet de modifier les paramètres dans les fichiers .config
livré avec Mono en utilisant des mappeurs de section de configuration. Les mappeurs et la cartographie
les règles sont définies dans le fichier $prefix/etc/mono/2.0/settings.map et, éventuellement, dans
le fichier settings.map qui se trouve dans le répertoire de niveau supérieur de votre application ASP.NET.
Les deux fichiers sont lus par System.Web au démarrage de l'application, s'ils se trouvent au
emplacements ci-dessus. Si vous ne souhaitez pas que le mappage soit effectué, vous pouvez définir ceci
variable dans votre environnement avant de démarrer l'application et aucune action ne sera
pris.

MONO_ASPNET_WEBCONFIG_CACHESIZE
Mono a un cache d'objets ConfigSection pour accélérer WebConfigurationManager
requêtes. Sa taille par défaut est de 100 éléments, et lorsque plus d'éléments sont nécessaires, le cache
les expulsions commencent à se produire. Si les expulsions sont trop fréquentes, cela pourrait imposer
surcharge inutile, qui pourrait être évitée en utilisant cette variable d'environnement pour
configurer une taille de cache plus élevée (ou réduire les besoins en mémoire en la diminuant).

MONO_CAIRO_DEBUG_DISPOSE
Si défini, Mono.Cairo collecte les traces de la pile lorsque les objets sont alloués, donc
que les avertissements de finalisation/Dispose incluent des informations sur l'instance
origine.

MONO_CFG_DIR
Si elle est définie, cette variable remplace le répertoire de configuration système par défaut
($PREFIX/etc). Il est utilisé pour localiser le fichier machine.config.

MONO_COM
Définit le style d'interopérabilité COM. Si la valeur de cette variable est "MS", Mono utilisera
routines de marssalling de chaîne du liboleaut32 pour la bibliothèque de types BSTR, tout
d'autres valeurs utiliseront le marshalling de chaîne BSTR mono-intégré.

MONO_CONFIG
Si elle est définie, cette variable remplace le fichier de configuration d'exécution par défaut
($PREFIX/etc/mono/config). Les options de ligne de commande --config remplacent les
variable d'environnement.

MONO_CPU_ARCH
Ignorer le mécanisme de détection automatique du processeur. Actuellement utilisé uniquement sur le bras. Les
le format de la valeur est le suivant :

"armvV [pouce[2]]"

où V est le numéro d'architecture 4, 5, 6, 7 et les options peuvent être actuellement
"pouce" ou "pouce2". Exemple:

MONO_CPU_ARCH="armv4 thumb" mono ...

MONO_ARM_FORCE_SOFT_FLOAT
Lorsque Mono est construit avec un repli flottant souple sur ARM et que cette variable est définie sur
"1", Mono émettra toujours un code flottant souple, même si une unité VFP est détectée.

MONO_DISABLE_AIO
Si défini, indique à mono de ne PAS essayer d'utiliser les services d'E/S asynchrones natifs. Dans ce
cas, une implémentation de sélection/interrogation par défaut est utilisée. Actuellement, seul epoll() est
prise en charge.

MONO_DISABLE_MANAGED_COLLATION
Si cette variable d'environnement est « oui », le moteur d'exécution utilise un classement non géré (qui
signifie en fait pas de classement sensible à la culture). Il désactive en interne la gestion
fonctionnalité de classement invoquée via les membres de System.Globalization.CompareInfo
classer. L'assemblage est activé par défaut.

MONO_DISABLE_SHM
Unix uniquement : si défini, désactive les fichiers de mémoire partagée utilisés pour les poignées inter-processus :
processus n'ont que des poignées privées. Cela signifie que les descripteurs de processus et de thread sont
non disponible pour les autres processus, et les mutex nommés, les événements nommés et nommés
les sémaphores ne sont pas visibles entre les processus. Ceci peut également être activé par
par défaut en passant l'option "--disable-shared-handles" à configurer. C'est le
par défaut à partir de mono 2.8.

MONO_DISABLE_SHARED_AREA
Unix uniquement : si défini, désactivez l'utilisation de la mémoire partagée pour exposer les performances
compteurs. Cela signifie qu'il ne sera pas possible à la fois de lire les performances en externe
compteurs de ces processus ou lire ceux des processus externes.

MONO_DNS
Lorsqu'il est défini, permet l'utilisation d'un résolveur DNS entièrement géré au lieu du
fonctions libc. Ce résolveur fonctionne bien mieux lorsque plusieurs requêtes sont exécutées dans
parallèle.

Notez que /etc/nsswitch.conf Sera ignoré.

MONO_EGD_SOCKET
Pour les plates-formes qui n'ont pas autrement un moyen d'obtenir des octets aléatoires, cela peut
être défini sur le nom d'un socket du système de fichiers sur lequel un démon egd ou prngd est
écoute.

MONO_ENABLE_SHM
Unix uniquement : activez la prise en charge des descripteurs inter-processus. Les poignées inter-processus sont
utilisé pour exposer les descripteurs de processus, les descripteurs de thread, les mutex nommés, les événements nommés et
sémaphores nommés dans les processus Unix.

MONO_ENV_OPTIONS
Cette variable d'environnement vous permet de passer des arguments de ligne de commande à un Mono
processus à travers l'environnement. Ceci est utile par exemple pour forcer tous vos
Processus mono pour utiliser LLVM ou SGEN sans avoir à modifier les scripts de lancement.

MONO_ENV_OPTIONS
Utilisé pour transmettre des options supplémentaires à l'agent de débogage dans l'environnement d'exécution, telles qu'elles étaient
passé en utilisant --debugger-agent=.

MONO_EVENTLOG_TYPE
Définit le type de fournisseur de journal des événements à utiliser (pour System.Diagnostics.EventLog).
Les valeurs possibles sont :

local[:chemin]
Conserve les journaux d'événements et les entrées dans le système de fichiers local. L'annuaire en
lesquels conserver les journaux d'événements, les sources d'événements et les entrées peuvent être spécifiés
dans le cadre de la valeur. Si le chemin n'est pas explicitement défini, il est par défaut
"/var/lib/mono/eventlog" sous unix et "%APPDATA%no\ventlog" sous Windows.

win32 Utilisations le indigène win32 API à écrire l'évènementiel et registres event journaux et event
sources dans le registre. Ceci n'est disponible que sur Windows. Sous Unix, le
autorisation de répertoire pour les répertoires de journaux d'événements individuels et de sources d'événements
est défini sur 777 (avec + t bit) permettant à tout le monde de lire et d'écrire le journal des événements
entrées tout en autorisant uniquement la suppression des entrées par le ou les utilisateurs qui
les a créés.

nul Ignore silencieusement tous les événements.

La valeur par défaut est "null" sur Unix (et les versions de Windows antérieures à NT), et "win32" sur
Windows NT (et supérieur).

MONO_EXTERNAL_ENCODAGES
Si défini, contient une liste d'encodages de texte séparés par des deux-points à essayer lors de la rotation
texte généré en externe (par exemple, arguments de ligne de commande ou noms de fichiers) en Unicode.
Les noms d'encodage proviennent de la liste fournie par iconv, et le cas particulier
"default_locale" qui fait référence à l'encodage par défaut de la locale actuelle.

Lors de la lecture de chaînes de texte générées en externe, UTF-8 est d'abord essayé, puis
list est essayée dans l'ordre avec la première conversion réussie mettant fin à la recherche.
Lors de l'écriture de texte externe (par exemple de nouveaux noms de fichiers ou arguments pour de nouveaux processus), le
le premier élément de cette liste est utilisé, ou UTF-8 si la variable d'environnement n'est pas définie.

Le problème avec l'utilisation de MONO_EXTERNAL_ENCODINGS pour traiter vos fichiers est qu'il
entraîne un problème : bien qu'il soit possible d'obtenir le bon nom de fichier, ce n'est pas
nécessairement possible d'ouvrir le fichier. En général, si vous avez des problèmes avec
encodages dans vos noms de fichiers, vous devez utiliser le programme "convmv".

MONO_GC_PARAMS
Lors de l'utilisation de Mono avec le ramasse-miettes SGen, cette variable contrôle plusieurs
paramètres du collecteur. La valeur de la variable est une liste séparée par des virgules de
mots.

pépinière-taille=Taille
Définit la taille de la pépinière. La taille est spécifiée en octets et doit être un
puissance de deux. Les suffixes « k », « m » et « g » peuvent être utilisés pour spécifier kilo-,
méga- et gigaoctets, respectivement. La pépinière est la première génération (de
deux). Une pépinière plus grande accélérera généralement le programme mais
utiliser plus de mémoire. La taille de la pépinière par défaut est de 4 Mo.

majeur =collectionneur Spécifie le collecteur principal à utiliser.
Les options sont « marksweep » pour le collecteur Mark&Sweep et « marksweep-conc »
pour Mark&Sweep simultané. Le collecteur Mark&Sweep non simultané est le
défaut.

limite de tas souple =Taille
Une fois que la taille du tas dépasse cette taille, ignorez la valeur par défaut
la métrique de déclenchement de collecte dit et n'autorise que quatre tailles de pépinière majeures
croissance de tas entre les grandes collections.

seuil-d'évacuation=порог
Définit le seuil d'évacuation en pourcentage. Cette option n'est disponible que sur
les grands collectionneurs de Mark&Sweep. La valeur doit être un entier dans la plage
0 à 100. La valeur par défaut est 66. Si la phase de balayage de la collection trouve
que l'occupation d'un type de bloc de tas spécifique est inférieure à cela
pourcentage, il fera une collection de copie pour ce type de bloc dans le prochain
collection majeure, rétablissant ainsi l'occupation à près de 100 pour cent. UNE
la valeur 0 désactive l'évacuation.

(pas-)paresseux-balayage
Active ou désactive le balayage différé pour le collecteur Mark&Sweep. Si activé,
le balayage des principaux blocs de tas est effectué au coup par coup chaque fois que le
le besoin se fait sentir, généralement lors des collectes en pépinière. Le balayage paresseux est activé
par défaut.

(pas) de balayage simultané
Active ou désactive le balayage simultané pour le collecteur Mark&Sweep. Si
activé, l'itération de tous les blocs principaux pour déterminer ceux qui peuvent être
libérés et lesquels doivent être conservés et balayés, se fait en même temps que
le programme en cours. Le balayage simultané est activé par défaut.

marque-pile=marque-mode
Spécifie comment les threads d'application doivent être analysés. Les options sont "précises"
et « conservateur ». Un marquage précis permet au collectionneur de savoir quelles valeurs
sur la pile sont des références et ce qui ne le sont pas. Marquage conservateur menace tous
valeurs comme références potentielles et les laisser intactes. Marquage précis
réduit les déchets flottants et peut accélérer la collecte et l'allocation des pépinières
taux, il a l'inconvénient de nécessiter une mémoire supplémentaire importante par
méthode compilée. La bonne option, malheureusement, nécessite une expérimentation.

ratio de sauvegarde-cible=rapport
Spécifie le taux d'enregistrement cible pour le collecteur principal. Le collectionneur laisse
une quantité donnée de mémoire à promouvoir de la pépinière en raison de
collections avant de déclencher une collection majeure. Ce montant est basé sur
combien de mémoire il s'attend à libérer. Il est représenté par un rapport de la taille
du tas après une importante collecte. Les valeurs valides sont comprises entre 0.1 et 2.0.
La valeur par défaut est 0.5. Des valeurs plus petites maintiendront la taille du tas principal plus petite
mais déclenchera des collections plus importantes. De même, des valeurs plus élevées utiliseront
plus de mémoire et se traduisent par des collectes majeures moins fréquentes. Cette option est
EXPERIMENTAL, il pourrait donc disparaître dans les versions ultérieures de mono.

ratio d'allocation par défaut=rapport
Spécifie l'allocation d'allocation par défaut lorsque la taille calculée est trop
petit. L'allocation d'allocation est la quantité de mémoire que le collecteur laisse être
promu avant de déclencher une importante collecte. C'est un rapport de la pépinière
Taille. Les valeurs valides sont comprises entre 1.0 et 10.0. La valeur par défaut est 4.0. Plus petite
les valeurs conduisent à des tas plus petits et à des collectes majeures plus fréquentes. De même,
des valeurs plus élevées permettront au tas de croître plus rapidement mais utiliseront plus de mémoire lorsqu'il
atteint une taille stable. Cette option est EXPERIMENTALE, elle peut donc disparaître
dans les versions ultérieures de mono.

mineur =mineur-collectionneur
Spécifie le collecteur mineur à utiliser. Les options sont « simples », ce qui favorise
tous les objets de la pépinière directement à l'ancienne génération et 'split'
ce qui permet à l'objet de rester plus longtemps sur la pépinière avant la promotion.

rapport d'allocation =rapport
Spécifie le ratio de mémoire de la pépinière à utiliser par l'espace alloué.
Cela ne peut être utilisé qu'avec le collecteur mineur divisé. Les valeurs valides sont
entiers compris entre 1 et 100. La valeur par défaut est 60.

âge-promotion=âge
Spécifie l'âge requis d'un objet doit atteindre à l'intérieur de la pépinière avant
été promu à l'ancienne génération. Cela ne peut être utilisé qu'avec le
collectionneur mineur divisé. Les valeurs valides sont des nombres entiers compris entre 1 et 14. Par défaut
est 2.

(non-)ciment
Active ou désactive la cimentation. Cela peut considérablement raccourcir la pépinière
temps de collecte sur certains points de repère où les objets épinglés sont référencés
du tas principal.

MONO_GC_DEBUG
Lors de l'utilisation de Mono avec le ramasse-miettes SGen, cette variable d'environnement peut être
utilisé pour activer diverses fonctionnalités de débogage du collecteur. La valeur de ce
variable est une liste de mots séparés par des virgules. N'utilisez pas ces options dans
.

nombre Définit le niveau de débogage au nombre spécifié.

allocation d'impression
Après chaque collection principale imprime la consommation de mémoire avant et après
la perception et l'indemnité pour le percepteur mineur, c'est-à-dire combien le
le tas est autorisé à se développer à partir des collections mineures avant la prochaine majeure
la collecte est déclenchée.

impression-épinglage
Recueille des statistiques sur les classes dont les objets sont épinglés dans la crèche
et pour lesquels des entrées de remset globales sont ajoutées. Imprime ces statistiques lorsque
éteindre.

collecte-avant-allocation

contrôle-aux-petites-collectes
Cela effectue un contrôle de cohérence sur les collections mineures et efface également le
pépinière au moment de la collecte, au lieu de la valeur par défaut, lorsque les tampons sont
alloué (clear-at-gc). Le contrôle de cohérence permet de s'assurer qu'il n'y a pas de
références majeures à mineures qui ne figurent pas sur les ensembles mémorisés.

vérification de cohérence mod-union
Vérifie que la table à cartes mod-union est cohérente avant chaque finition
grande pause de collecte. Cette vérification ne s'applique qu'aux majeures simultanées
collectionneurs.

coche-bits
Vérifie que les bits de marquage dans le tas principal sont cohérents à la fin de chaque
grande collection. Des bits de marquage cohérents signifient que si un objet est marqué,
tous les objets auxquels il avait des références doivent également être marqués.

chèque-pépinière-épinglé
Après les collectes en pépinière et avant de commencer les collectes simultanées, vérifiez
si tous les objets de la pépinière sont épinglés ou non - selon
le contexte. Ne fait rien lorsque le collecteur de pépinière divisé est utilisé.

vérifications xdomain
Effectue une vérification pour s'assurer qu'aucune référence n'est laissée à un non chargé
Domaine d'application.

création claire à la table
Efface la pépinière de manière incrémentielle lorsque le thread local d'allocation tampons
(TLAB) sont créés. Le paramètre par défaut efface toute la pépinière au GC
le temps.

débogage-clair-à-tlab-création
Efface la pépinière de manière incrémentielle lorsque le thread local d'allocation tampons
(TLAB) sont créés, mais au moment du GC le remplit avec l'octet « 0xff », qui
devrait entraîner un plantage plus rapidement si `clear-at-tlab-creation` ne le fait pas
fonctionner correctement.

effacer-à-gc
Cela efface la pépinière au moment du GC au lieu de le faire lorsque le thread local
un tampon d'allocation (TLAB) est créé. La valeur par défaut est de vider la pépinière à
Temps de création du TLAB.

désactiver-mineur
Ne faites pas de collections mineures. Si la pépinière est pleine, une importante collection est
déclenché à la place, à moins qu'il ne soit également désactivé.

désactiver-majeur
Ne faites pas de grandes collections.

marque-stack-conservatrice
Force le CPG à balayer la pile de manière prudente, même si un balayage précis est
disponible.

allocateur-non-géré
Désactive l'allocateur géré.

check-scan-démarre
Si défini, effectue un contrôle de plausibilité sur le scan_starts avant et après chaque
collection

vérifier-nursery-at-minor-gc
S'il est défini, fait une promenade d'objets complète de la pépinière au début de chaque
collection mineure.

dépotoir-nursery-at-minor-gc
Si défini, vide le contenu de la pépinière au début de chaque mineur
collection. Nécessite que verify-nursery-at-minor-gc soit défini.

vidage de tas =filet
Vide le contenu du tas dans le fichier spécifié. Pour visualiser le
informations, utilisez l'outil mono-heapviz.

protocole-binaire=filet
Génère la sortie de débogage dans le fichier spécifié. Pour que cela fonctionne, Mono
doit être compilé avec le BINARY_PROTOCOL défini sur sgen-gc.c. Vous pouvez
puis utilisez cette commande pour explorer la sortie
sgen-grep-binprot 0x1234 0x5678 < fichier

pépinière-canaris
Si défini, les objets alloués dans la pépinière sont suffixés avec un canari (garde)
mot, qui est vérifié sur chaque collection mineure. Peut être utilisé pour détecter/déboguer
problèmes de corruption de tas.

ne-pas-finaliser
Si activé, les finaliseurs ne seront pas exécutés. Tout le reste ne sera pas affecté :
les objets finalisables seront toujours placés dans la file d'attente de finalisation où ils
survivre jusqu'à ce qu'ils soient finalisés. Une fois qu'ils ne sont pas dans la file d'attente
ils seront désormais collectés régulièrement.

finaliseurs de journaux
Connectez-vous en détail autour du processus de finalisation pour faciliter le débogage.

MONO_GAC_PREFIX
Fournit un préfixe que le runtime utilise pour rechercher les Global Assembly Caches. Annuaires
sont séparés par le séparateur de chemin de plate-forme (deux-points sous unix). MONO_GAC_PREFIX
doit pointer vers le répertoire supérieur d'une installation préfixée. Ou vers l'annuaire
fourni dans la commande gacutil /gacdir. Exemple:
/home/nom d'utilisateur/.mono:/usr/local/mono/

MONO_IOMAP
Permet une prise en charge de la réécriture de noms de fichiers pour aider les applications mal écrites qui
coder en dur les chemins Windows. Définir sur une liste de « lecteur » séparés par des deux-points pour supprimer le lecteur
lettres, ou "case" pour faire une correspondance de fichier insensible à la casse dans chaque répertoire d'un
chemin. "all" active toutes les méthodes de réécriture. (Les barres obliques inverses sont toujours mappées sur
barres obliques si cette variable est définie sur une option valide).
Par exemple, cela fonctionnerait à partir du shell :

MONO_IOMAP=lecteur:boîtier
exporter MONO_IOMAP

Si vous utilisez mod_mono pour héberger vos applications Web, vous pouvez utiliser le MonoIOMAP
à la place, comme ceci :

MonoIOMAP tous

See mod_mono(8) pour plus de détails.

En outre. Mono comprend un module de profilage qui permet de suivre ce que
ajustements aux chemins de fichiers que le code IOMAP doit faire. Le code de suivi signale le
emplacement géré (trace de pile complète) à partir duquel l'appel IOMAP a été effectué et, sur
sortie du processus, les emplacements où toutes les chaînes IOMAP-ed ont été créées dans géré
code. Ce dernier rapport n'est qu'approximatif car il n'est pas toujours possible de
estimer l'emplacement réel où la chaîne a été créée. Le code utilise simple
heuristique - il analyse la trace de la pile remontant à l'emplacement d'allocation de la chaîne
et ignore également tout le code managé qui réside dans les assemblys installés dans GAC
comme dans les bibliothèques de classes livrées avec Mono (puisqu'elles sont supposées être libres de
problèmes de sensibilité à la casse). Il signale ensuite le premier emplacement dans le code de l'utilisateur -
dans la plupart des cas, ce sera l'endroit où la chaîne est allouée ou très proche de
l'emplacement. Le code de rapport est implémenté en tant que module de profilage personnalisé (voir
la section "PROFILAGE") et peut être chargé de la manière suivante :

mono --profile=iomap votreapplication.exe

Notez, cependant, que Mono ne prend actuellement en charge qu'un seul module de profilage à la fois.

MONO_LLVM
Lorsque Mono utilise le backend de génération de code LLVM, vous pouvez utiliser cet environnement
variable pour passer les options de génération de code au compilateur LLVM.

MONO_MANAGED_WATCHER
Si défini sur "désactivé", System.IO.FileSystemWatcher utilisera un observateur de fichiers
implémentation qui ignore silencieusement toutes les demandes de surveillance. Si défini sur n'importe quel
autre valeur, System.IO.FileSystemWatcher utilisera la valeur par défaut gérée
mise en œuvre (lente). S'il n'est pas défini, mono essaiera d'utiliser inotify, FAM, Gamin, kevent
sous les systèmes Unix et les appels d'API natifs sur Windows, retombant sur le
mise en œuvre sur erreur.

MONO_MESSAGING_PROVIDER
Mono prend en charge un modèle de plugin pour son implémentation de System.Messaging, ce qui en fait
possible de prendre en charge une variété d'implémentations de messagerie (par exemple AMQP, ActiveMQ).
Pour spécifier quelle implémentation de messagerie doit être utilisée, la variable evironement
doit être défini sur le nom de classe complet du fournisseur. Par exemple, pour utiliser le RabbitMQ
basée sur l'implémentation AMQP, la variable doit être définie sur :

Mono.Messaging.RabbitMQ.RabbitMQMessagingProvider,Mono.Messaging.RabbitMQ

MONO_NO_SMP
Si défini, le processus mono est lié à un seul processeur. Cela peut être
utile lors du débogage ou pour contourner les conditions de course.

MONO_NO_TLS
Désactivez l'inlining des accès locaux aux threads. Essayez de régler ceci si vous obtenez une erreur de segmentation
au début de l'exécution de mono.

MONO_CHEMIN
Fournit un chemin de recherche vers le runtime où rechercher la bibliothèque
des dossiers. C'est un outil pratique pour le débogage des applications, mais
ne doit pas être utilisé par les applications déployées car cela casse l'assemblage
chargeur de manière subtile.
Les répertoires sont séparés par le séparateur de chemin de plate-forme (deux-points sous unix). Exemple:
/home/nom d'utilisateur/lib:/usr/local/mono/lib
Les chemins relatifs sont résolus en fonction du répertoire actuel au moment du lancement.
Les solutions alternatives à MONO_PATH incluent : l'installation de bibliothèques dans
le Global Assembly Cache (voir gacutil(1)) ou avoir la personne à charge
bibliothèques côte à côte avec l'exécutable principal.
Pour une description complète des pratiques recommandées pour l'application
déploiement, voir
http://www.mono-project.com/docs/getting-started/application-deployment/

MONO_RTC
Prise en charge expérimentale du RTC dans le profileur statistique : si l'utilisateur a
l'autorisation, des statistiques plus précises sont recueillies. Le MONO_RTC
la valeur doit être limitée à ce que le Linux rtc permet : puissance de deux
de 64 à 8192 Hz. Pour activer des fréquences plus élevées comme 4096 Hz, exécutez en tant que root :

echo 4096 > /proc/sys/dev/rtc/max-user-freq

Par exemple :

MONO_RTC=4096 mono --profiler=default:stat program.exe

MONO_SHARED_DIR
S'il est défini, il s'agit du répertoire dans lequel l'état du handle ".wapi" est stocké. C'est le
répertoire dans lequel la couche d'émulation d'E/S Windows stocke ses données d'état partagées
(fichiers, événements, mutex, tuyaux). Par défaut, Mono stockera le répertoire ".wapi"
dans le répertoire personnel des utilisateurs.

MONO_SHARED_HOSTNAME
Utilise la valeur de chaîne de cette variable en remplacement du nom d'hôte lorsque
création de noms de fichiers dans le répertoire ".wapi". Cela aide si le nom d'hôte de votre
machine est susceptible d'être modifiée lorsqu'une application mono est en cours d'exécution ou si vous avez un
Répertoire .wapi partagé entre plusieurs ordinateurs différents. Mono utilise généralement le
nom d'hôte pour créer les fichiers qui sont utilisés pour partager l'état entre plusieurs Mono
processus. Ceci est fait pour prendre en charge les répertoires personnels qui pourraient être partagés sur le
réseau.

MONO_STRICT_IO_EMULATION
S'il est défini, des vérifications supplémentaires sont effectuées pendant les opérations d'E/S. Actuellement, cela ne comprend que
verrous consultatifs autour des écritures de fichiers.

MONO_THEME
Le nom du thème à utiliser par Windows.Forms. Les thèmes disponibles aujourd'hui incluent
"clearlooks", "nice" et "win32". La valeur par défaut est "win32".

MONO_TLS_SESSION_CACHE_TIMEOUT
La durée, en secondes, pendant laquelle le cache de session SSL/TLS conservera son entrée pour éviter
une nouvelle négociation entre le client et un serveur. Les négociations sont très CPU
intensif, donc une valeur personnalisée spécifique à l'application peut s'avérer utile pour les petits
systèmes embarqués. La valeur par défaut est de 180 secondes.

MONO_THREADS_PER_CPU
Le nombre minimum de threads dans le pool de threads général sera
MONO_THREADS_PER_CPU * nombre de processeurs. La valeur par défaut de cette variable est 1.

MONO_XMLSERIALIZER_THS
Contrôle le seuil du XmlSerializer pour produire un sérialiseur personnalisé pour un
classe donnée au lieu d'utiliser l'interpréteur basé sur Reflection. Les valeurs possibles
sont « non » pour désactiver l'utilisation d'un sérialiseur personnalisé ou un numéro pour indiquer quand le
XmlSerializer devrait commencer la sérialisation. La valeur par défaut est 50, ce qui signifie que
un sérialiseur personnalisé sera produit à la 50e utilisation.

MONO_X509_REVOCATION_MODE
Définit le mode de révocation utilisé lors de la validation d'une chaîne de certificats X509 (https,
ftps, smtps...). La valeur par défaut est 'nocheck', qui n'effectue aucune vérification de révocation à
tous. Les autres valeurs possibles sont « hors ligne », qui effectue une vérification CRL (pas
mis en œuvre encore) et « en ligne » qui utilise OCSP et CRL pour vérifier la révocation
statut (pas encore implémenté).

ENVIRONNEMENT VARIABLES POUR DÉBOGAGE

MONO_ASPNET_NODELETE
Si défini sur n'importe quelle valeur, les fichiers source temporaires générés par les classes de support ASP.NET
ne sera pas supprimé. Ils seront conservés dans le répertoire temporaire de l'utilisateur.

MONO_DEBUG
Si défini, active certaines fonctionnalités de l'environnement d'exécution utiles pour le débogage. Cette variable
doit contenir une liste d'options de débogage séparées par des virgules. Actuellement, le
les options suivantes sont prises en charge :

pause-sur-non vérifié
Si cette variable est définie, lorsque la VM Mono rencontre un problème de vérification,
au lieu de lever une exception, il s'introduira dans le débogueur. C'est
utile lors du débogage des problèmes de vérificateur

jette Cette option peut être utilisée pour obtenir des informations plus détaillées d'InvalidCast
exceptions, il fournira des informations sur les types impliqués.

collecter-pagefault-stats
Collecte des informations sur les défauts de page. Ceci est utilisé en interne pour suivre
le nombre de défauts de page produits pour charger les métadonnées. Pour afficher ce
informations, vous devez utiliser cette option avec l'option de ligne de commande "--stats".

dont-domaines-libres
Il s'agit d'une optimisation pour les applications multi-AppDomain (le plus souvent
applications ASP.NET). En raison de limitations internes Mono, Mono par défaut
n'utilise pas d'allocations typées sur les applications multi-appDomain car elles pourraient
fuite de mémoire lorsqu'un domaine est déchargé. Bien qu'il s'agisse d'une bonne valeur par défaut, pour
applications qui utilisent beaucoup plus que sur AppDomain (par exemple, ASP.NET
applications), il vaut la peine d'échanger les petites fuites contre l'augmentation
performances (de plus, étant donné que les applications ASP.NET ne vont probablement pas
pour décharger les domaines d'application sur les systèmes de production, il vaut la peine d'utiliser
cette fonctionnalité).

dyn-runtime-invoquer
Demande à l'environnement d'exécution d'essayer d'utiliser un wrapper générique d'appel d'exécution à la place
de créer un wrapper d'appel.

gdb Équivaut à régler le MONO_XDEBUG variable, cela émet des symboles dans un
bibliothèque partagée car le code est JITed qui peut être chargé dans GDB pour inspecter
symboles

points de génération
Génère automatiquement des points de séquence où la pile IL est vide. Ces
sont des endroits où le débogueur peut définir un point d'arrêt.

explicite-null-checks
Fait en sorte que le JIT génère une vérification NULL explicite sur les déréférencements de variables
au lieu de dépendre du système d'exploitation pour lever un SIGSEGV ou un autre
forme d'événement d'interruption lorsqu'un emplacement mémoire non valide est accédé.

poignée-sigint
Capture le signal d'interruption (Control-C) et affiche une trace de pile lorsque
pressé. Utile pour savoir où le programme s'exécute à un moment donné
point. Cela n'affiche que la trace de pile d'un seul thread.

init-piles
Demande au runtime d'initialiser la pile avec des valeurs connues (0x2a
sur x86-64) au début d'une méthode d'aide au débogage du moteur JIT.

garder-délégués
Cette option fera fuir les trampolines délégués qui ne sont plus référencés comme
pour présenter à l'utilisateur plus d'informations sur une utilisation abusive d'un délégué.
Fondamentalement, une instance de délégué peut être créée, transmise au code non managé,
et aucune référence conservée dans le code managé, ce qui récupèrera le code.
Avec cette option, il est possible de localiser la source des problèmes.

exceptions-pinvoke-inverses
Cette option entraînera l'abandon de mono avec un message descriptif lors de la
pile se déroulant après une exception, il atteint un cadre de pile natif. Cette
se produit lorsqu'un délégué managé est passé au code natif et que le
le délégué lève une exception. Mono essaiera normalement de dérouler la pile pour
le premier gestionnaire d'exceptions (géré), et il ignorera toute pile native
cadres dans le processus. Cela conduit à un comportement indéfini (puisque mono ne
savoir comment traiter les trames natives), les fuites et éventuellement les plantages aussi.

pas de trace arrière gdb
Cette option désactivera le backtrace GDB émis par le runtime après un
SIGSEGV ou SIGABRT en code non managé.

suspendre-sur-sigsegv
Cette option suspend le programme lorsqu'un SIGSEGV natif est reçu.
Ceci est utile pour déboguer les plantages qui ne se produisent pas sous gdb, car un
live process contient plus d'informations qu'un fichier core.

vérifier-pinvoke-callconv
Cette option permet au runtime de vérifier les incohérences de convention d'appel
lors de l'utilisation de pinvoke, c'est-à-dire en mélangeant cdecl/stdcall. Cela ne fonctionne que sur windows. Si
une incompatibilité est détectée, une ExecutionEngineException est levée.

MONO_LOG_LEVEL
Le niveau de journalisation, les valeurs possibles sont 'error', 'critical', 'warning', 'message',
« info » et « débogage ». Voir la section DEBOGAGE pour plus de détails.

MONO_LOG_MASK
Contrôle le domaine de l'environnement d'exécution Mono auquel la journalisation s'appliquera. S'il est défini, le
le masque de journal est remplacé par la valeur définie. Les valeurs possibles sont "asm" (assembly loader),
"type", "dll" (chargeur de bibliothèque natif), "gc" (garbage collector), "cfg" (fichier de configuration
loader), "aot" (précompilateur), "security" (par exemple, prise en charge de Moonlight CoreCLR) et
"tous". La valeur par défaut est "tout". La modification de la valeur du masque vous permet d'afficher
uniquement des messages pour un certain composant. Vous pouvez utiliser plusieurs masques par virgule
les séparant. Par exemple pour voir les messages du fichier de configuration et le chargeur d'assembly
les messages définissent votre masque sur "asm,cfg".

MONO_TRACE
Utilisé pour le suivi d'exécution des appels de méthode. Le format de la trace séparée par des virgules
options est :

[-]M:nom de la méthode
[-]N:espace de noms
[-]T:nom de la classe
[-]tous
[-]programme
désactivé Sortie de trace désactivée au démarrage.

Vous pouvez activer/désactiver la sortie de trace en envoyant un signal SIGUSR2 au programme.

MONO_TRACE_LISTENER
Si défini, active le System.Diagnostics.DefaultTraceListener, qui imprimera le
sortie des classes System.Diagnostics Trace et Debug. Il peut être réglé sur un
nom de fichier et à Console.Out ou Console.Error pour afficher la sortie sur la sortie standard
ou erreur standard, respectivement. S'il est défini sur Console.Out ou Console.Error vous
peut ajouter un préfixe facultatif qui sera utilisé lors de l'écriture de messages comme celui-ci :
Console.Error:MyProgramName. Voir System.Diagnostics.DefaultTraceListener
documentation pour plus d'informations.

MONO_WCF_TRACE
Cela facilite la fonctionnalité de diagnostic WCF en sortant simplement tous les messages de journal de
moteur WCF vers "stdout", "stderr" ou tout fichier passé à cette variable d'environnement.
Le format du journal est le même que la sortie de diagnostic habituelle.

MONO_XEXCEPTIONS
Cela lève une exception lorsqu'une erreur X11 est rencontrée ; par défaut un message est
affiché mais l'exécution continue

MONO_XMLSERIALIZER_DEBUG
Définissez cette valeur sur 1 pour empêcher le sérialiseur de supprimer les fichiers temporaires
qui sont créés pour une sérialisation rapide ; Cela peut être utile lors du débogage.

MONO_XSYNC
Ceci est utilisé dans l'implémentation System.Windows.Forms lors de l'exécution avec le X11
arrière-plan. Ceci est utilisé pour déboguer les problèmes dans Windows.Forms car il force tous les
les commandes envoyées au serveur X11 doivent être exécutées de manière synchrone. Le mode par défaut de
le fonctionnement est asynchrone, ce qui rend difficile l'isolement de la racine de certains
problèmes.

MONO_GENERIC_SHARING
Cette variable d'environnement contrôle le type de partage générique utilisé. Cette variable
est utilisé par les développeurs JIT internes et ne doit pas être modifié en production. Ne pas
utilise le. La variable contrôle quelles classes auront le partage de code générique
activée. Les valeurs autorisées sont :

tous Tout le code généré peut être partagé.

collections
Seules les classes de System.Collections.Generic auront leur code partagé
(Ceci est la valeur par défault).

corlib Seul le code dans corlib aura son code partagé.

aucun Aucun partage de code générique ne sera effectué.
Le partage de code générique par défaut ne s'applique qu'aux collections. Le Mono JIT par défaut
active ceci.

MONO_XDEBUG
Lorsque la variable d'environnement MONO_XDEBUG est définie, les informations de débogage pour le code JITted sont émises
dans une bibliothèque partagée, chargeable dans gdb. Cela permet, par exemple, de voir géré
les noms de trames sur les backtraces gdb.

MONO_VERBOSE_METHOD
Active la verbosité JIT maximale pour la méthode spécifiée. C'est très utile
pour diagnostiquer les problèmes de mauvaise compilation d'une méthode spécifique.

MONO_VERBOSE_HWCAP
Si défini, rend les informations de sortie JIT sur les fonctionnalités de CPU détectées (telles que SSE,
CMOV, FCMOV, etc.) vers stdout.

MONO_CONSERVATIVE_HWCAP
S'il est défini, le JIT n'effectuera aucune détection de capacité matérielle. Cela peut être
utile pour identifier la cause des problèmes JIT. C'est la valeur par défaut lorsque Mono est construit
en tant que compilateur croisé AOT, afin que le code généré s'exécute sur la plupart des matériels.

VALGRIND

Si vous souhaitez utiliser Valgrind, vous trouverez le fichier `mono.supp' utile, il contient les
suppressions pour le GC qui déclenchent des avertissements incorrects. Utilisez-le comme ceci :
valgrind --suppressions=mono.supp mono ...

TRACE

Sur certaines plates-formes, Mono peut exposer un ensemble de sondes DTrace (également appelées user-land
défini statiquement, sondes USDT).

Ils sont définis dans le fichier 'mono.d'.

ves-init-begin, ves-init-fin
Début et fin de l'initialisation de l'exécution.

méthode-compiler-commencer, méthode-compilation-fin
Début et fin de la compilation de la méthode. Les arguments de la sonde sont le nom de la classe, la méthode
nom et signature, et en cas de succès ou d'échec de la méthode de compilation
compilation.

gc-commencer, gc-fin
Début et fin de la collecte des ordures.

Pour vérifier la disponibilité des sondes, exécutez :
dtrace -P mono'$cible' -l -c mono

PERMISSIONS

L'implémentation Ping de Mono pour détecter l'accessibilité du réseau peut créer les paquets ICMP
lui-même sans avoir besoin de la commande ping du système pour effectuer le travail. Si vous souhaitez activer
ceci sur Linux pour les utilisateurs non root, vous devez donner des autorisations spéciales au binaire Mono.

En tant que root, exécutez cette commande :
# setcap cap_net_raw=+ep /usr/bin/mono

Utilisez mono en ligne en utilisant les services onworks.net