Bonjour, gros soucis j'esaye de compiler mon programme en release et j'ai l'erreur error ASPPARSE: Impossible de charger le type ''montype.webform1'

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler et ensuite le reste du chemin

j'ai tout essayé :

- Fermer le programme, pc etc

- le fichier existe bien 

- Vérifiez que le namespace du code-behind de WebForm1.aspx correspond au namespace dans lequel la classe webform est definie

- Essayez de nettoyer et de reconstruire mon projet avant de compiler en mode release

- Assurez-vous que votre configuration de compilation est correcte et qu'elle inclut le fichier WebForm1.aspx

Bref grosse galere et oui en debug mon programme fonctionne parfaitement. Si vous avez une idée je prend

[HttpException]: Impossible de charger le type 'montype.WebForm1'.
   à System.Web.UI.TemplateParser.GetType(String typeName, Boolean ignoreCase, Boolean throwOnError)
   à System.Web.UI.TemplateParser.ProcessInheritsAttribute(String baseTypeName, String codeFileBaseTypeName, String src, Assembly assembly)
   à System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parseData)
[HttpParseException]: Impossible de charger le type 'montype.WebForm1'.
   à 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.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, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
   à System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
   à System.Web.Compilation.NonBatchDirectoryCompiler.Process()
   à System.Web.Compilation.BuildManager.PrecompileWebDirectoriesRecursive(VirtualDirectory vdir, Boolean topLevel)
   à System.Web.Compilation.BuildManager.PrecompileWebDirectoriesRecursive(VirtualDirectory vdir, Boolean topLevel)
   à System.Web.Compilation.BuildManager.PrecompileAppInternal(VirtualPath startingVirtualDir, IEnumerable`1 excludedVirtualPaths)
   à System.Web.Compilation.BuildManager.PrecompileApp(VirtualPath startingVirtualDir, IEnumerable`1 excludedVirtualPaths)
   à System.Web.Compilation.BuildManager.PrecompileApp(ClientBuildManagerCallback callback, IEnumerable`1 excludedVirtualPaths)
   à System.Web.Compilation.BuildManagerHost.PrecompileApp(ClientBuildManagerCallback callback, List`1 excludedVirtualPaths)
   à System.Web.Compilation.BuildManagerHost.PrecompileApp(ClientBuildManagerCallback callback, List`1 excludedVirtualPaths)
   à System.Web.Compilation.ClientBuildManager.PrecompileApplication(ClientBuildManagerCallback callback, Boolean forceCleanBuild)
   à System.Web.Compilation.ClientBuildManager.PrecompileApplication(ClientBuildManagerCallback callback)
   à System.Web.Compilation.Precompiler.Main(String[] args)

-
Edité par HELBOYS 4 janvier 2024 à 9:48:24

Heu, si ça "fonctionne" en Debug et pas en Release, j'ai une méthode "bourrin".

Utiliser Process Monitor pour voir l'enchainement des chargements de dll et voir où cela diverge.

aurais tu un exemple possible ou une autre solution ?Comme je suis obligé de demander les droits admin sinon pour installer process monitor je prefere comprendre avant.

Merci 

Process Monitor monitore toutes les actions de tous les programmes au niveau des fichiers, de la base de registre, etc...

En comparant l'activité du programme qui compile en Debug mais pas en Release, tu devrais voir des différences dans la séquence d'activités Debug et Release.

Avec cette différence, tu devrais pouvoir remonter vers la source de cette différence : variables d'environnement, réglage du projet, etc ...

Tu ne compiles pas en local ou dans une VM, avant de mettre en prod ?

je compile en local si mais ca marche pour tout sauf ca. Une version pas mise a jour depuis longtemps

avec ca ( le code entier je peux pas le montrer mais on comprend comment ca marche):

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler

Quand ce programme s'exécute pour du Debug, il trouve tout, quand il s'exécute pour de la Release, il manque des choses.

Si t'as les fichiers accédés dans chacune de ces exécutions, t'auras le motifs de la différence de comportement du compilateur.

La méthode "System.Web.UI.TemplateParser.ParseString" cherche à charger dans l'AppDomain l'assembly contenant le code binaire de type "montype.WebForm1" (et les assemblies des classes mères de celle-ci).

En ASP.NET, il y a la possibilité de faire de la compilation à la volée pour compiler le code source en bitecode .NET.

.NET pouvant faire du JIT compilation pour convertir le bytecode .NET en natif ou utiliser directement des machins pré-buildés.

Tout ce fatras est piloté par de la configuration en base de registre et autres bidules.

En debug, dans la liste des dll chargées dans l'AppDomain, il y a la Dll contenant l'implémentation (bytecode .NET) de "montype.WebForm1".

Vérifiez que c'est bien la même dll qui est chargée dans l'AppDomain en Release.

Ce n'est vraisemblablement pas le cas car la configuration est différente dans ces 2 cas.

En connaissant la différence, on devrait pourvoir changer la configuration pour que la version Release trouve ce qu'il faut, comme la version Debug.

Vous avez cette Dll sous la main, pour qu'on la passe au désassembleur .NET ?

Il y a une approche un peu moins bourrin, c'est d'utiliser le "fusion log" :

Fuslogvw.exe (Visionneuse du journal de liaison d’assembly) - .NET Framework | Microsoft Learn

bonjour j'ai essayé et la dll est presente dans les 2 cas donc je ne sais toujours pas d'ou ca provient.

- package nuget verifié

- chemins d'accès aux fichiers verifié 

- j'ai testé d'autre version de framework ca n'a rien changé

- vider mon bin pour etre sur pareil rien 

-
Edité par HELBOYS 19 février 2024 à 16:59:20

Les "fusion log" ne disent rien ???

Vous êtes sûr que c'est la même architecture d'AppDomain qui est utilisé Debug et en Release ?

>Aucune erreur de génération et si je lance la version release elle tourne tres bien

Je comprends plus, c'est en Release ou en Debug que cela ne fonctionne pas ?

Pas possible de monter un environnement de test où vous êtes admin, dans une VM par exemple ?

Vous avez vérifié dans ILDASM si la Dll est "complète" ?

-
Edité par bacelar 20 février 2024 à 10:59:09

Bonjour, c'est quand je tente de publier donc en compilation. Pour une mise en prod. Non impossible d'avoir une vm de test. La dll ILDASM n'existe pas dans mon projet. Sans la mise en prod on peut uniquement balancer la page en html et non aspx et donc les formulaires ne fonctionne pas puisque tout est écrit en C#. Il faut donc absolument qu'il arrête d'afficher cette erreur.

Au besoin je peux fournir plus de précision mais j'ai pas plus d'idée :/. Merci en tout cas pour le temps donné !

Il faut que t'insiste pour que tes admin t'installent un player de VM et, si possible, un master de la plateforme de production où tu pourras être admin.

Tu dois pouvoir tester correctement ce que tu produis.

La dll générée en production est vraisemblablement erronée, demandes à tes admins de te la fournir.

Pas moyen de faire un projet qui reproduit le problème que tu peux partager ?

le projet n'a pas etait mis en prod depuis 2 ans je suis retourné sur le 1er commit. J'ai lancé, j'ai mis release et pouf ca fonctionne pas non plus. Dans le doute j'ai testé sur un deuxième pc et ca fonctionne pas non plus. Ca me semble assez fou que meme avant ca ne fonctionne pas. J'ai acces a la prod mais ca apporte pas grand chose. La franchement j'ai pas d'idée.

Concrètement si je pourrais voir pour partager c est juste un projet C# qui correspond a un site internet basique avec juste un formulaire de contact 2 bouton et après c est de la mise en page. J'ai cette version pour compiler : v4.0.30319\aspnet_compiler (la ou je fais donc dans un bash) qui ensuite me rebalance les fichiers release compilé pour mettre en prod . Voila voila

-
Edité par HELBOYS 21 février 2024 à 11:34:48

Je pense que c'est un problème de configuration, pas de code.

Donc que la vieille version ne "fonctionne" pas/plus, cela ne me choque pas, c'est "tombé en marche".

Vous pouvez pas lancer le bidule sur une machine où vous avez les droits admin ?

Ca n'apportera pas grand chose d etre juste en admin. j'ai tenté avec d'autre config, verifier chaque fichier. Detruire et refaire. renommer pour qu il rebuilde une nouvelle config. nettoyé chaque partie de code. Sans l admin on peut deja tout voir dans les dll compilé, dans le programme en lui meme aussi.

La vm ne va rien m apporter je ne peux deja rien casser sur le pc. Process monitor n'a finalement servie a rien j'ai pas d'erreur et pas de difference 

-
Edité par HELBOYS 21 février 2024 à 14:48:23

HELBOYS a écrit:

J'ai deja eu le meme soucis que dans la publication que ta donné sur un autre projet et c'est pas la meme chose du coup ca n'aide pas malheureusement

>Ca n'apportera pas grand chose d etre juste en admin

Bin si, avoir accès au "fusion log".

>Sans l admin on peut deja tout voir dans les dll compilé

Ok, alors utilisez ILDASM pour vérifier si c'est le compilateur qui déconne ou votre configuration.

>La vm ne va rien m apporter

Si, le fait de pouvoir être admin (=> avoir accès au "fusion log") et de tester librement les corrections de configurations nécessaires.

>Process monitor n'a finalement servie

Si, être sûr de la Dll utilisée et donc pouvoir l'analyser avec ILDASM.

Est-ce que votre problème est facilement reproduisible à partir d'un projet "exemple" ?

>je peux crée un depot sinon ou partager les fichiers en modifiant juste certaine chose.

Un dépôt Git, ça serait mieux (versionning, etc...) mais attention de ne pas partager des données sensibles. Si t'as un exemple minimaliste qui reproduit ton problème, ça serait top.

Pour la Dll, la version qui n'arrive pas à se charger.