Discussion :

[cuber]

Bonjour à tous, je suis face à une incompréhension:
Mon équipe a développé une application ASP.NET (C# framework 2.0) qui utilise une dll externe. Avant d'aller plus loin il faut savoir que cette dll (a.dll) est mise dans le répertoire Windows/System32 sur les postes de développements et sur le serveur de prod. Pour pouvoir utiliser cette dll, nous utilisons une dll "wrappeuse" (wrap.dll) qui fait la liaison de a.dll vers l'application ASP.NET.
Sur les serveurs locals des développeurs (j'entends par là le serveur de Visual Studio 2005) cela fonctionne parfaitement mais lorsque que l'on passe l'application sur le serveur de prod ça marche pas. En fait tout marche tant que l'application n'instancie pas d'objets de a.dll..... On obtient une erreur de type System.Runtime.InteropServices.SEHException (voir là).
J'avoue ne pas bien saisir cette erreur..Une erreur générée par a.dll? Une fuite mémoire?

Il faut savoir que je peux reproduire cette erreur en enlevant a.dll ou/et wrap.dll du répertoire windows/system32 des postes de développement. Mais au vu du essage d'erreur je ne suis pas certains à 100% que l'erreur de base déclanchant l'exception soit la même....

Je suppose une chose pouvant générer l'erreur sur le serveur: le framework n'arrive pas à voir les dll. Or j'ai bien enregistré a.dll via regsrv32 (wrap.dll ne passe pas puisse que c'est un wrapper). Je pencherai donc vers une problème de droits mais le problème c'est que je ne trouve pas....

Il faut savoir que le serveur de prod est sous Win2003 server sp2 , possède une partition C: et une D: et nous devons mettre l'application ASP.NET dans D:/Webs et non dans C:/Inetpub/wwwroot. (Ca peut venir de là aussi non?)

Sinon est-il possible de pré-compiler l'application (c'est à dire on ne déposerait pas les fichiers sources sur le serveur) avec les dll externes?

Je ne vois pas de solutions. Merci d'avoir lu mon message et n'hésitez pas si vous avez une piste, idée ou si ce genre de problème vous ai déjà arrivé.

[SaumonAgile]

Ta DLL a.dll est ce une DLL native ou bien une assembly managée ?
Si c'est une assembly managée, pourquoi ne pas la stocker dans le GAC ?

[cuber]

Je ne suis pas celui qui à créer les dll a.dll et wrap.dll mais j'imagine que la a.dll est native et que wrap.dll est une managée.

Mais je ne suis pas certain de ma définition entre natif/managée.

Sinon si ça peut aider, j'ai remarquer que dans les fichiers temporaires sur le poste développeur, que seul wrap.dll apparait dans le cache du framework dotNet.

De toute façon nous n'avons rien mis dans le GAC sur les postes de développement.

[cuber]

Sur les postes de développements, nous avons fait Projet-> ajouter une référence et nous avons ajouté a.dll et wrap.dll. Ca les a peut etre ajouter dans la GAC?
Mais je ne les vois pas en utilisant l'outils d'administration du framework .Net 2 en affichant les assemblys enregistré bizarre