none
Impossible de charger le type app._Default ou autre RRS feed

  • Question

  • Bonjour

    Depuis la semaine derniere je suis confronté à un probléme de déploiement sur toutes mes applications ASP.Net que ce soit sous VS2005 ou VS2008. Mes environnements de devellopements son sous Vista mais j'ai aussi tester sous XP (mon vieux portable) et le probléme est le méme.

    En effet, tous fonctionne correctement sous environement de devellopement mais a la difusion sur les serveurs IIS (5 ou 6) je tombe régulierement sur le message "Impossible de charger le type MonAppli._Default ou le nom d'une librairie si je lance sur un global.asax. Les ou la DLL sont bien presentes dans le répertoire Bin.

    Curieusement, en faisant quelques manip au niveau du projet, ou en effaçant l'ensemble du repertoire virtuel et en redistribuant, il arrive que l'application ce lance correctement mais, une fois le time out de session et le time out d'application passer, l'erreur revient et le site ne fonctionne plus.

    J'ai aussi tenter le nettoyage des repertoires temporaire des site web sous \windows et vérifier que le système créer bien de nouveau le répertoire de l'application lors de l'appel. Tous semble normal mais le résultat n'est pas meilleur.

    Les ancienne application, déployer avant la semaine derniere fonctionne correctement, par contre, impossible d'effectuer des modifications et de redifusé car l'erreur se produit.

    Que ce soit en Framework 2.0 ou en Framework 3.5 le probleme est toujours le méme. J'ai réalisé une batterie de test avec la méme appli sous VS2005 et VS2008, pas d'erreur de compilation. J'ai vérifier / modifier la sécurité des répertoires sous IIS, pareil. J'ai dégager les objets Ajax, rien a faire.

    Au vue du fait que un coup je veut bien, un coup je veux plus, je penche plutot pour un probléme de sécurité car si la compilation était mauvaise, le site ne démarrerait jamais mais là, je séche complettement.

    Si quelqu'un à déja eu ce phénoméne merci d'avance!!!

    mercredi 19 janvier 2011 09:22

Réponses

  • la solution n'est pas trouvé mais la méthode pour tous remettre en place elle oui. Réinstallation complette du serveur. Pas super comme solution mais maintenant, tous refonctionne correctement.

     

    Mickey41


    Bruno
    • Marqué comme réponse Link.frEditor mercredi 2 novembre 2011 08:49
    mercredi 2 novembre 2011 07:54

