Charger des dll à partir de la variable d'environnement Path à partir d'un service

Question

Nous installons Matlab Runtime sur une machine, puis nous redémarrons un service Windows .net qui appelle des méthodes à partir de Matlab Runtime.
Le problème est que nous recevons des erreurs TypeInitializationException jusqu'au redémarrage de Windows. Nous pensons que cela se produit car les les variables d'environnement ne sont pas modifiées sur les services jusqu'au redémarrage et que Matlab utilise le% Path % variable pour référencer ses DLL principales.
Ma question est la suivante: pensez-vous que je peux modifier la variable% Path% afin que Matlab l'utilise lors du référencement de la DLL principale pour son moteur?
Ou est-il possible d’ajouter un répertoire au mécanisme de chargement des DLL d’exécution de .NET afin que ces dll de base Matlab soient correctement référencées sans redémarrer la machine?

Voici l'exception que nous obtenons

System.TypeInitializationException: The type initializer for 'MatlabCalculation.Calculation' threw an exception. ---> System.TypeInitializationException: The type initializer for 'MathWorks.MATLAB.NET.Utility.MWMCR' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'mclmcrrt710.dll': Kan opgegeven module niet vinden. (Exception from HRESULT: 0x8007007E)
   at MathWorks.MATLAB.NET.Utility.MWMCR.mclmcrInitialize()
   at MathWorks.MATLAB.NET.Utility.MWMCR..cctor()
   --- End of inner exception stack trace ---
   at MatlabCalculation.Calculation..cctor()
   --- End of inner exception stack trace ---
   at MatlabCalculation.Calculation.Finalize()

" Kan opgegeven module niet vinden " = "Le module spécifié n'a pas été trouvé"

Answer 1

Si vous pouvez réécrire le service, vous pouvez utiliser le System. Environnement . Méthodes .GetEnvironmentVariable et SetEnvironmentVariable dans le code .NET et ajoutez vous-même le chemin du moteur d’exécution Matlab. Si vous ne pouvez pas réécrire le service, vous pouvez essayer net stop / net démarrez ou installutil , qui agit sur les services. Ou vous pouvez demander sur ServerFault.

ANCIENNE RÉPONSE parce que j'ai mal compris la question:

Le composant MATLAB démarre-t-il puis lance-t-il l'exception? Si tel est le cas, le CTFROOT, TOOLBOXDIR, et Les fonctions ADDPATH pourraient vous aider. Peut-être quelque chose comme:

if isdeployed
    addpath(ctfroot);
    addpath(toolboxdir('signal'));
    %more addpath(toolboxdir('toolboxname')) statements
end

Mais si MATLAB ne commence pas du tout, cela ne changera rien.

Answer 2

Cela pourrait vous aider dans votre réflexion "ou est-il possible d'ajouter un répertoire au mécanisme de chargement des DLL d'exécution de .NET afin que ces dll core de Matlab soient correctement référencées sans redémarrer l'ordinateur":

Dans une application, j'utilise le code suivant pour indiquer à .NET où trouver les assemblys lorsqu'il essaie de les charger de manière dynamique. Dans mon cas, j'en ai besoin, car mon application est chargée en tant qu'extension d'un autre programme. Par conséquent, mes dll ne se trouvent pas dans le même répertoire que l'application. Peut-être que cela s’applique également à vous?

Dans mon cas, la DLL de mon application principale est chargée correctement, car elle est enregistrée pour COM interop. Mais je dois effectuer les opérations suivantes pour que MS Enterprise Library puisse charger ses assemblys, à cause de la manière dont il le fait de façon très dynamique. Le code suivant indique à .NET de rechercher dans le répertoire de l'assembly en cours d'exécution lors de la recherche d'assemblys à charger. Vous pouvez faire de même avec tous les répertoires dans lesquels vous souhaitez que .NET consulte, par exemple. ceux basés sur des variables d'environnement.

using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;
using System.IO;

namespace CommonClasses
{
    /// <summary>
    /// Helper class to ensure the Common Language Runtime can dynamically load our referenced dlls.
    /// Because our components are called from COM via iexplore.exe the executing directory is likely to be something like 
    /// c:\program files\internet explorer\, which obviously doesn't contain our assemblies. This only seems to be a problem
    /// with the Enterprise Library so far, because it dynamically loads the assemblies it needs.
    /// This class helps by directing the CLR to use the directory of this assembly when it can't find the assembly 
    /// normally. The directory of this assembly is likely to be something like c:\program files\my program\
    /// and will contain all the dlls you could ask for.
    /// </summary>
    public static class AssemblyResolveAssistant
    {

        /// <summary>
        /// Records whether the AssemblyResolve event has been wired.
        /// </summary>
        private static bool _isWired = false;

        /// <summary>
        /// Add the handler to enable assemblies to be loaded from this assembly's directory, if it hasn't 
        /// already been added.
        /// </summary>
        public static void AddAssemblyResolveHandler()
        {
            if (!_isWired)
            {
                AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);
                _isWired = true;
            }
        }

        /// <summary>
        /// Event handler that's called when the CLR tries to load an assembly and fails.
        /// </summary>
        /// <param name="sender"></param>
        /// <param name="args"></param>
        /// <returns></returns>
        static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
        {
            Assembly result = null;
            // Get the directory where we think the assembly can be loaded from.
            string dirName = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
            AssemblyName assemblyName = new AssemblyName(args.Name);
            assemblyName.CodeBase = dirName;
            try
            {
                //Load the assembly from the specified path.
                result = Assembly.Load(assemblyName);
            }
            catch (Exception) { }
            //Return the loaded assembly, or null if assembly resolution failed.
            return result;
        }
    }
}

Appelez ensuite la méthode AssemblyResolveAssistant.AddAssemblyResolveHandler () avant de faire quoi que ce soit qui nécessitera le chargement d'assemblys en dehors des dossiers normaux.

Answer 3

à partir de: http://www.mathworks.com/support/solutions/fr/data/1-A1A70V/index.html?product=MN&solution=1-A1A70V

Solution: Lorsque l'application Web appelle la fonction CreateEnvironmentBlock pour récupérer les variables d'environnement sur un ordinateur Microsoft Windows Server 2003 ou Microsoft Windows XP, la variable d'environnement de chemin d'accès renvoyée est tronquée à 1 024 octets. Ce problème se produit même si la taille maximale d'une variable d'environnement est 2 048 octets. Ce problème empêche l’application Web d’obtenir la variable d’environnement correcte.

Plus précisément, les répertoires d’exécution du compilateur MATLAB sur le PATH peuvent avoir été tronqués dans la variable d’environnement PATH renvoyée.

Pour résoudre le problème, effectuez l'une des opérations suivantes:

1) Ajoutez les répertoires d'exécution MATLAB Compiler au début de la variable PATH existante.

2) Obtenez un correctif pour ce problème sur le site Web Microsoft suivant. http://support.microsoft.com/kb/906469