Utilisation d'une DLL non managée dans une application ASP.NET
8 réponses
Tugrul Ebabil
Bonjour,
nous essayons d'utiliser une assembly non managée au sein d'une application
ASP.NET mais nous n'y arrivons pas. Voici la description du problème :
Contexte logiciel :
Serveur : Windows Server 2003.
IIS 6.0
AspNet 2.0.50727
Redistribuable Visual Studio 2005 installé.
Site et assembly compilés avec Visual Studio 2005.
Framework 2.0.50727.
Enoncé du problème :
Lors de l’exécution d’un site ASP.NET, on fait appel à du code non managé
écrit en C++. Afin de réaliser ceci, un wrapper C++ managé est utilisé pour
permettre l’appel depuis une page du site. Pour pouvoir être publié avec le
site et intégré dans le wrapper, la dll non managée supporte la CLR (mais
aucune modification de code n’a été effectuée).
Le wrapper supporte la CLR oldsyntaxe. Les deux assembly sont ajoutées aux
références du site web et sont placées sous le répertoire bin du site.
Sur le PC de développement, tout se déroule correctement.
Sur le Serveur, le message suivant apparaît:
Le module spécifié est introuvable. (Exception de HRESULT :
0x8007007E)
Description : Une exception non gérée s'est produite au moment de
l'exécution de la demande Web actuelle. Contrôlez la trace de la pile pour
plus d'informations sur l'erreur et son origine dans le code.
Détails de l'exception: System.IO.FileNotFoundException: Le module spécifié
est introuvable. (Exception de HRESULT : 0x8007007E)
Erreur source:
Une exception non gérée s'est produite lors de l'exécution de la demande Web
actuelle. Les informations relatives à l'origine et l'emplacement de
l'exception peuvent être identifiées en utilisant la trace de la pile
d'exception ci-dessous.
Informations sur la version : Version Microsoft .NET Framework
:2.0.50727.832; Version ASP.NET :2.0.50727.832
Les mêmes assembly appelées par une application WinForms fonctionnent en
étant sous le répertoire courant de l‘application.
Le déplacement de la dll non managée et du wrapper sous Windows\System32
résout le problème mais n’est évidemment pas une solution envisageable.
Il ne s’agit pas d’un problème de sécurité, les droits trust level sont à
Full sous web.config.
Des recherches sur Internet nous ont amené à tenter les résolutions
suivantes :
- Nommage fort de la dll C++ non managée (snk + version + langue). Ajout de
la clé dans le fichier web_mediumtrust.config et passage du trust level à
Medium dans web.config. -> aucun résultat.
- Ajout de l’assembly C++ non managée dans le GAC. -> aucun résultat.
- Nommage fort de la dll C++ non managée et du wrapper (snk + version +
langue). Ajout de la clé dans le fichier web_mediumtrust.config et passage du
trust level à Medium dans web.config. -> aucun résultat.
- Ajout de la dll C++ non managée et du wrapper dans le GAC. -> aucun
résultat.
Est-ce que quelqu'un aurait une solution à ce problème ? Merci d'avance pour
votre aide.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gilles TOURREAU [MVP]
"Tugrul Ebabil" a écrit dans le message de news:
Bonjour,
nous essayons d'utiliser une assembly non managée au sein d'une application ASP.NET mais nous n'y arrivons pas. Voici la description du problème :
Contexte logiciel :
Serveur : Windows Server 2003. IIS 6.0 AspNet 2.0.50727 Redistribuable Visual Studio 2005 installé. Site et assembly compilés avec Visual Studio 2005. Framework 2.0.50727.
Enoncé du problème :
Lors de l’exécution d’un site ASP.NET, on fait appel à du code non managé écrit en C++. Afin de réaliser ceci, un wrapper C++ managé est utilisé pour permettre l’appel depuis une page du site. Pour pouvoir être publié avec le site et intégré dans le wrapper, la dll non managée supporte la CLR (mais aucune modification de code n’a été effectuée).
Le wrapper supporte la CLR oldsyntaxe. Les deux assembly sont ajoutées aux références du site web et sont placées sous le répertoire bin du site.
Sur le PC de développement, tout se déroule correctement. Sur le Serveur, le message suivant apparaît:
Le module spécifié est introuvable. (Exception de HRESULT : 0x8007007E) Description : Une exception non gérée s'est produite au moment de l'exécution de la demande Web actuelle. Contrôlez la trace de la pile pour plus d'informations sur l'erreur et son origine dans le code.
Détails de l'exception: System.IO.FileNotFoundException: Le module spécifié est introuvable. (Exception de HRESULT : 0x8007007E)
Erreur source:
Une exception non gérée s'est produite lors de l'exécution de la demande Web actuelle. Les informations relatives à l'origine et l'emplacement de l'exception peuvent être identifiées en utilisant la trace de la pile d'exception ci-dessous.
Informations sur la version : Version Microsoft .NET Framework :2.0.50727.832; Version ASP.NET :2.0.50727.832
Les mêmes assembly appelées par une application WinForms fonctionnent en étant sous le répertoire courant de l‘application.
Le déplacement de la dll non managée et du wrapper sous WindowsSystem32 résout le problème mais n’est évidemment pas une solution envisageable.
Il ne s’agit pas d’un problème de sécurité, les droits trust level sont à Full sous web.config.
Des recherches sur Internet nous ont amené à tenter les résolutions suivantes :
- Nommage fort de la dll C++ non managée (snk + version + langue). Ajout de la clé dans le fichier web_mediumtrust.config et passage du trust level à Medium dans web.config. -> aucun résultat. - Ajout de l’assembly C++ non managée dans le GAC. -> aucun résultat. - Nommage fort de la dll C++ non managée et du wrapper (snk + version + langue). Ajout de la clé dans le fichier web_mediumtrust.config et passage du trust level à Medium dans web.config. -> aucun résultat. - Ajout de la dll C++ non managée et du wrapper dans le GAC. -> aucun résultat.
Est-ce que quelqu'un aurait une solution à ce problème ? Merci d'avance pour votre aide.
Tugrul Ebabil
Bonjour,
Etes-vous sûr que toutes les DLL que votre application ai besoin se trouvent dans le répertoire bin de votre site ?
Cordialement
-- Gilles TOURREAU - MVP C#
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
"Tugrul Ebabil" <TugrulEbabil@discussions.microsoft.com> a écrit dans le
message de news:E41D02CE-9061-4739-BA21-4A2ABDB2915C@microsoft.com...
Bonjour,
nous essayons d'utiliser une assembly non managée au sein d'une
application
ASP.NET mais nous n'y arrivons pas. Voici la description du problème :
Contexte logiciel :
Serveur : Windows Server 2003.
IIS 6.0
AspNet 2.0.50727
Redistribuable Visual Studio 2005 installé.
Site et assembly compilés avec Visual Studio 2005.
Framework 2.0.50727.
Enoncé du problème :
Lors de l’exécution d’un site ASP.NET, on fait appel à du code non managé
écrit en C++. Afin de réaliser ceci, un wrapper C++ managé est utilisé
pour
permettre l’appel depuis une page du site. Pour pouvoir être publié avec
le
site et intégré dans le wrapper, la dll non managée supporte la CLR (mais
aucune modification de code n’a été effectuée).
Le wrapper supporte la CLR oldsyntaxe. Les deux assembly sont ajoutées aux
références du site web et sont placées sous le répertoire bin du site.
Sur le PC de développement, tout se déroule correctement.
Sur le Serveur, le message suivant apparaît:
Le module spécifié est introuvable. (Exception de HRESULT :
0x8007007E)
Description : Une exception non gérée s'est produite au moment de
l'exécution de la demande Web actuelle. Contrôlez la trace de la pile pour
plus d'informations sur l'erreur et son origine dans le code.
Détails de l'exception: System.IO.FileNotFoundException: Le module
spécifié
est introuvable. (Exception de HRESULT : 0x8007007E)
Erreur source:
Une exception non gérée s'est produite lors de l'exécution de la demande
Web
actuelle. Les informations relatives à l'origine et l'emplacement de
l'exception peuvent être identifiées en utilisant la trace de la pile
d'exception ci-dessous.
Informations sur la version : Version Microsoft .NET Framework
:2.0.50727.832; Version ASP.NET :2.0.50727.832
Les mêmes assembly appelées par une application WinForms fonctionnent en
étant sous le répertoire courant de l‘application.
Le déplacement de la dll non managée et du wrapper sous WindowsSystem32
résout le problème mais n’est évidemment pas une solution envisageable.
Il ne s’agit pas d’un problème de sécurité, les droits trust level sont à
Full sous web.config.
Des recherches sur Internet nous ont amené à tenter les résolutions
suivantes :
- Nommage fort de la dll C++ non managée (snk + version + langue). Ajout
de
la clé dans le fichier web_mediumtrust.config et passage du trust level à
Medium dans web.config. -> aucun résultat.
- Ajout de l’assembly C++ non managée dans le GAC. -> aucun résultat.
- Nommage fort de la dll C++ non managée et du wrapper (snk + version +
langue). Ajout de la clé dans le fichier web_mediumtrust.config et passage
du
trust level à Medium dans web.config. -> aucun résultat.
- Ajout de la dll C++ non managée et du wrapper dans le GAC. -> aucun
résultat.
Est-ce que quelqu'un aurait une solution à ce problème ? Merci d'avance
pour
votre aide.
Tugrul Ebabil
Bonjour,
Etes-vous sûr que toutes les DLL que votre application ai besoin se trouvent
dans le répertoire bin de votre site ?
nous essayons d'utiliser une assembly non managée au sein d'une application ASP.NET mais nous n'y arrivons pas. Voici la description du problème :
Contexte logiciel :
Serveur : Windows Server 2003. IIS 6.0 AspNet 2.0.50727 Redistribuable Visual Studio 2005 installé. Site et assembly compilés avec Visual Studio 2005. Framework 2.0.50727.
Enoncé du problème :
Lors de l’exécution d’un site ASP.NET, on fait appel à du code non managé écrit en C++. Afin de réaliser ceci, un wrapper C++ managé est utilisé pour permettre l’appel depuis une page du site. Pour pouvoir être publié avec le site et intégré dans le wrapper, la dll non managée supporte la CLR (mais aucune modification de code n’a été effectuée).
Le wrapper supporte la CLR oldsyntaxe. Les deux assembly sont ajoutées aux références du site web et sont placées sous le répertoire bin du site.
Sur le PC de développement, tout se déroule correctement. Sur le Serveur, le message suivant apparaît:
Le module spécifié est introuvable. (Exception de HRESULT : 0x8007007E) Description : Une exception non gérée s'est produite au moment de l'exécution de la demande Web actuelle. Contrôlez la trace de la pile pour plus d'informations sur l'erreur et son origine dans le code.
Détails de l'exception: System.IO.FileNotFoundException: Le module spécifié est introuvable. (Exception de HRESULT : 0x8007007E)
Erreur source:
Une exception non gérée s'est produite lors de l'exécution de la demande Web actuelle. Les informations relatives à l'origine et l'emplacement de l'exception peuvent être identifiées en utilisant la trace de la pile d'exception ci-dessous.
Informations sur la version : Version Microsoft .NET Framework :2.0.50727.832; Version ASP.NET :2.0.50727.832
Les mêmes assembly appelées par une application WinForms fonctionnent en étant sous le répertoire courant de l‘application.
Le déplacement de la dll non managée et du wrapper sous WindowsSystem32 résout le problème mais n’est évidemment pas une solution envisageable.
Il ne s’agit pas d’un problème de sécurité, les droits trust level sont à Full sous web.config.
Des recherches sur Internet nous ont amené à tenter les résolutions suivantes :
- Nommage fort de la dll C++ non managée (snk + version + langue). Ajout de la clé dans le fichier web_mediumtrust.config et passage du trust level à Medium dans web.config. -> aucun résultat. - Ajout de l’assembly C++ non managée dans le GAC. -> aucun résultat. - Nommage fort de la dll C++ non managée et du wrapper (snk + version + langue). Ajout de la clé dans le fichier web_mediumtrust.config et passage du trust level à Medium dans web.config. -> aucun résultat. - Ajout de la dll C++ non managée et du wrapper dans le GAC. -> aucun résultat.
Est-ce que quelqu'un aurait une solution à ce problème ? Merci d'avance pour votre aide.
Tugrul Ebabil
Bonjour,
Etes-vous sûr que toutes les DLL que votre application ai besoin se trouvent dans le répertoire bin de votre site ?
Cordialement
-- Gilles TOURREAU - MVP C#
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Tugrul Ebabil
Bonjour,
toutes les DLL managées, les wrappers et les DLL non managées nécessaires à l'application ASP.NET se trouvent dans le répertoire bin du site.
Comme je l'ai écrit, en déplaçant les wrappers et les DLL non managées dans le répertoire System32 de Windows, ça marche.
Pour être sûr qu'il ne s'agissait pas d'un problème de dépendance manquante, nous avons copié le contenu du répertoire System32 de Windows dans le répertoire bin du site. Ceci n'a donné aucun résultat.
Il semblerait donc que les DLL non managées ne soient recherchées que dans le répertoire System32.
Vu ce comportement, je me pose la question suivante : peut-on utiliser des DLLs non managées dans une application ASP.NET ?
Cordialement,
Tugrul Ebabil
"Gilles TOURREAU [MVP]" a écrit :
"Tugrul Ebabil" a écrit dans le message de news: > Bonjour, > > nous essayons d'utiliser une assembly non managée au sein d'une > application > ASP.NET mais nous n'y arrivons pas. Voici la description du problème : > > Contexte logiciel : > > Serveur : Windows Server 2003. > IIS 6.0 > AspNet 2.0.50727 > Redistribuable Visual Studio 2005 installé. > Site et assembly compilés avec Visual Studio 2005. > Framework 2.0.50727. > > Enoncé du problème : > > Lors de l’exécution d’un site ASP.NET, on fait appel à du code non managé > écrit en C++. Afin de réaliser ceci, un wrapper C++ managé est utilisé > pour > permettre l’appel depuis une page du site. Pour pouvoir être publié avec > le > site et intégré dans le wrapper, la dll non managée supporte la CLR (mais > aucune modification de code n’a été effectuée). > > Le wrapper supporte la CLR oldsyntaxe. Les deux assembly sont ajoutées aux > références du site web et sont placées sous le répertoire bin du site. > > Sur le PC de développement, tout se déroule correctement. > Sur le Serveur, le message suivant apparaît: > > Le module spécifié est introuvable. (Exception de HRESULT : > 0x8007007E) > Description : Une exception non gérée s'est produite au moment de > l'exécution de la demande Web actuelle. Contrôlez la trace de la pile pour > plus d'informations sur l'erreur et son origine dans le code. > > Détails de l'exception: System.IO.FileNotFoundException: Le module > spécifié > est introuvable. (Exception de HRESULT : 0x8007007E) > > Erreur source: > > Une exception non gérée s'est produite lors de l'exécution de la demande > Web > actuelle. Les informations relatives à l'origine et l'emplacement de > l'exception peuvent être identifiées en utilisant la trace de la pile > d'exception ci-dessous. > > Trace de la pile: > -------------------------------------------------------------------------------- > [FileNotFoundException: Le module spécifié est introuvable. (Exception de > HRESULT : 0x8007007E)] > System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, > Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& > stackMark, > Boolean throwOnFileNotFound, Boolean forIntrospection) +0 > System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, > Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean > forIntrospection) +211 > System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence > assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) > +141 > System.Reflection.Assembly.Load(String assemblyString) +25 > System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String > assemblyName, Boolean starDirective) +32 > > [ConfigurationErrorsException: Le module spécifié est introuvable. > (Exception de HRESULT : 0x8007007E)] > > System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String > assemblyName, Boolean starDirective) +596 > System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory() > +3596761 > System.Web.Configuration.CompilationSection.LoadAssembly(AssemblyInfo > ai) > +46 > > System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection > compConfig) +177 > System.Web.Compilation.WebDirectoryBatchCompiler..ctor(VirtualDirectory > vdir) +267 > > System.Web.Compilation.BuildManager.BatchCompileWebDirectoryInternal(VirtualDirectory > vdir, Boolean ignoreErrors) +36 > > System.Web.Compilation.BuildManager.BatchCompileWebDirectory(VirtualDirectory > vdir, VirtualPath virtualDir, Boolean ignoreErrors) +429 > System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath > virtualPath) +73 > > System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath > virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean > allowBuildInPrecompile) +580 > > System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext > context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, > Boolean allowBuildInPrecompile) +93 > > System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath > virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert) > +111 > > System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath > virtualPath, Type requiredBaseType, HttpContext context, Boolean > allowCrossApp, Boolean noAssert) +54 > System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, > String requestType, VirtualPath virtualPath, String physicalPath) +31 > > System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext > context, String requestType, VirtualPath virtualPath, String physicalPath) > +40 > System.Web.HttpApplication.MapHttpHandler(HttpContext context, String > requestType, VirtualPath path, String pathTranslated, Boolean > useAppConfig) > +139 > > System.Web.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() > +120 > System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& > completedSynchronously) +155 > -------------------------------------------------------------------------------- > > Informations sur la version : Version Microsoft .NET Framework > :2.0.50727.832; Version ASP.NET :2.0.50727.832 > > > Les mêmes assembly appelées par une application WinForms fonctionnent en > étant sous le répertoire courant de l‘application. > > Le déplacement de la dll non managée et du wrapper sous WindowsSystem32 > résout le problème mais n’est évidemment pas une solution envisageable. > > Il ne s’agit pas d’un problème de sécurité, les droits trust level sont à > Full sous web.config. > > Des recherches sur Internet nous ont amené à tenter les résolutions > suivantes : > > - Nommage fort de la dll C++ non managée (snk + version + langue). Ajout > de > la clé dans le fichier web_mediumtrust.config et passage du trust level à > Medium dans web.config. -> aucun résultat. > - Ajout de l’assembly C++ non managée dans le GAC. -> aucun résultat. > - Nommage fort de la dll C++ non managée et du wrapper (snk + version + > langue). Ajout de la clé dans le fichier web_mediumtrust.config et passage > du > trust level à Medium dans web.config. -> aucun résultat. > - Ajout de la dll C++ non managée et du wrapper dans le GAC. -> aucun > résultat. > > Est-ce que quelqu'un aurait une solution à ce problème ? Merci d'avance > pour > votre aide. > > Tugrul Ebabil >
Bonjour,
Etes-vous sûr que toutes les DLL que votre application ai besoin se trouvent dans le répertoire bin de votre site ?
Cordialement
-- Gilles TOURREAU - MVP C#
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Bonjour,
toutes les DLL managées, les wrappers et les DLL non managées nécessaires à
l'application ASP.NET se trouvent dans le répertoire bin du site.
Comme je l'ai écrit, en déplaçant les wrappers et les DLL non managées dans
le répertoire System32 de Windows, ça marche.
Pour être sûr qu'il ne s'agissait pas d'un problème de dépendance manquante,
nous avons copié le contenu du répertoire System32 de Windows dans le
répertoire bin du site. Ceci n'a donné aucun résultat.
Il semblerait donc que les DLL non managées ne soient recherchées que dans
le répertoire System32.
Vu ce comportement, je me pose la question suivante : peut-on utiliser des
DLLs non managées dans une application ASP.NET ?
Cordialement,
Tugrul Ebabil
"Gilles TOURREAU [MVP]" a écrit :
"Tugrul Ebabil" <TugrulEbabil@discussions.microsoft.com> a écrit dans le
message de news:E41D02CE-9061-4739-BA21-4A2ABDB2915C@microsoft.com...
> Bonjour,
>
> nous essayons d'utiliser une assembly non managée au sein d'une
> application
> ASP.NET mais nous n'y arrivons pas. Voici la description du problème :
>
> Contexte logiciel :
>
> Serveur : Windows Server 2003.
> IIS 6.0
> AspNet 2.0.50727
> Redistribuable Visual Studio 2005 installé.
> Site et assembly compilés avec Visual Studio 2005.
> Framework 2.0.50727.
>
> Enoncé du problème :
>
> Lors de l’exécution d’un site ASP.NET, on fait appel à du code non managé
> écrit en C++. Afin de réaliser ceci, un wrapper C++ managé est utilisé
> pour
> permettre l’appel depuis une page du site. Pour pouvoir être publié avec
> le
> site et intégré dans le wrapper, la dll non managée supporte la CLR (mais
> aucune modification de code n’a été effectuée).
>
> Le wrapper supporte la CLR oldsyntaxe. Les deux assembly sont ajoutées aux
> références du site web et sont placées sous le répertoire bin du site.
>
> Sur le PC de développement, tout se déroule correctement.
> Sur le Serveur, le message suivant apparaît:
>
> Le module spécifié est introuvable. (Exception de HRESULT :
> 0x8007007E)
> Description : Une exception non gérée s'est produite au moment de
> l'exécution de la demande Web actuelle. Contrôlez la trace de la pile pour
> plus d'informations sur l'erreur et son origine dans le code.
>
> Détails de l'exception: System.IO.FileNotFoundException: Le module
> spécifié
> est introuvable. (Exception de HRESULT : 0x8007007E)
>
> Erreur source:
>
> Une exception non gérée s'est produite lors de l'exécution de la demande
> Web
> actuelle. Les informations relatives à l'origine et l'emplacement de
> l'exception peuvent être identifiées en utilisant la trace de la pile
> d'exception ci-dessous.
>
> Trace de la pile:
> --------------------------------------------------------------------------------
> [FileNotFoundException: Le module spécifié est introuvable. (Exception de
> HRESULT : 0x8007007E)]
> System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase,
> Evidence assemblySecurity, Assembly locationHint, StackCrawlMark&
> stackMark,
> Boolean throwOnFileNotFound, Boolean forIntrospection) +0
> System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef,
> Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean
> forIntrospection) +211
> System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence
> assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
> +141
> System.Reflection.Assembly.Load(String assemblyString) +25
> System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String
> assemblyName, Boolean starDirective) +32
>
> [ConfigurationErrorsException: Le module spécifié est introuvable.
> (Exception de HRESULT : 0x8007007E)]
>
> System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String
> assemblyName, Boolean starDirective) +596
> System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory()
> +3596761
> System.Web.Configuration.CompilationSection.LoadAssembly(AssemblyInfo
> ai)
> +46
>
> System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection
> compConfig) +177
> System.Web.Compilation.WebDirectoryBatchCompiler..ctor(VirtualDirectory
> vdir) +267
>
> System.Web.Compilation.BuildManager.BatchCompileWebDirectoryInternal(VirtualDirectory
> vdir, Boolean ignoreErrors) +36
>
> System.Web.Compilation.BuildManager.BatchCompileWebDirectory(VirtualDirectory
> vdir, VirtualPath virtualDir, Boolean ignoreErrors) +429
> System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath
> virtualPath) +73
>
> System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath
> virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean
> allowBuildInPrecompile) +580
>
> System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext
> context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp,
> Boolean allowBuildInPrecompile) +93
>
> System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath
> virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert)
> +111
>
> System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath
> virtualPath, Type requiredBaseType, HttpContext context, Boolean
> allowCrossApp, Boolean noAssert) +54
> System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context,
> String requestType, VirtualPath virtualPath, String physicalPath) +31
>
> System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext
> context, String requestType, VirtualPath virtualPath, String physicalPath)
> +40
> System.Web.HttpApplication.MapHttpHandler(HttpContext context, String
> requestType, VirtualPath path, String pathTranslated, Boolean
> useAppConfig)
> +139
>
> System.Web.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
> +120
> System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean&
> completedSynchronously) +155
> --------------------------------------------------------------------------------
>
> Informations sur la version : Version Microsoft .NET Framework
> :2.0.50727.832; Version ASP.NET :2.0.50727.832
>
>
> Les mêmes assembly appelées par une application WinForms fonctionnent en
> étant sous le répertoire courant de l‘application.
>
> Le déplacement de la dll non managée et du wrapper sous WindowsSystem32
> résout le problème mais n’est évidemment pas une solution envisageable.
>
> Il ne s’agit pas d’un problème de sécurité, les droits trust level sont à
> Full sous web.config.
>
> Des recherches sur Internet nous ont amené à tenter les résolutions
> suivantes :
>
> - Nommage fort de la dll C++ non managée (snk + version + langue). Ajout
> de
> la clé dans le fichier web_mediumtrust.config et passage du trust level à
> Medium dans web.config. -> aucun résultat.
> - Ajout de l’assembly C++ non managée dans le GAC. -> aucun résultat.
> - Nommage fort de la dll C++ non managée et du wrapper (snk + version +
> langue). Ajout de la clé dans le fichier web_mediumtrust.config et passage
> du
> trust level à Medium dans web.config. -> aucun résultat.
> - Ajout de la dll C++ non managée et du wrapper dans le GAC. -> aucun
> résultat.
>
> Est-ce que quelqu'un aurait une solution à ce problème ? Merci d'avance
> pour
> votre aide.
>
> Tugrul Ebabil
>
Bonjour,
Etes-vous sûr que toutes les DLL que votre application ai besoin se trouvent
dans le répertoire bin de votre site ?
toutes les DLL managées, les wrappers et les DLL non managées nécessaires à l'application ASP.NET se trouvent dans le répertoire bin du site.
Comme je l'ai écrit, en déplaçant les wrappers et les DLL non managées dans le répertoire System32 de Windows, ça marche.
Pour être sûr qu'il ne s'agissait pas d'un problème de dépendance manquante, nous avons copié le contenu du répertoire System32 de Windows dans le répertoire bin du site. Ceci n'a donné aucun résultat.
Il semblerait donc que les DLL non managées ne soient recherchées que dans le répertoire System32.
Vu ce comportement, je me pose la question suivante : peut-on utiliser des DLLs non managées dans une application ASP.NET ?
Cordialement,
Tugrul Ebabil
"Gilles TOURREAU [MVP]" a écrit :
"Tugrul Ebabil" a écrit dans le message de news: > Bonjour, > > nous essayons d'utiliser une assembly non managée au sein d'une > application > ASP.NET mais nous n'y arrivons pas. Voici la description du problème : > > Contexte logiciel : > > Serveur : Windows Server 2003. > IIS 6.0 > AspNet 2.0.50727 > Redistribuable Visual Studio 2005 installé. > Site et assembly compilés avec Visual Studio 2005. > Framework 2.0.50727. > > Enoncé du problème : > > Lors de l’exécution d’un site ASP.NET, on fait appel à du code non managé > écrit en C++. Afin de réaliser ceci, un wrapper C++ managé est utilisé > pour > permettre l’appel depuis une page du site. Pour pouvoir être publié avec > le > site et intégré dans le wrapper, la dll non managée supporte la CLR (mais > aucune modification de code n’a été effectuée). > > Le wrapper supporte la CLR oldsyntaxe. Les deux assembly sont ajoutées aux > références du site web et sont placées sous le répertoire bin du site. > > Sur le PC de développement, tout se déroule correctement. > Sur le Serveur, le message suivant apparaît: > > Le module spécifié est introuvable. (Exception de HRESULT : > 0x8007007E) > Description : Une exception non gérée s'est produite au moment de > l'exécution de la demande Web actuelle. Contrôlez la trace de la pile pour > plus d'informations sur l'erreur et son origine dans le code. > > Détails de l'exception: System.IO.FileNotFoundException: Le module > spécifié > est introuvable. (Exception de HRESULT : 0x8007007E) > > Erreur source: > > Une exception non gérée s'est produite lors de l'exécution de la demande > Web > actuelle. Les informations relatives à l'origine et l'emplacement de > l'exception peuvent être identifiées en utilisant la trace de la pile > d'exception ci-dessous. > > Trace de la pile: > -------------------------------------------------------------------------------- > [FileNotFoundException: Le module spécifié est introuvable. (Exception de > HRESULT : 0x8007007E)] > System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, > Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& > stackMark, > Boolean throwOnFileNotFound, Boolean forIntrospection) +0 > System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, > Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean > forIntrospection) +211 > System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence > assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) > +141 > System.Reflection.Assembly.Load(String assemblyString) +25 > System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String > assemblyName, Boolean starDirective) +32 > > [ConfigurationErrorsException: Le module spécifié est introuvable. > (Exception de HRESULT : 0x8007007E)] > > System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String > assemblyName, Boolean starDirective) +596 > System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory() > +3596761 > System.Web.Configuration.CompilationSection.LoadAssembly(AssemblyInfo > ai) > +46 > > System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection > compConfig) +177 > System.Web.Compilation.WebDirectoryBatchCompiler..ctor(VirtualDirectory > vdir) +267 > > System.Web.Compilation.BuildManager.BatchCompileWebDirectoryInternal(VirtualDirectory > vdir, Boolean ignoreErrors) +36 > > System.Web.Compilation.BuildManager.BatchCompileWebDirectory(VirtualDirectory > vdir, VirtualPath virtualDir, Boolean ignoreErrors) +429 > System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath > virtualPath) +73 > > System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath > virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean > allowBuildInPrecompile) +580 > > System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext > context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, > Boolean allowBuildInPrecompile) +93 > > System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath > virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert) > +111 > > System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath > virtualPath, Type requiredBaseType, HttpContext context, Boolean > allowCrossApp, Boolean noAssert) +54 > System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, > String requestType, VirtualPath virtualPath, String physicalPath) +31 > > System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext > context, String requestType, VirtualPath virtualPath, String physicalPath) > +40 > System.Web.HttpApplication.MapHttpHandler(HttpContext context, String > requestType, VirtualPath path, String pathTranslated, Boolean > useAppConfig) > +139 > > System.Web.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() > +120 > System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& > completedSynchronously) +155 > -------------------------------------------------------------------------------- > > Informations sur la version : Version Microsoft .NET Framework > :2.0.50727.832; Version ASP.NET :2.0.50727.832 > > > Les mêmes assembly appelées par une application WinForms fonctionnent en > étant sous le répertoire courant de l‘application. > > Le déplacement de la dll non managée et du wrapper sous WindowsSystem32 > résout le problème mais n’est évidemment pas une solution envisageable. > > Il ne s’agit pas d’un problème de sécurité, les droits trust level sont à > Full sous web.config. > > Des recherches sur Internet nous ont amené à tenter les résolutions > suivantes : > > - Nommage fort de la dll C++ non managée (snk + version + langue). Ajout > de > la clé dans le fichier web_mediumtrust.config et passage du trust level à > Medium dans web.config. -> aucun résultat. > - Ajout de l’assembly C++ non managée dans le GAC. -> aucun résultat. > - Nommage fort de la dll C++ non managée et du wrapper (snk + version + > langue). Ajout de la clé dans le fichier web_mediumtrust.config et passage > du > trust level à Medium dans web.config. -> aucun résultat. > - Ajout de la dll C++ non managée et du wrapper dans le GAC. -> aucun > résultat. > > Est-ce que quelqu'un aurait une solution à ce problème ? Merci d'avance > pour > votre aide. > > Tugrul Ebabil >
Bonjour,
Etes-vous sûr que toutes les DLL que votre application ai besoin se trouvent dans le répertoire bin de votre site ?
Cordialement
-- Gilles TOURREAU - MVP C#
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Patrice
Bonjour, le problème est lié au chemin de recherche des DLLs non managées : http://msdn2.microsoft.com/en-us/library/7d83bc18(VS.80).aspx (par exemple essayer en modifiant la variable d'environnement ? ou en modifiant le wrapper pour qu'il charge explicitement la DLL ?)
Egalement la notion de dossier courant pour une application ASP.NET n'a pas vraiment lieu d'être (je crois que c'est également le dossier system32).
-- Patrice
Bonjour, le problème est lié au chemin de recherche des DLLs non managées :
http://msdn2.microsoft.com/en-us/library/7d83bc18(VS.80).aspx (par exemple
essayer en modifiant la variable d'environnement ? ou en modifiant le
wrapper pour qu'il charge explicitement la DLL ?)
Egalement la notion de dossier courant pour une application ASP.NET n'a pas
vraiment lieu d'être (je crois que c'est également le dossier system32).
Bonjour, le problème est lié au chemin de recherche des DLLs non managées : http://msdn2.microsoft.com/en-us/library/7d83bc18(VS.80).aspx (par exemple essayer en modifiant la variable d'environnement ? ou en modifiant le wrapper pour qu'il charge explicitement la DLL ?)
Egalement la notion de dossier courant pour une application ASP.NET n'a pas vraiment lieu d'être (je crois que c'est également le dossier system32).
-- Patrice
Tugrul Ebabil
Bonjour,
je ne l'avais pas écrit mais nous avons également essayé d'ajouter le répertoire bin du site dans la variable d'environnement PATH, ça n'a pas marché non plus.
Nous avons aussi essayé de charger dynamiquement les DLL non managées dans les wrapper en utilisant les chemins complets, ça n'a pas marché non plus.
Si j'ai bien compris le fonctionnement des applications ASP.NET, les DLL qui sont dans le répertoire bin du site sont recopiées dans un répertoire temporaire (documents and settings...). L'exécution se fait dans ce répertoire temporaire. On voit bien que lors de la copie, les DLL non managées ne sont pas recopiées dans le répertoire temporaire. Ce qui ne se trouve pas dans ce répertoire est cherché dans System32. Il semblerait que la variable d'environnement PATH ne soit absolument pas utilisée. Si nous copions les DLL non managées dans le répertoire temporaire, ça marche.
Cordialement,
Tugrul Ebabil
"Patrice" a écrit :
Bonjour, le problème est lié au chemin de recherche des DLLs non managées : http://msdn2.microsoft.com/en-us/library/7d83bc18(VS.80).aspx (par exemple essayer en modifiant la variable d'environnement ? ou en modifiant le wrapper pour qu'il charge explicitement la DLL ?)
Egalement la notion de dossier courant pour une application ASP.NET n'a pas vraiment lieu d'être (je crois que c'est également le dossier system32).
-- Patrice
Bonjour,
je ne l'avais pas écrit mais nous avons également essayé d'ajouter le
répertoire bin du site dans la variable d'environnement PATH, ça n'a pas
marché non plus.
Nous avons aussi essayé de charger dynamiquement les DLL non managées dans
les wrapper en utilisant les chemins complets, ça n'a pas marché non plus.
Si j'ai bien compris le fonctionnement des applications ASP.NET, les DLL qui
sont dans le répertoire bin du site sont recopiées dans un répertoire
temporaire (documents and settings...). L'exécution se fait dans ce
répertoire temporaire.
On voit bien que lors de la copie, les DLL non managées ne sont pas
recopiées dans le répertoire temporaire. Ce qui ne se trouve pas dans ce
répertoire est cherché dans System32. Il semblerait que la variable
d'environnement PATH ne soit absolument pas utilisée. Si nous copions les DLL
non managées dans le répertoire temporaire, ça marche.
Cordialement,
Tugrul Ebabil
"Patrice" a écrit :
Bonjour, le problème est lié au chemin de recherche des DLLs non managées :
http://msdn2.microsoft.com/en-us/library/7d83bc18(VS.80).aspx (par exemple
essayer en modifiant la variable d'environnement ? ou en modifiant le
wrapper pour qu'il charge explicitement la DLL ?)
Egalement la notion de dossier courant pour une application ASP.NET n'a pas
vraiment lieu d'être (je crois que c'est également le dossier system32).
je ne l'avais pas écrit mais nous avons également essayé d'ajouter le répertoire bin du site dans la variable d'environnement PATH, ça n'a pas marché non plus.
Nous avons aussi essayé de charger dynamiquement les DLL non managées dans les wrapper en utilisant les chemins complets, ça n'a pas marché non plus.
Si j'ai bien compris le fonctionnement des applications ASP.NET, les DLL qui sont dans le répertoire bin du site sont recopiées dans un répertoire temporaire (documents and settings...). L'exécution se fait dans ce répertoire temporaire. On voit bien que lors de la copie, les DLL non managées ne sont pas recopiées dans le répertoire temporaire. Ce qui ne se trouve pas dans ce répertoire est cherché dans System32. Il semblerait que la variable d'environnement PATH ne soit absolument pas utilisée. Si nous copions les DLL non managées dans le répertoire temporaire, ça marche.
Cordialement,
Tugrul Ebabil
"Patrice" a écrit :
Bonjour, le problème est lié au chemin de recherche des DLLs non managées : http://msdn2.microsoft.com/en-us/library/7d83bc18(VS.80).aspx (par exemple essayer en modifiant la variable d'environnement ? ou en modifiant le wrapper pour qu'il charge explicitement la DLL ?)
Egalement la notion de dossier courant pour une application ASP.NET n'a pas vraiment lieu d'être (je crois que c'est également le dossier system32).
-- Patrice
Delf
Tugrul Ebabil a formulé ce jeudi :
Il semblerait donc que les DLL non managées ne soient recherchées que dans le répertoire System32.
Vu ce comportement, je me pose la question suivante : peut-on utiliser des DLLs non managées dans une application ASP.NET ?
Je vais essayé de répondre : oui on peut utiliser des DLL non managées en ASP.NET, quelque soit leurs localisations sur le poste.
J'avais du pour un prjet utiliser des DLL C++/Win32 dont leurs localisations étaient définies dans la Registry (et autre qu'un répertoire system).
De mémoire j'avais utilisé un mécanisme pour construire dynamiquement une assembly .NET qui chargeait la DLL Win32 en passant le Path...
Si c'est important je peux chercher les sources si je les ai encore, mais c'était vraiment usine à gaz... et c'était ma 1° tâche en .NET, quand j'ai découvert cet environement... :
-- Delf
Tugrul Ebabil a formulé ce jeudi :
Il semblerait donc que les DLL non managées ne soient recherchées que dans
le répertoire System32.
Vu ce comportement, je me pose la question suivante : peut-on utiliser des
DLLs non managées dans une application ASP.NET ?
Je vais essayé de répondre : oui on peut utiliser des DLL non managées
en ASP.NET, quelque soit leurs localisations sur le poste.
J'avais du pour un prjet utiliser des DLL C++/Win32 dont leurs
localisations étaient définies dans la Registry (et autre qu'un
répertoire system).
De mémoire j'avais utilisé un mécanisme pour construire dynamiquement
une assembly .NET qui chargeait la DLL Win32 en passant le Path...
Si c'est important je peux chercher les sources si je les ai encore,
mais c'était vraiment usine à gaz... et c'était ma 1° tâche en .NET,
quand j'ai découvert cet environement... :
Il semblerait donc que les DLL non managées ne soient recherchées que dans le répertoire System32.
Vu ce comportement, je me pose la question suivante : peut-on utiliser des DLLs non managées dans une application ASP.NET ?
Je vais essayé de répondre : oui on peut utiliser des DLL non managées en ASP.NET, quelque soit leurs localisations sur le poste.
J'avais du pour un prjet utiliser des DLL C++/Win32 dont leurs localisations étaient définies dans la Registry (et autre qu'un répertoire system).
De mémoire j'avais utilisé un mécanisme pour construire dynamiquement une assembly .NET qui chargeait la DLL Win32 en passant le Path...
Si c'est important je peux chercher les sources si je les ai encore, mais c'était vraiment usine à gaz... et c'était ma 1° tâche en .NET, quand j'ai découvert cet environement... :
-- Delf
Tugrul Ebabil
Bonjour,
merci pour votre réponse. Je suis intéressé par votre solution si vous avez encore les sources.
Cordialement,
Tugrul Ebabil
"Delf" a écrit :
Tugrul Ebabil a formulé ce jeudi :
> Il semblerait donc que les DLL non managées ne soient recherchées que dans > le répertoire System32. > > Vu ce comportement, je me pose la question suivante : peut-on utiliser des > DLLs non managées dans une application ASP.NET ?
Je vais essayé de répondre : oui on peut utiliser des DLL non managées en ASP.NET, quelque soit leurs localisations sur le poste.
J'avais du pour un prjet utiliser des DLL C++/Win32 dont leurs localisations étaient définies dans la Registry (et autre qu'un répertoire system).
De mémoire j'avais utilisé un mécanisme pour construire dynamiquement une assembly .NET qui chargeait la DLL Win32 en passant le Path...
Si c'est important je peux chercher les sources si je les ai encore, mais c'était vraiment usine à gaz... et c'était ma 1° tâche en .NET, quand j'ai découvert cet environement... :
-- Delf
Bonjour,
merci pour votre réponse. Je suis intéressé par votre solution si vous avez
encore les sources.
Cordialement,
Tugrul Ebabil
"Delf" a écrit :
Tugrul Ebabil a formulé ce jeudi :
> Il semblerait donc que les DLL non managées ne soient recherchées que dans
> le répertoire System32.
>
> Vu ce comportement, je me pose la question suivante : peut-on utiliser des
> DLLs non managées dans une application ASP.NET ?
Je vais essayé de répondre : oui on peut utiliser des DLL non managées
en ASP.NET, quelque soit leurs localisations sur le poste.
J'avais du pour un prjet utiliser des DLL C++/Win32 dont leurs
localisations étaient définies dans la Registry (et autre qu'un
répertoire system).
De mémoire j'avais utilisé un mécanisme pour construire dynamiquement
une assembly .NET qui chargeait la DLL Win32 en passant le Path...
Si c'est important je peux chercher les sources si je les ai encore,
mais c'était vraiment usine à gaz... et c'était ma 1° tâche en .NET,
quand j'ai découvert cet environement... :
merci pour votre réponse. Je suis intéressé par votre solution si vous avez encore les sources.
Cordialement,
Tugrul Ebabil
"Delf" a écrit :
Tugrul Ebabil a formulé ce jeudi :
> Il semblerait donc que les DLL non managées ne soient recherchées que dans > le répertoire System32. > > Vu ce comportement, je me pose la question suivante : peut-on utiliser des > DLLs non managées dans une application ASP.NET ?
Je vais essayé de répondre : oui on peut utiliser des DLL non managées en ASP.NET, quelque soit leurs localisations sur le poste.
J'avais du pour un prjet utiliser des DLL C++/Win32 dont leurs localisations étaient définies dans la Registry (et autre qu'un répertoire system).
De mémoire j'avais utilisé un mécanisme pour construire dynamiquement une assembly .NET qui chargeait la DLL Win32 en passant le Path...
Si c'est important je peux chercher les sources si je les ai encore, mais c'était vraiment usine à gaz... et c'était ma 1° tâche en .NET, quand j'ai découvert cet environement... :
-- Delf
Delf
Tugrul Ebabil vient de nous annoncer :
merci pour votre réponse. Je suis intéressé par votre solution si vous avez encore les sources.
Je regarderai ça Jeudi soir.
-- Delf
Tugrul Ebabil vient de nous annoncer :
merci pour votre réponse. Je suis intéressé par votre solution si vous avez
encore les sources.
merci pour votre réponse. Je suis intéressé par votre solution si vous avez encore les sources.
Je regarderai ça Jeudi soir.
-- Delf
zouhairgnt
Le jeudi 03 Avril 2008 à 21:57 par Delf :
Tugrul Ebabil a formulé ce jeudi :
Il semblerait donc que les DLL non managées ne soient recherchées que dans le répertoire System32. Vu ce comportement, je me pose la question suivante : peut-on utiliser des DLLs non managées dans une application ASP.NET ?
Je vais essayé de répondre : oui on peut utiliser des DLL non managées en ASP.NET, quelque soit leurs localisations sur le poste. J'avais du pour un prjet utiliser des DLL C++/Win32 dont leurs localisations étaient définies dans la Registry (et autre qu'un répertoire system). De mémoire j'avais utilisé un mécanisme pour construire dynamiquement une assembly .NET qui chargeait la DLL Win32 en passant le Path... Si c'est important je peux chercher les sources si je les ai encore, mais c'était vraiment usine à gaz... et c'était ma 1° tâche en .NET, quand j'ai découvert cet environement... : -- Delf
Bonjour Delf Je viens de lire votre réponse, après dix-ans mais j'ai besoin d'aide aujourd'hui. J'ai une application asp.net qui utilise une dll non managé DLL C++/Win32 l'appels au fonctions de la dll marche correctement. Sauf quand deux utilisateurs sont connecté, et quand les deux Users font un appel à des fonctions de la DLL, le programme m'affiche tentative de lecture dans une mémoire endommagée. Comme si la dll est chargé d'une façon globale, Est ce qu'il une possibilité de charger la Dll dans l’environnement de la session. pour éviter ce genre d'erreurs.
Le jeudi 03 Avril 2008 à 21:57 par Delf :
> Tugrul Ebabil a formulé ce jeudi :
>
>> Il semblerait donc que les DLL non managées ne soient
>> recherchées que dans
>> le répertoire System32.
>>
>> Vu ce comportement, je me pose la question suivante : peut-on utiliser des
>> DLLs non managées dans une application ASP.NET ?
>>
>
> Je vais essayé de répondre : oui on peut utiliser des DLL non
> managées
> en ASP.NET, quelque soit leurs localisations sur le poste.
>
> J'avais du pour un prjet utiliser des DLL C++/Win32 dont leurs
> localisations étaient définies dans la Registry (et autre qu'un
> répertoire system).
>
> De mémoire j'avais utilisé un mécanisme pour construire
> dynamiquement
> une assembly .NET qui chargeait la DLL Win32 en passant le Path...
>
> Si c'est important je peux chercher les sources si je les ai encore,
> mais c'était vraiment usine à gaz... et c'était ma 1°
> tâche en .NET,
> quand j'ai découvert cet environement... :
>
> --
> Delf
Bonjour Delf
Je viens de lire votre réponse, après dix-ans mais j'ai besoin d'aide aujourd'hui.
J'ai une application asp.net qui utilise une dll non managé DLL C++/Win32
l'appels au fonctions de la dll marche correctement.
Sauf quand deux utilisateurs sont connecté, et quand les deux Users font un appel à des fonctions de la DLL, le programme m'affiche tentative de lecture dans une mémoire endommagée.
Comme si la dll est chargé d'une façon globale,
Est ce qu'il une possibilité de charger la Dll dans l’environnement de la session. pour éviter ce genre d'erreurs.
Il semblerait donc que les DLL non managées ne soient recherchées que dans le répertoire System32. Vu ce comportement, je me pose la question suivante : peut-on utiliser des DLLs non managées dans une application ASP.NET ?
Je vais essayé de répondre : oui on peut utiliser des DLL non managées en ASP.NET, quelque soit leurs localisations sur le poste. J'avais du pour un prjet utiliser des DLL C++/Win32 dont leurs localisations étaient définies dans la Registry (et autre qu'un répertoire system). De mémoire j'avais utilisé un mécanisme pour construire dynamiquement une assembly .NET qui chargeait la DLL Win32 en passant le Path... Si c'est important je peux chercher les sources si je les ai encore, mais c'était vraiment usine à gaz... et c'était ma 1° tâche en .NET, quand j'ai découvert cet environement... : -- Delf
Bonjour Delf Je viens de lire votre réponse, après dix-ans mais j'ai besoin d'aide aujourd'hui. J'ai une application asp.net qui utilise une dll non managé DLL C++/Win32 l'appels au fonctions de la dll marche correctement. Sauf quand deux utilisateurs sont connecté, et quand les deux Users font un appel à des fonctions de la DLL, le programme m'affiche tentative de lecture dans une mémoire endommagée. Comme si la dll est chargé d'une façon globale, Est ce qu'il une possibilité de charger la Dll dans l’environnement de la session. pour éviter ce genre d'erreurs.