Toutes les réponses

  • Bonjour,

    Je crois avoir eu un problème similaire car j'avais deux DLLs qui fournissait le même type. Je pense que j'avais ouvert les DLLs pour trouver le type concernée en utilisant l'explorateur d'objets et je m'étais aperçu que j'avais une vieille DLL qui trainait.

    Cela doit pouvoir arriver également si on a plusieurs pages default.aspx qui ne sont pas chacune dans leur propre namespace. Le message n'est pas un peu plus complet ? (il vient du journal des évènements Windows ?)


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    mercredi 19 janvier 2011 12:39
    Modérateur
  • Merci Patrice de ta réponse

    Le message provient du serveur IIS lors de l'ouverture du site avec:

    Erreur du serveur dans l'application 'monapplie'

    Erreur d'analyse

    Impossible de charger le type 'monapplie._Default'

    Avec bien sur en dessou le header @Page de la page Default bien marquer avec le CodeBehind et Inherits="monapplie._Default'

    Comme il s'agit de site intranet, je suis en mode debug off, de cette maniere, je vois tous suite les problémes.(Le message d'erreur est aussi dans les log bien sur).

    Je n'ais pas plusieurs applications dans ma solution et juste une seule page Default.

    De plus, le problème est le méme pour une autre application qui elle est avec un Global.Asax. La non plus il ne charge pas la librairie au lancement et déclare le méme genre d'erreur. L'Une est sur un serveur IIS6 sous Windows 2003 serveur, l'autre sur IIS 5 sous Windows2000 serveur.

    Le plus bizarre dans cette affaire c'est qu'une remise au propre du répertoire de diffusion et une redistribution permette de relancer l'application correctement, mais une fois le time out application atteint, l'erreur revient. Si il se lance une fois, c'est que la librairie est bonne. C'est comme si l'arret de l'application entrainait un changement de statu peut étre au niveau répertoire ou dans IIS.

    Le mode de gestion des applications n'est pas en cause, l'une est en state server et l'autre en in process. Les serveurs ne sont méme pas les méme par contre, il sont dans le méme domaine. Je me demande si quelque chose n'a pas été modifier au niveau domaine dans la gestion de droit ou de fichier ou de je ne sait quoi.

     

    mercredi 19 janvier 2011 13:21
  • Ok et dans le journal des évènements de Windows il y a quoi ? Les messages sont souvent un peu plus complets dans le journal.

    En terme de structure on a bien une seule application notamment cette application n'a pas une autre application dans un de ses sous dossiers et n'est pas elle-même sous-dossier d'une autre application ?

    Dans quelle DLLs ce type est-il censé être présent ? De mémoire j'avais trouvé en chargeant la DLL pour y trouver le type concerné. Je pense que si c'était un problème de droit le problème serait plus étendu.

    L'application est installée comment (précompilation ?).

    "monapplie._Default" est une faute de frappe. Dans le message d'avant c'est MonAppli._Default. Egalement les namespaces sont sensibles à la casse y compris en VB...

    De mémoire il y également un outil qui s'appelle je crois "fuslog" et qui permet de voir ce qu'il essaie de charger comme DLL. Cela pourrait peut-être donner des indications sur le fichier qui lui manquerait ?


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    mercredi 19 janvier 2011 17:06
    Modérateur
  • Bonjour Patrice

    Le monapplie, c'est juste pour remplacer le nom de l'application. Le nom réel de l'application est PIRELLI.

    Dans les log, j'ai ça. J'ai déja recherché des solutions sur le code d'erreur mais rien qui résolve le problème.

    Type de l'événement : Avertissement
    Source de l'événement : ASP.NET 2.0.50727.0
    Catégorie de l'événement : Événement Web
    ID de l'événement : 1310
    Date :  20/01/2011
    Heure :  08:36:31
    Utilisateur : N/A
    Ordinateur : SRV-DATABASE1
    Description :
    Code de l'événement : 3006
    Message d'événement : Une erreur d'analyse s'est produite.
    Heure de l'événement : 20/01/2011 08:36:30
    Heure de l'événement (UTC) : 20/01/2011 07:36:30
    ID d'événement : 2a06607b5c5340f1ac57350e43d05f3e
    Séquence d'événements : 4
    Occurrence de l'événement : 1
    Code de détail de l'événement : 0
     
    Informations d'application :
        Domaine d'application : /LM/W3SVC/1/Root/PIRELLI-3-129399825862949684
        Niveau de confiance : Full
        Chemin d'accès virtuel de l'application : /PIRELLI
        Chemin d'accès à l'application : D:\Site INTRANET\PIRELLI\
        Nom d'ordinateur : SRV-DATABASE1
     
    Informations sur le processus :
        ID de processus : 12140
        Nom du processus : w3wp.exe
        Nom du compte : AUTORITE NT\SYSTEM
     
    Informations sur l'exception :
        Type d'exception : HttpParseException
        Message d'exception : Impossible de charger le type 'PIRELLI._Default'.
     
    Informations sur la demande :
        URL de la demande : http://srv-database1/PIRELLI/Default.aspx
        Chemin d'accès à la demande : /PIRELLI/Default.aspx
        Adresse d'hôte de l'utilisateur : 10.105.240.1
        Utilisateur : 
        Est authentifié : False
        Type d'authentification : 
        Nom du compte de thread : AUTORITE NT\SYSTEM
     
    Informations sur le thread :
        ID de thread : 6
        Nom du compte de thread : AUTORITE NT\SYSTEM
        Emprunte une identité : False
        Trace de la pile :    à System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding)
       à System.Web.UI.TemplateParser.ParseReader(StreamReader reader, VirtualPath virtualPath)
       à System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath)
       à System.Web.UI.TemplateParser.ParseInternal()
       à System.Web.UI.TemplateParser.Parse()
       à System.Web.UI.TemplateParser.Parse(ICollection referencedAssemblies, VirtualPath virtualPath)
       à System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType()
       à System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider)
       à System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders()
       à System.Web.Compilation.BuildProvidersCompiler.PerformBuild()
       à System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath)
       à System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)
       à System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)
       à System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert)
       à System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert)
       à System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
       à System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
       à System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig)
       à System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
       à System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

    Il s'agit bien d'une précompilation avec la librairie dans le répertoire Bin.

    Il n'y a qu'une seulle DLL..Quand je passe par l'explorateur d'objet, je vois bien la librairie intégrer au projet, avec le namespace PIRELLI et la classe _Default définie à l'intérieur. Ceci ne me garantie pas qu'elle est correctement compilé mais tous semble en place. J'ai changer hier la version de l'assemblie, histoire de voir comment le serveur réagissait avec une librairie de version différente, l'explorateur d'objet le prend bien en compte en me donnant la version 1.0.0.1 au lieu de 1.0.0.0 mais cela ne change rien.

     Les deux projets que je test sont de type différent. Celui là est de type projet application web et l'autre un projet site web.

    Ce qui me titille un peu et que je trouve curieux c'est que la classe _Default est déclarer dans le code "Partial Public Class _Default" là ou les autres classe des autres formulaires sont déclarer "Public Partial Class". J'ai essayer d'inverser dans _Default mais l'éditeur me remet toujours cette ordre. J'ai aussi recréer une page Default et supprimer l'ancienne. Rien à faire. De plus, j'ai redistribuer add lib pour pouvoir lancer n'importe quelle fenetre du site mais si je spécifie un autre nom de page dans l'url d'appel, le message est le méme.

    J'ai fais une réparation du Framework 3.5 sp1 hier sur un serveur (le 3.5 comprend des élements de mise à jour pour le 2.0) et ceci ne semble pas avoir arrangé les chose, voir méme empiré car là, je n'arrive méme plus à lancer l'application, quoi que je fasse.

    Cordialement. 

    jeudi 20 janvier 2011 08:14
  • D'après http://blogs.msdn.com/b/tess/archive/2006/10/13/asp-net-2-0-investigating-net-exceptions-with-windbg-compilation-and-load-exceptions.aspx, HttpParseException serait plutôt causé par :

    - soit le code behind de la page n'a pas été compilé
    - soit une référence vers un assembly qui n'est pas à la même version en dév et sur le serveur de déploiement (une DLL n'aurait pas été mise dans le GAC par exemple ?) L'appli utilise t'elle des références vers des produits tiers ? L'application Web est bien configurée dans IIS pour utiliser la bonne version du .NET Framework ?

    Egalement le fichier est verrouillé par un anti-virus, le service d'indexation ou une sauvegarde. ProcMon (remplace FileMon dont il est question dans l'article) permet éventuellement de vérifier qu'elle est l'opération qui échoue (http://technet.microsoft.com/en-us/sysinternals/bb896645) si c'est bien un problème de lecture de fichier.

    Désolé de cette aide peu efficace mais dans mon cas, le problème semblait plus simple et il faudrait vraiment tomber qui a eu non seulement ce même message mais également pour la même cause que dans ton cas...

     


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    jeudi 20 janvier 2011 12:50
    Modérateur
  • Merci Patrice, c'est déja bien sympa à toi de me donnée des pistes. Des fois, tous seul, on s'entére un peu dans des supositions ou des possibilités sans voir plus large ou ailleur.

    J'ai bien avancé sur le sujet ce matin car j'ai réussie à reproduire l'erreur dans l'environement de devellopement et j'ai pus noter des choses trés curieuses.

    En fait, j'ai repris une autre appli qui est exactement sur le méme moule que celle ci et en la lançant, j'ai eu l'erreur. je me suis donc intérésse à la page default de ce projet pour voir un peu ce qui pouvait clocher.

    Je ne sais pas pourquoi, le designer.vb et la classe code behind de la page Default se vois gratiffier d'un namespace du nom de l'application (appellons la APPX).

    Si je regarde l'objet assembly APPX, je trouve en fait deux namespace l'un APPX, ou se trouve toutes les pages sauf Default et l'autre donnée comme APPX.APPX ou je trouve ma page et classe Default.

    J'ai donc modifier le header de page pour placer le Inherits avec APPX.APPX._Default et là, l'application demarre. Ont peut parfaitement naviguer dans les autres pages qui elles sont APPX.NomDePage.

    J'ai donc reporté ce modéle sur l'application PIRELLI.

    J'ai en premier lieu migrer toutes les pages avec un namespace PIRELLI aussi bine au niveau du designer.vb que sur le code behind.

    J'ai compilé, vérifier l'assembly et là, miracle, l'application demarre correctement aprés publication. Pour en avoir le coeur net, je revient sur mes pas, vire les namespaces, recompile, redistribut et cela fonctionne encore. Curieux.

    Je fairt un arret relance IIS, le site me donne à nouveau l'erreur. Je replace mes namespaces mais juste sur la page Default, recompile, redistribue, encore erreur.

    Curieusement lors du positionnement des namespace, le systeme m'a passer automatiquement toutes les classe declarer "Public Partial Class" en "Partial Public Class". Ce truc là, je le trouve un peu bizarre. Je me demande si le fait de placer Public aprés Partial ne pauserait pas un probléme (mais dans l'explorateur d'objet, la classe est bien noter comme public donc????).

    Il est donc possible que le fichier soit à la bonne place, que le système le trouve mais qu'il se paume dans les namespaces. La seule façons de le voir serait de pouvoir analysé directement l'assembly en sortie de compilation pour explorer ces entrées réel. En étant vicieux et en important cet assenbly dans un projet de test je pense pouvoir découvrir le pot au rose.

    Effectivement ce projet utilise des librairies tierce tel que Crystal report et Ajax pour Framework 2.0 mais d'autre site sur ce méme serveur utilise aussi ces librairies et ils non pas de soucis. Si cela se trouve, c'est carrément mon environement de dev qui à pris une claque et me met la zone dans les codes ou dans la compilation.Je n'espére pas car là, tous refaire, c'est du boulot!!!!

     

    jeudi 20 janvier 2011 13:53
  • En VB, dans les propriétés du projet il y a aussi un "espace de noms racine" par défaut contrairement à C# où à ma connaissance c'est forcément explicite dans les fichiers.

    Il est donc assez facile parfois d'avoir APPX comme espace de noms racine et d'indiquer un espace de nom APPX explicitement dans le fichier ce qui fait que l'on se retrouve alors dans APPX.APPX.

    Je ne pense pas que l'ordre des mots clés soit déterminant.

    Si c'est précompilé mais que les pages ASPX restent compilées à la volée, cela pourrait bien être effectivement qq chose du style, le code behind est compilé en APPX.APPX.Classe alors que la page ASPX hérite de APPX.Classe ou inversement.

    En plus de mémoire, je crois me souvenir que VS ajoute automatiquement un namespace pour les pages default qui dépend du dossier (le problème étant qu'il est parfois assez courant d'avoir plusieurs pages default.aspx dans des dossiers différents et il faut donc ne pas avoir de conflit sur les noms des classes).

    Bon courage !!

     


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    jeudi 20 janvier 2011 16:29
    Modérateur
  • Oui Patrice, effectivement, ce n'est parfois pas trés limpide mais j'ai sortie l'artillerie lourde et je commence à y voir plus clair.

    J'ai pris ma chére et tendre librairie et je l'ai intégrer dans un projet bidon en temps que référence et là, aucun soucis, toute mes classes sont là, dans le bon namespace.

    Alors où est le problème ? En dev, je trouve tous ce qu'il faut, sur le serveur web, il ne trouve pas.

    J'ai installes process monitor sur mon PC et sur le serveur WEB histoire de tracer les ouverture de fichiers et voila ce que je constate.

    Sur mon PC, en dev, le systeme vas ouvrir la librairie qui vas bien dans \windows\microsoft.net\framework\version du framework(2.0)\Temporary asp.net\repx\repy...\pirelli.dll

    Là tous ce passe bien et cela me parait trés normal.

    Sur le serveur, ce n'est absolument pas pareil.

    Il recherche des fichiers precompilé de chaque page dans \windows\microsoft.net\framework\version du framework(2.0)\Temporary asp.net\PIRELLI\fichier machin. On dirait que w3wp interprette mon application comme si je lui avait spécifier un Src dans l'entete de page ce qui n'est pas le cas. De plus, je ne distribue pas le code behind avec le site, il ne peut donc pas auto compiler grand chose.

    La question est maintenant de savoir pourquoi il réagit comme cela alors que le système créer bien toujours dans le "Temporary asp.net" le directory pirelli avec la librairie situer dans des sous directorie.

    En fait, il n'interprette pas le site comme étant pré compilé ou tous du moins, des fois il le comprend mais dans la majorité des cas il ne le comprend pas.

    Bref, patience et longueur de temps font mieux que force ni que rage!!!! Je vais trouvé, je vais trouvé!!!!

    jeudi 20 janvier 2011 16:53
  • Je pensais aux pages ASPX. Il existe un mode dans lequel le code behind est compilé mais les pages ASPX restent compilées à la volée.

    Que contient une page ASPX présente sur le serveur ? Les balises qui définissent son contenu ou un message du style "Il s'agit d'un fichier de marquage généré par l'outil de précompilation, et il ne doit pas être effacé !"


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    jeudi 20 janvier 2011 17:19
    Modérateur
  • Bonjour Patrice

    Les pages ne contienne rien de spécial.

    J'ai revue la doc de dépoiement pour les sites aspx dans l'aide IIS et ceci a comfirmé et eclairé mon probléme.

    En fait, lors du premier démarrage du site, IIS fait une compilation des pages de maniere à conserver une trace lui permettant d'assurer la continuité de fonctionnement du site méme lors d'une mise à jour. Il place tous cela dans \windows\microsoft.net\framework\version du framework(2.0)\Temporary asp.net\nom du site\repx\repy\. Il ne s'agit pas là d'une compilation dynamique lors de l'appel de la page mais d'une compilation global lors du premier appel du site qui est refaite si il constate que les pages ont changé.

    On vas trouver aussi un répertoire assembly ou vont étre placer les différente DLL en provenance du répertoire Bin de l'application.

    Il utilise normalement la librairie du repertoire bin de l'application. Une application aspx doit étre dans un répertoire virtuel, ceux qui est mon cas.

    Donc coté distribution, j'ai l'application déployer dans le répertoire virtuel, les fichiers aspx sont en place, le répertoire bin est present, la librairie est dedans, la classe est bien dans la librairie.

    Coté réaction IIS: Il créer effectivement un répertoire PIRELLI dans \windows\microsoft.net\framework\version du framework(2.0)\Temporary asp.net\, la librairie est bien positionné mais, au lancement du site, il ne compile pas les pages ou tous du moins pas toujours.

    Ce matin j'ai réussie à lancer le site et j'ai bien vue les fichiers compilé apparaitre dans le bon répertoire. J'ai en fait fait quelque modif dans le fichier web.config histoire de voir en comparent avec des web.config d'autre applications. Rien de trés probant car suivant les projets qui sont supposé étre du méme type, on retrouve bien des structures commune mais aussi des chose qui sont sur une et pas l'autre ce sans justification au niveau config ou assembly ou base de donnée.

    Je supose que IIS ne comprend pas ce que je lui demande et le web.config définis normalement la méthode de gestion. Je cherche donc par là.

    Me reste à vérifier comment il régit lors d'un arret / relabce IIS ou de l'arret application car c'est là que le bas blesse, ça demarre et quelque minutes plus tard, il ne veut plus.

    On y est prsque, encore quelques pas je pense et ceci ne devrait étre qu'un mauvais souvenir!!!

     

    vendredi 21 janvier 2011 10:46
  • Bonjour,

     

    Mickey41, avez-vous des nouvelles sur ce projet ? Pouvez-vous nous dire quel est l’état du projet dans ce moment ?

     

    Cordialement,

    Alex

    ________________

    Publiez un article sur MSDN !

    Windows Phone 7

    Astuces pour Visual Studio 2010

    XNA – Développement jeux vidéo

    Didacticiels et astuces : VB.NET, C#, ASP.NET, .NET Framework, Silverlight, Workflow Foundation, SharePoint, WPF

    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

     

     


    Suivez MSDN sur Twitter 

    mercredi 26 janvier 2011 15:37
  • Bonjour Alex

    Actuellement, ce projet (et d'autre) ont toujours le méme probléme au déploiement sur mes différents serveur IIS. Manque de bol suplémentaire, je n'ai pas reçus de mail d'avertissement pour mon abonnement Premium et mon administrateur license non plus. Il a expirer au 31/12/2010, je suis donc coincé pour ouvrir un ticket tant que mon admin n'a pas repris un abonnement pour moi.

    Je cherche actuellement une astuce au niveau de la KB2264107 qui a été installer au 12/01 (mes problémes ont commencer aprés cette date). Ce kb modifie le comportement des API LoadLibrary et LoadlibraryEx. Mon probléme etant au niveau du chargement de la librairie et de la compilation du site, ce KB a peut étre une incidence.

    Si quelqu'un a d'autre piste, merci d'avance!!!

    Cordialement

    Mickey41

    mercredi 26 janvier 2011 16:01
  • Bonjour Mickey41,

    Est-ce que vous avez résolu votre problème ?

    Merci d’avance de tenir la communauté informée sur la suite de vos démarches.

    Cordialement,
    aelassas.free.fr
    vendredi 28 octobre 2011 22:36
    Auteur de réponse
  • la solution n'est pas trouvé mais la méthode pour tous remettre en place elle oui. Réinstallation complette du serveur. Pas super comme solution mais maintenant, tous refonctionne correctement.

     

    Mickey41


    Bruno
    • Marqué comme réponse Link.frEditor mercredi 2 novembre 2011 08:49
    mercredi 2 novembre 2011 07:54