Chargement des assemblys .NET Framework
- Mise à jour2025-08-27
- Temps de lecture : 3 minute(s)
Si vous faites référence à un objet .NET de la face-avant ou du diagramme d'un VI, assurez-vous que LabVIEW peut charger l'assembly .NET pour cet objet. C'est le CLR (Common Language Runtime) qui doit trouver les assemblys .NET Framework que vous appelez. Reportez-vous au site Web Microsoft Developer Network (MSDN) pour obtenir de plus amples informations sur la façon dont le CLR trouve les assemblys. Si le CLR ne parvient pas à trouver l'assembly, LabVIEW recherche l'assembly de la même façon qu'il recherche les VIs manquants. LabVIEW recherche les VIs manquants dans les répertoires que vous spécifiez sur la page Chemins de la boîte de dialogue Options. Si LabVIEW ne parvient pas à trouver l'assembly .NET pour un objet .NET référencé directement sur la face-avant ou le diagramme, il génère une erreur au chargement. Si LabVIEW ne parvient pas à charger un assembly dépendant qui est nécessaire à l'exécution, il génère une erreur à l'exécution.
Le CLR utilise le répertoire de l'exécutable en cours d'exécution comme chemin de recherche par défaut lorsqu'il charge les assemblys .NET privés. Si vous faites référence à un objet .NET à partir d'un VI qui n'appartient pas à un projet LabVIEW, le CLR considère que LabVIEW.exe est l'exécutable en cours d'exécution. Par conséquent, le LCR recherche les assemblys privés dans le répertoire qui contient le fichier LabVIEW.exe. Si vous faites référence à un objet .NET à partir d'un VI qui appartient à un projet LabVIEW, le CLR considère que le projet est l'exécutable en cours d'exécution. Par conséquent, le CLR recherche les assemblys privés dans le répertoire du projet. Si vous faites référence à un assembly .NET à partir d'un VI et que l'assembly n'appartient pas au .NET, NI vous conseille fortement de stocker le VI dans un projet pour ne pas avoir à mettre les fichiers dans le répertoire où se trouve le fichier LabVIEW.exe.
Si vous appelez un assembly .NET Framework à partir d'un VI qui n'appartient pas à un projet, vous pouvez en théorie enregistrer l'assembly dans le même répertoire que le VI qui l'appelle. Par défaut, LabVIEW recherche les assemblys que le CLR ne peut pas charger dans les répertoires de certains VIs, y compris le répertoire du VI appelant. Cependant, l'appel d'assemblys stockés à cet emplacement risque de produire des conflits de noms et un comportement .NET Framework inattendu. Par conséquent, NI ne vous recommande pas d'enregistrer les assemblys à cet emplacement.
Détection des changements apportés aux assemblys en mémoire
Une fois que LabVIEW charge un assembly en mémoire, l'assembly reste en mémoire jusqu'à ce que vous fermiez l'instance d'application qui a chargé l'assembly. Tant qu'un assembly est en mémoire, LabVIEW ne détecte pas les changements que vous effectuez sur l'assembly sur disque. Par conséquent, avant que LabVIEW ne puisse accéder aux changements apportés à l'assembly, vous devez mettre la version de l'assembly en mémoire à jour.
Chargement de VIs après avoir modifié un assembly
Microsoft Visual Studio .NET et d'autres outils de développement fournis avec .NET SDK peuvent assigner des noms fort à un assembly. Les assemblys ayant le même nom fort devraient être identiques.
Lorsque vous chargez un VI avec changement de chemin d'un assembly .NET, ou avec changement du numéro de version ou de la chaîne de culture d'un assembly à nom fort, LabVIEW lance une boîte de dialogue de mise en garde pour vous informez du changement. Une fois chargé, un astérisque apparaît dans la barre de titre du VI et dans la liste des VIs ouverts affichés dans le menu Fenêtre. Lorsque vous enregistrez le VI, l'astérisque disparaît jusqu'au prochain changement.
Si vous chargez un VI avec un changement de l'horodatage d'un assembly .NET Framework, LabVIEW ne lance pas de boîte de dialogue de mise en garde mais affiche un astérisque dans la barre de titre du VI.
Reportez-vous à la Base de connaissances de ni.com pour obtenir des informations complémentaires sur comment sélectionner et charger des versions d'assemblys .NET spécifiques.