Fichier Readme de Microsoft .NET Framework 4

Pour obtenir la version la plus récente du fichier Readme, cliquez ici.

1. Configuration requise

1.1 Architectures prises en charge

1.2 Systèmes d'exploitation pris en charge

1.3 Configuration matérielle requise

1.4 Autre configuration requise

2. Problèmes connus

2.1 Installation

2.1.1 Framework complet (Installation)

2.1.1.1 Impossible de charger le type 'System.ServiceModel.Activation.HttpModule' après la modification de .NET Framework 3.5 lorsque .NET Framework 4 est installé

Ce problème peut se produire en raison des scénarios suivants :

Le texte complet de l'erreur est le suivant :

Impossible de charger le type 'System.ServiceModel.Activation.HttpModule' à partir de l'assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

Description : une exception non gérée s'est produite au moment de l'exécution de la requête Web actuelle. Contrôlez la trace de la pile pour plus d'informations sur l'erreur et son origine dans le code.

Pour résoudre ce problème :

2.1.1.2 La désinstallation de .NET Framework 4 Bêta 2 laisse des entrées "isapiCgiRestriction" non utilisées dans le fichier applicationHost.config sur Windows Vista, Windows Server 2008 et Windows 7

Sur un ordinateur sur lequel IIS 7 ou IIS 7.5 est activé et .NET Framework 4 installé, la désinstallation de la version Bêta 2 laisse des entrées "isapiCgiRestriction" inutilisées dans le fichier applicationHost.config. Cela se produit sur Windows Vista, Windows Server 2008 et Windows 7. Les entrées inutilisées n'affectent pas la fonctionnalité de serveur Web. Les versions ultérieures de .NET Framework 4 peuvent être installées sur le même ordinateur, car les installations suivantes mettront à jour les entrées "isapiCgiRestriction".

Pour résoudre ce problème :

Supprimez les entrées "isapiCgiRestriction" inutilisées du fichier applicationHost.config. Cependant, cette étape n'est pas requise, car les entrées conservées après la désinstallation n'affectent pas les fonctionnalités du produit ou la possibilité d'installer des versions ultérieures.

2.1.1.3 .NET Framework 1.0 ne peut pas être installé une fois .NET Framework 4 installé

.NET Framework 1.0 ne peut pas être installé une fois .NET Framework 4 installé.  .NET Framework 1.0 doit être installé avant l'installation de .NET Framework 4.

Pour résoudre ce problème :

  1. Ouvrez le Panneau de configuration et Programmes et fonctionnalités.
  2. Désinstallez .NET Framework 4 Extended.
  3. Désinstallez .NET Framework 4 Client Profile.
  4. Installez .NET Framework 1.0.
  5. Installez .NET Framework 4.

2.1.1.4 Échec de l'installation de .NET Framework 4

L'installation de .NET Framework 4 a échoué.

Pour résoudre ce problème :

Reportez-vous au guide de dépannage des problèmes d'installation de .NET Framework 4 Setup troubleshooting guide (http://go.microsoft.com/fwlink/?LinkId=186690)

2.1.1.5 Le service Windows Presentation Foundation (WPF) 4 Font Cache n'est pas complètement supprimé avec la désinstallation de .NET Framework 4 (Framework complet)

Le service Windows Presentation Foundation (WPF) 4 Font Cache n'est pas complètement supprimé avec la désinstallation de .NET Framework 4 (Framework complet).

Remarque : ce problème concerne la version complète et la version Client Profile du .NET Framework.

Pour résoudre ce problème :

  1. Ouvrez la fenêtre de commande en mode Administrateur.
  2. Tapez        'sc delete WPFFontCache_v0400'

“[SC] DeleteService SUCCESS” doit s'afficher.

Lorsque vous actualisez la console des services, le service Font Cache doit s'afficher.  Si cette actualisation ne corrige pas le problème, redémarrez l'ordinateur.

2.1.2 Client Profile (Installation)

2.1.2.1 .NET Framework 1.0 ne peut pas être installé une fois .NET Framework 4 Client Profile installé

.NET Framework 1.0 ne peut pas être installé une fois .NET Framework 4 Client Profile installé.  .NET Framework 1.0 doit être installé avant l'installation de .NET Framework 4 Client Profile.

Pour résoudre ce problème :

  1. Ouvrez le Panneau de configuration et Programmes et fonctionnalités.
  2. Désinstallez .NET Framework 4 Client Profile.
  3. Installez .NET Framework 1.0.
  4. Installez .NET Framework 4 Client Profile.

2.1.2.2 Le service Windows Presentation Foundation (WPF) 4 Font Cache n'est pas complètement supprimé avec la désinstallation de .NET Framework 4 (Client Profile)

Lorsque .NET Framework 4 est désinstallé,  le service WPF Font Cache peut ne pas être totalement désinstallé. 

Bien que le service WPF Font Cache ne puisse plus être utilisé après la désinstallation, l'entrée des services "Windows Presentation Foundation Font Cache 4.0.0.0"  s'affiche toujours dans la console Services.

Sur Windows Vista et Windows Server 2008, le champ "Description" de la console des services indiquera : "<Échec de la lecture de la description. Code d'erreur : 2 >".  Sur Windows XP et Windows Server 2003, le champ "Description" affichera la chaîne correcte.

La réinstallation du .NET Framework corrigera cette erreur. Aucun autre effet n'est connu.

Remarque : ce problème concerne la version complète et la version Client Profile du .NET Framework.

Pour résoudre ce problème :

  1. Ouvrez la fenêtre de commande en mode Administrateur.
  2. Tapez        'sc delete WPFFontCache_v0400'

“[SC] DeleteService SUCCESS” doit s'afficher.

Lorsque vous actualisez la console des services, le service Font Cache doit s'afficher.  Si cette actualisation ne corrige pas le problème, redémarrez l'ordinateur.

2.1.2.3 Échec de l'installation de .NET Framework 4 Client Profile

L'installation de .NET Framework 4 Client Profile a échoué.

Pour résoudre ce problème :

Reportez-vous au guide de dépannage des problèmes d'installation de .NET Framework 4 Setup troubleshooting guide (http://go.microsoft.com/fwlink/?LinkId=186690)

2.2 Désinstallation

2.2.1 Framework complet (Désinstallation)

2.2.1.1 La désinstallation de .NET Framework 4 Bêta 2 laisse des entrées "isapiCgiRestriction" non utilisées dans le fichier applicationHost.config sur Windows Vista, Windows Server 2008 et Windows 7

Sur un ordinateur sur lequel IIS 7 ou IIS 7.5 est activé et .NET Framework 4 installé, la désinstallation de la version Bêta 2 laisse des entrées "isapiCgiRestriction" inutilisées dans le fichier applicationHost.config. Cela se produit sur Windows Vista, Windows Server 2008 et Windows 7. Les entrées inutilisées n'affectent pas la fonctionnalité de serveur Web. Les versions ultérieures de .NET Framework 4 peuvent être installées sur le même ordinateur, car les installations suivantes mettront à jour les entrées "isapiCgiRestriction".

Pour résoudre ce problème :

Supprimez les entrées "isapiCgiRestriction" inutilisées du fichier applicationHost.config. Cependant, cette étape n'est pas requise, car les entrées conservées après la désinstallation n'affectent pas les fonctionnalités du produit ou la possibilité d'installer des versions ultérieures.

2.2.1.2 Le service WPF 4.0 FontCache n'est pas totalement supprimé après la désinstallation de NET4 (Framework complet)

La solution de contournement pour supprimer totalement ce service FontCache consiste à :

  1. Ouvrir une fenêtre de commande en mode Administrateur.
  2. Taper        'sc delete WPFFontCache_v0400'

Vous devez voir :  “[SC] DeleteService SUCCESS”.

Si vous actualisez la console des services, le service FontCache ne doit plus s'afficher.  Un redémarrage peut être nécessaire, si l'actualisation de la console des services n'a pas corrigé ce problème.

(Remarque : ce problème est pour le Framework complet et est une copie du problème du Readme 877240 valable pour Client Profile )

Pour résoudre ce problème :

La solution de contournement pour supprimer totalement ce service FontCache consiste à :

  1. Ouvrir une fenêtre de commande en mode Administrateur.
  2. Taper        'sc delete WPFFontCache_v0400'

Vous devez voir :  “[SC] DeleteService SUCCESS”.

Si vous actualisez la console des services, le service FontCache ne doit plus s'afficher.  Un redémarrage peut être nécessaire, si l'actualisation de la console des services n'a pas corrigé ce problème.

2.2.2 Client Profile (Désinstallation)

2.2.2.1 Le service WPF 4.0 FontCache n'est pas totalement supprimé après la désinstallation de NET4 (Client Profile)

Lors de la désinstallation de .NET 4.0 sur Vista/XP/w2k3/W2k8  le service WPF font cache n'est pas totalement désinstallé. 

Bien que le service WPF Font Cache ne puisse plus être utilisé après la désinstallation, l'entrée des services "Windows Presentation Foundation Font Cache 4.0.0.0"  est conservée et visible dans la console Services.

Sur Vista et W2k8, le champ "Description" de la console des services indiquera : "<Échec de la lecture de la description. Code d'erreur : 2 >".  Sur XP/w2k3, le champ "Description" affichera la chaîne correcte.

La réinstallation du Framework corrigera ce problème. Aucun autre effet n'est connu.

Remarque : ce problème concerne Net4 Client  Profile et NET4 complet

Pour résoudre ce problème :

La solution de contournement pour supprimer totalement ce service FontCache consiste à :

  1. Ouvrir une fenêtre de commande en mode Administrateur.
  2. Taper        'sc delete WPFFontCache_v0400'

Vous devez voir :  “[SC] DeleteService SUCCESS”.

Si vous actualisez la console des services, le service FontCache ne doit plus s'afficher.  Un redémarrage peut être nécessaire, si l'actualisation de la console des services n'a pas corrigé ce problème.

(Remarque : ce problème est pour Client Profile et est une copie du problème du Readme  888322 valable pour le Framework complet ) 

2.3 Problèmes liés au produit

2.3.1 Problèmes d'ordre général

2.3.1.1 Échec de la publication ClickOnce en raison d'un emplacement incorrect des modules linguistiques redistribuables.

Une erreur de build peut se produire si vous utilisez des versions Chinois simplifié ou Chinois traditionnel de Visual Studio 2010 pour publier une application et si vous activez l'option 'Télécharger les composants requis à partir de l'emplacement de mon application' dans la boîte de dialogue Composants requis et sélectionnez l'un des composants suivants :

  1. Microsoft .NET Framework 4 (x86 et x64)
  2. Microsoft .NET Framework 4 Client Profile (x86 et x64)
  3. Microsoft Visual F# Runtime pour .NET 2.0
  4. Microsoft Visual F# Runtime pour .NET 4.0

L'erreur de build suivante peut s'afficher par exemple pour 'Microsoft .NET Framework 4 Client Profile (x86 et x64)' :

'MSB3152: L'emplacement d'installation pour les composants requis n'a pas la valeur 'site Web du fabricant du composant' et le fichier 'DotNetFX40Client\dotNetFx40LP_Client_x86_x64cs.exe' dans l'élément 'Microsoft .NET Framework 4 Client Profile (x86 et x64)' est introuvable sur le disque. Pour plus d'informations, consultez l'aide.'

Pour contourner ce problème :

    Pour contourner ce problème, pour le chinois simplifié, procédez comme suit :

  1. Ouvrez le dossier '%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client'. Pour un système x64, le chemin est %ProgramFiles(x86)%.
  2. Copiez le dossier zh-Hans dans un nouveau dossier nommé zh-chs
  3. Ouvrez le dossier zh-chs.
  4. Ouvrez Package.xml en mode Administrateur.
  5. Modifiez la valeur de >Culture< en zh-chs comme suit :
  6. <Nom chaîne=”Culture”>zh-chs</String>

    Pour contourner ce problème, pour le chinois traditionnel, procédez comme suit :

  1. Ouvrez le dossier '%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client'. Pour un système x64, le chemin est %ProgramFiles(x86)%.
  2. Copiez le dossier zh-Hant dans un nouveau dossier nommé zh-cht
  3. Ouvrez le dossier zh-cht.
  4. Ouvrez Package.xml en mode Administrateur.
  5. Modifiez la valeur de >Culture< en zh-cht comme suit :
  6. <Nom chaîne=”Culture”>zh-cht</String>

2.3.1.2 L'application ClickOnce installe des modules linguistiques redistribuables incorrects.

Vous pouvez ne pas être en mesure d'installer les modules linguistiques chinois simplifié ou chinois traditionnel si vous utilisez des versions chinois simplifié ou chinois traditionnel de Visual Studio 2010 pour publier une application si vous avez activé l'option 'Télécharger les composants requis à partir du site Web du fournisseur de composants' dans la boîte de dialogue Composants requis et sélectionnez l'un des composants suivants :

  1. Microsoft .NET Framework 4 (x86 et x64)
  2. Microsoft .NET Framework 4 Client Profile (x86 et x64)
  3. Microsoft Visual F# Runtime pour .NET 2.0
  4. Microsoft Visual F# Runtime pour .NET 4.0

Pour contourner ce problème :

    Pour contourner ce problème, pour le chinois simplifié, procédez comme suit :

  1. Ouvrez le dossier '%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client'. Pour un système x64, le chemin est %ProgramFiles(x86)%.
  2. Copiez le dossier zh-Hans dans un nouveau dossier nommé zh-chs
  3. Ouvrez le dossier zh-chs.
  4. Ouvrez Package.xml en mode Administrateur.
  5. Modifiez la valeur de >Culture< en zh-chs comme suit :
  6. <Nom chaîne=”Culture”>zh-chs</String>

    Pour contourner ce problème, pour le chinois traditionnel, procédez comme suit :

  1. Ouvrez le dossier '%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client'. Pour un système x64, le chemin est %ProgramFiles(x86)%.
  2. Copiez le dossier zh-Hant dans un nouveau dossier nommé zh-cht
  3. Ouvrez le dossier zh-cht.
  4. Ouvrez Package.xml en mode Administrateur.
  5. Modifiez la valeur de >Culture< en zh-cht comme suit :
  6. <Nom chaîne=”Culture”>zh-cht</String>

2.3.2 ASP.NET

2.3.2.1 Après avoir installé .NET Framework 4 sur Windows 7, vous ne pouvez plus configurer les fichiers aspnet.config pour des pools d'applications individuels sur IIS 7.5

Après l'installation de .NET Framework 4 sur un ordinateur client ou serveur qui s'exécute sur Windows 7 avec IIS 7.5 activé, l'option pour configurer les fichiers de configuration ASP.NET pour différents pools d'applications ne fonctionne plus. Cela se produit car l'installation de .NET Framework 4 entraîne une modification du comportement par défaut pour l'initialisation du CLR (Common Language Runtime). Lorsque .NET Framework 4 est installé, IIS 7.5 sur Windows 7 appelle une DLL ASP.NET 4 native pour effectuer l'initialisation CLR, et cette logique d'initialisation ne permet à l'utilisateur d'utiliser des fichiers de configuration différents.

Pour résoudre ce problème :

Dans la mesure où la logique d'initialisation CLR est fondamentalement la même pour .NET Framework 4 et pour IIS 7.5 (sauf en ce qui concerne le problème du fichier de configuration), vous pouvez reconfigurer IIS 7.5 afin qu'il ne délègue plus l'initialisation CLR à ASP.NET 4. Pour ce faire, vous disposez de deux méthodes.

Option 1
----------
Dans le fichier applicationHost.config d'IIS 7.5 , définissez la valeur par défaut de l'attribut "managedRuntimeLoader" à une chaîne vide, comme dans l'exemple suivant :

<applicationPools>
  <applicationPoolDefaults managedRuntimeLoader="" />
</applicationPools>

Option 2
----------
Dans le fichier IIS_Schema.xml d'IIS 7.5, définissez "defaultValue" dans l'attribut nommé "managedRuntimeLoader" à une chaîne vide. Par exemple, l'attribut d'origine peut ressembler à celui de l'exemple suivant : 

<attribute name="managedRuntimeLoader" type="string" defaultValue="webengine4.dll" />

Modifiez-le dans la balise :

<attribute name="managedRuntimeLoader" type="string" defaultValue="" />

2.3.2.2 La désinscription et la réinscription d'ASP.NET 4 sur Windows XP et Windows Server 2003 provoque une valeur vide pour la version ASP.NET sous l'onglet Propriété ASP.NET dans IIS MMC

Sur Windows XP et Windows Server 2003 (toutes les versions), si vous désinscrivez ASP.NET 4 d'IIS, puis le réinscrivez, IIS MMC affiche une valeur vide pour la liste de version ASP.NET sous l'onglet ASP.NET. Les étapes suivantes provoqueront ce problème :

  1. L'utilisation de la version ASP.NET 4 de aspnet_regiis, exécution de "aspnet_regiis -u"
  2. L'utilisation de la version ASP.NET 4 de aspnet_regiis, exécution de "aspnet_regiis -i -enable"

Pour résoudre ce problème :

Dans la liste de version ASP.NET dans IIS MMC, sélectionnez manuellement la version d'ASP.NET que vous voulez, puis cliquez sur le bouton "Appliquer".

2.3.2.3 Les tâches de compilation ASP.NET sur Windows Vista, Windows Server 2008 et Windows 7 peuvent échouer car le processus de travail IIS ne dispose pas des autorisations en écriture sur le répertoire temporaire Windows

Certaines tâches de compilation ASP.NET sur Windows Vista, Windows Server 2008 et Windows 7 peuvent échouer car le processus de travail IIS ne dispose pas des autorisations en écriture sur le répertoire temporaire Windows (%WINDOWS%\Temp). Lorsque vous essayez de compiler des éléments, tels que des références de service Web qui dépendent de fichiers WSDL, vous pouvez recevoir des erreurs, telles que "Message d'erreur de l'analyseur : Impossible de générer une classe temporaire."
 
Cette erreur se produit si IIS est activé sur l'ordinateur et .NET Framework 4 est installé, mais les fonctionnalités d'extensibilité d'ASP.NET et .NET ne sont pas activées.

Pour résoudre ce problème :

Option 1
----------
Accordez explicitement des autorisations en écriture sur le répertoire temporaire Windows (%WINDOWS%\Temp) pour le compte du processus de travail IIS. Pour ce faire, accordez l'accès en écriture à un groupe qui comprend le compte du processus de travail, par exemple le groupe IIS_IUSRS.
 
Option 2
---------
Activez les fonctionnalités d'extensibilité ASP.NET et .NET. Dans le Panneau de configuration, ouvrez "Programmes", et sous "Programmes et fonctionnalités", cliquez sur "Activer ou désactiver les fonctionnalités Windows". Dans la boîte de dialogue "Fonctionnalités de Windows", ouvrez le nœud "Services Internet (IIS)", puis "Services World Wide Web", puis "Fonctionnalités de développement d'applications". Activez les fonctionnalités suivantes :

     Extensibilité .NET
     ASP.NET

2.3.2.4 Échec de la tentative de chargement des assemblys Web précompilés qui sont déployés dans le GAC et exception "SecurityException" levée lorsque le site Web s'exécute avec une confiance partielle

Vous pouvez précompiler des sites Web ASP.NET en utilisant l'outil en ligne de commande aspnet_compiler.exe. Si vous signez les assemblys résultants avec une clé, vous pouvez déployer les assemblys dans le GAC plutôt que dans le dossier Bin du site Web.

Dans ASP.NET 4, si un site Web qui s'exécute avec une confiance partielle essaie de charger des assemblys à partir du GAC, une exception "System.Security.SecurityException" est levée. Cela se produit car, par défaut, ASP.NET 4 utilise une implémentation de sécurité d'accès du code (CAS) plus récente que les versions antérieures d'ASP.NET. Dans la nouvelle implémentation CAS, les assemblys précompilés et signés qui sont déployés dans le GAC doivent être explicitement marqués avec l'attribut "SecurityTransparent".

Pour résoudre ce problème :

Option 1
--------
Avant de compiler l'assembly, marquez-le avec l'attribut "SecurityTransparent", comme indiqué dans l'exemple suivant :

[assembly:System.Security.SecurityTransparentAttribute]

Option 2
--------
Ajoutez le paramètre "compilerOptions" au fichier Web.config pour le site, comme indiqué dans l'article "Comment : créer des assemblys dont la version est gérée pour les sites Web précompilés" (http://msdn.microsoft.com/en-us/library/ms228042.aspx). Dans ce processus, ajoutez la ligne suivante au fichier AssemblyInfo.vb ou AssemblyInfo.cs qui est référencé par l'option "compilerOptions" :

[assembly:System.Security.SecurityTransparentAttribute]

Option 3
--------
Créez une bibliothèque de classes factice qui contient l'attribut suivant :

[assembly:System.Security.SecurityTransparentAttribute]

Compilez la bibliothèque de classes dans un assembly, puis exécutez l'outil de ligne de commande aspnet_merge.exe sur la sortie du site Web précompilé en utilisant l'option "copyattrs", comme indiqué dans l'exemple suivant :

aspnet_merge c:\MyApplicationRootDirectory -copyattrs assemblyfile.dll

Pour le nom de la DLL, utilisez le nom de la bibliothèque de classes factice marquée avec l'attribut "SecurityTransparent".

Option 4
--------
Repassez temporairement en mode CAS en définissant l'attribut "legacyCasModel" de l'élément "trust" à "true" dans le fichier Web.config pour le site, comme indiqué dans l'exemple suivant :

<trust level="Medium" legacyCasModel="true"/>

Après avoir apporté cette modification, il est recommandé d'utiliser l'une des autres options pour ajouter l'attribut "SecurityTransparent" aux assemblys précompilés. Vous pouvez supprimer l'attribut "legacyCasModel" et exécuter le site Web avec le nouveau mode CAS.

2.3.2.5 Les applications ASP.NET et WCF peuvent ne pas démarrer en mode intégré IIS 7

Si de nouvelles sections de configuration sont ajoutées au fichier Web.config d'une application ASP.NET ou Windows Communication Foundation (WCF), cette application ne démarrera pas en mode intégré IIS 7.

Par exemple, si une section de configuration <standardEndpoints> est ajoutée au fichier Web.config d'une application WCF, cette application ne démarrera pas en mode intégré IIS 7. À la place, IIS 7 retournera une erreur de validation de configuration, car la nouvelle section de configuration n'est pas reconnue par le système de configuration IIS 7.

Pour résoudre ce problème :

Téléchargez et installez un correctif disponible pour ce problème. Le correctif est disponible à l'adresse http://support.microsoft.com/kb/958854. Vous pouvez également installer Windows Vista SP 2, qui comprend ce correctif.  Windows 7 et Windows Server 2008 R2 n'ont pas ce problème, car ces systèmes d'exploitation incluent déjà ce correctif.

2.3.2.6 La réinscription d'ASP.NET 4 peut être nécessaire sur Windows Vista, Windows Server 2008, Windows 7 et Windows Server 2008 R2

ASP.NET 4 doit être réinscrit si la fonctionnalité d'extensibilité IIS 7/7.5 ou .NET IIS7/7.5 est activée *après* l'installation de .NET Framework 4 sur l'ordinateur. ASP.NET 4 doit également être réinscrit si la fonctionnalité d'extensibilité .NET est supprimée lorsque .NET Framework 4 est installé sur l'ordinateur.

Dans les deux cas, la réinscription est requise car le processus d'installation et de désinstallation du système d'exploitation pour IIS7 et IIS 7.5 et pour la fonctionnalité d'extensibilité .NET n'a pas été conçu pour le cas où une version ultérieure du .NET Framework existe déjà sur l'ordinateur.

Pour résoudre ce problème :

Pour réinscrire ASP.NET 4, exécutez la commande suivante :

          aspnet_regiis -iru -enable 

Vérifiez que vous utilisez la version de aspnet_regiis.exe installée dans le répertoire d'installation de .NET Framework 4.

2.3.2.7 L'onglet Console de gestion ASP.NET (MMC) peut ne pas s'afficher lorsque vous gérez un serveur Web distant

L'onglet ASP.NET peut ne pas s'afficher si vous exécutez la console de gestion (MMC) sur un ordinateur local lorsque vous gérez un serveur Web distant. Cela se produit lorsque vous utilisez l'outil de gestion d'IIS 6 pour gérer à distance un serveur Web sur lequel ASP.NET est installé et lorsque l'ordinateur local exécute Windows Server 2008 x64, Windows 7 ou Windows Server 2008 R2 (x86 ou x64).

Pour résoudre ce problème :

Il n'existe aucune solution de contournement.

2.3.2.8 L'exécution de la version ASP.NET 2.0 de "aspnet_regiis -ua" n'inscrit pas d'autres versions d'ASP.NET, y compris ASP.NET 4

L'exécution de la version ASP.NET 2.0 de la commande "aspnet_regiis -ua" sur Windows Vista, Windows Server 2008, Windows 7 ou Windows Server 2008 R2 provoque l'erreur suivante : 

          Cette demande n'est pas prise en charge.

Cela se produit car la version ASP.NET 2.0 de la commande "aspnet_regiis" ne détecte pas qu'une version ultérieure d'ASP.NET existe sur l'ordinateur.

Pour résoudre ce problème :

Exécutez la version ASP.NET 4 de la commande "aspnet_regiis -ua" pour désinscrire toutes les versions d'ASP.NET sur l'ordinateur.

2.3.2.9 L'exécution de "aspnet_regiis -i" sur Windows Server 2003 ne force pas de façon récursive la mise à niveau des répertoires virtuels vers ASP.NET 4

Pour ASP.NET 2.0, la commande "aspnet_regiis -i" met à niveau de façon récursive tous les répertoires virtuels sur Windows Server 2003 pour qu'ils utilisent ASP.NET 2.0. Pour ASP.NET 4, la commande "aspnet_regiis -i" sur Windows Server 2003 met à niveau uniquement la racine d'IIS 6 vers ASP.NET 4. Si des répertoires virtuels sous la racine sont explicitement définis pour exécuter une version spécifique d'ASP.NET, ces répertoires virtuels conservent la version d'ASP.NET qui a été explicitement définie au lieu d'hériter du paramètre ASP.NET 4 des répertoires racines.

Pour résoudre ce problème :

Exécutez les versions ASP.NET 4 de l'une ou l'autre des commandes suivantes :

          aspnet_regiis -s

          aspnet_regiis -r

Ces commandes forcent une mise à jour récursive de tous les répertoires virtuels vers ASP.NET 4.

2.3.2.10 La désinscription d'ASP.NET 2.0 interrompt les compteurs de performance ASP.NET 4

La désinscription d'ASP.NET 2.0 sur un système d'exploitation sur lequel ASP.NET 4 est déjà inscrit endommage certaines inscriptions de compteurs de performance pour ASP.NET 4. Cela se produit car le processus de désinscription d'ASP.NET 2.0 ne peut pas détecter qu'une version ultérieure d'ASP.NET est installée sur l'ordinateur. Il en résulte, que lorsque vous utilisez certains compteurs de performance ASP.NET 4, des erreurs telles que les suivantes peuvent apparaître dans le journal des événements de l'application : 

          "Impossible de trouver la procédure d'ouverture "%pef_counter_name%" dans la DLL "%WINDOWS%\Microsoft.NET\Framework\v4.0.NNNNN\aspnet_perf.dll" pour le service "ASP.NET"."

          "La collecte de données du compteur de performance à partir du service "ASP.NET" a été désactivée à cause d'au moins une erreur générée par la bibliothèque du compteur de performance pour ce service."

Pour résoudre ce problème :

Exécutez la version ASP.NET 4 de la commande "aspnet_regiis -iru".  Cela réinscrit les compteurs de performance ASP.NET 4.

2.3.2.11 Les instances utilisateur SQL Server Express ne fonctionnent pas avec les projets d'application Web sous IIS 6 ou IIS 7 ou avec des applications sous IIS 7.5

Par défaut, les projets Web et les applications Web ASP.NET 4 qui reposent sur les instances utilisateur SQL Server Express ne fonctionnent pas dans les scénarios suivants :

  1. Un projet d'application Web (WAP) est hébergé en tant que répertoire virtuel sur une version d'IIS.  En effet, les instances utilisateur SQL Server Express requièrent des autorisations de fichiers spécifiques pour le dossier Documents de l'utilisateur et le compte de service IIS par défaut (NETWORK SERVICE) ne dispose pas de ces autorisations.
  2. Un site Web est hébergé sur IIS 7.5 sous Windows 7 ou Windows Server 2008 R2. Les informations d'identification de sécurité par défaut pour les pools d'applications IIS 7.5 ne sont pas basées sur NETWORK SERVICE.

Pour résoudre ce problème :

Pour plus d'informations sur la façon de résoudre ces problèmes, consultez l'article  

          http://go.microsoft.com/fwlink/?LinkID=160102

2.3.2.12 Des erreurs de configuration sont levées par ASP.NET 4 ou IIS 7 lorsque des sections associées existent dans les fichiers Web.config au niveau de l'application

Dans ASP.NET 4, la taille du fichier Web.config par défaut a été réduite de façon significative. C'est pourquoi IIS 7 (sur Windows Vista et sur Windows Server 2008) et IIS 7.5 (sur Windows Server 2008 R2) lèveront des erreurs de configuration. Les erreurs exactes dépendent des mises à jour qui ont été installées sur le système d'exploitation et des informations de configuration contenues dans les fichiers Web.config au niveau de l'application.

Windows Vista SP1 ou Windows Server 2008 SP1, sur lequel le correctif KB958854 ou SP2 n'a pas été installé. Dans cette configuration, le système de configuration IIS 7 fusionne mal la configuration managée d'une application en comparant le fichier Web.config au niveau de l'application aux fichiers machine.config ASP.NET 2.0. C'est pourquoi les fichiers Web.config au niveau de l'application de .NET Framework 3.5 ou .NET Framework 4 doivent avoir une section configuration <system.web.extensions> afin de ne pas provoquer d'erreur de validation IIS 7.  Les entrées du fichier Web.config au niveau de l'application modifiées manuellement qui ne correspondent pas précisément aux définitions de section de configuration réutilisables originales proposées par Visual Studio 2008 provoqueront des erreurs de configuration. (Les entrées de configuration par défaut générées par Visual Studio 2008 fonctionnent). Un problème courant est que les fichiers Web.config modifiés manuellement ne contiennent pas les attributs de configuration pour "allowDefinition" et "requirePermission" qui se trouvent dans plusieurs définitions de section de configuration. Il en résulte une non-correspondance entre la section de configuration abrégée dans les fichiers Web.config au niveau de l'application et la définition complète dans le fichier machine.config ASP.NET 4. C'est pourquoi, au moment de l'exécution, le système de configuration ASP.NET 4 lève une erreur de configuration.

Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2 et également Windows Vista SP1 et Windows Server 2008 SP1 lorsque le correctif KB958854 est installé. Dans ce scénario, le système de configuration natif IIS 7 et IIS 7.5 retourne une erreur de configuration car il effectue une comparaison de texte sur l'attribut "type" qui est défini pour un gestionnaire de sections de configuration managé. Dans la mesure où tous les fichiers Web.config qui sont générés par Visual Studio 2008 et Visual Studio 2008 SP1 comportent "3.5" dans la chaîne de type pour les sections de configuration <system.web.extensions> (et associés), et dans la mesure où le fichier machine.config ASP.NET 4 comporte "4.0" dans l'attribut "type" pour les mêmes sections de configuration, la validation de configuration échoue pour les applications générées dans Visual Studio 2008 ou Visual Studio 2008 SP1 dans IIS 7 et IIS 7.5.

Pour résoudre ce problème :

Pour le premier scénario, mettez à jour le fichier Web.config au niveau de l'application en incluant le texte de configuration réutilisable d'un fichier Web.config généré automatiquement par Visual Studio 2008.

Pour le second scénario, supprimez ou commentez toutes les définitions de section de configuration <system.web.extensions> et les définitions de groupe de section de configuration à partir du fichier Web.config au niveau de l'application.

2.3.2.13 Aucune donnée de paramètre n'est passée à la méthode System.Web.Hosting.IProcessHostPreloadClient.Preload

La méthode System.Web.Hosting.IProcessHostPreloadClient.Preload prend un tableau de chaînes comme paramètre d'entrée. Cependant, il n'existe aucun moyen pour définir ces données et aucune information n'est passée à ce paramètre.

Pour résoudre ce problème :

Les premières versions préliminaires de la fonctionnalité de démarrage automatique d'IIS 7.5 prenaient en charge une façon de configurer une ou plusieurs valeurs de chaîne à passer à la méthode IProcessHostPerloadClient.Preload ASP.NET 4. Cependant, cette fonctionnalité a été supprimée avant la version finale de Windows 7 et de Windows Server 2008 R2.

2.3.2.14 La fonctionnalité d'extensibilité .NET IIS7/IIS7.5 sur Windows Vista, Windows Server 2008, Windows 7 et Windows Server 2008 R2 n'est pas intégrée à ASP.NET 4

La fonctionnalité d'extensibilité .NET IIS 7 et IIS 7.5 est une option de configuration qui est disponible dans la boîte de dialogue "Fonctionnalités de Windows" permettant d'installer ou de désinstaller les fonctionnalités IIS 7 ou IIS 7.5. Cette fonctionnalité est située dans le nœud suivant :

Services Internet (IIS) > Services World Wide Web > Fonctionnalités de développement d'applications  > Extensibilité .NET   

Sur Windows Vista, Windows Server 2008, Windows 7 et Windows Server 2008 R2, la fonctionnalité d'extensibilité .NET concerne uniquement l'intégration ASP.NET 2.0 avec IIS 7 ou IIS 7.5. Elle n'a aucun effet sur l'inscription ou la désinscription d'ASP.NET 4 avec IIS 7 ou IIS 7.5.

Pour résoudre ce problème :

Pour gérer l'intégration ASP.NET 4 avec IIS 7 ou IIS 7.5, utilisez la version ASP.NET 4 de la commande "aspnet_regiis.exe".

2.3.2.15 Les applications ASP.NET 2.0 qui s'exécutent sur IIS 6 peuvent générer des erreurs telles que "System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' est introuvable."

Les applications ASP.NET 2.0 qui s'exécutent sur IIS 6 (sur Windows Server 2003 ou Windows Server 2003 R2) peuvent générer des erreurs telles que la suivante :

System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' est introuvable.

Cette erreur se produit uniquement après qu'ASP.NET 4 a été activé sur IIS 6. Cette erreur se produit car ASP.NET détecte qu'un site Web est configuré pour utiliser ASP.NET 4, un composant natif d'ASP.NET 4 passe des URL sans extension à la portion managée d'ASP.NET pour traitement.

Cependant, si les répertoires virtuels qui se trouvent sous un site Web ASP.NET 4 ont été configurés pour utiliser ASP.NET 2.0, le traitement d'URL sans extension produit une URL modifiée qui contient "eurl.axd", qui est envoyé à l'application ASP.NET 2.0. ASP.NET 2.0 ne peut pas reconnaître le format "eurl.axd".  C'est pourquoi, ASP.NET 2.0 essaie de trouver un fichier nommé "eurl.axd" et de l'exécuter.  Dans la mesure où ce fichier n'existe pas, la requête échoue avec une exception "HttpException".

Pour résoudre ce problème :

Option 1
--------
Si ASP.NET 4 n'est pas requis pour exécuter le site Web, remappez le site pour utiliser ASP.NET 2.0.

Option 2
---------
Si ASP.NET 4 est requis pour exécuter le site Web, déplacez un répertoire virtuel ASP.NET 2.0 enfant vers un autre site Web mappé à ASP.NET 2.0.

Option 3
---------
S'il n'est pas pratique de remapper le site Web à ASP.NET 2.0 ou de changer l'emplacement d'un répertoire virtuel, désactivez de façon explicite le traitement d'URL sans extension dans ASP.NET 4. Utilisez la procédure suivante :

1. Dans le registre Windows, ouvrez le nœud suivant: 

     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.<build#>   

 Remarque : <build#> est le numéro de la build de la version Release de .NET Framework 4.

2. Créez une valeur DWORD "EnableExtensionlessUrls".

3. Définissez "EnableExtensionlessUrls" à 0. Cela désactive le comportement d'URL sans extension.

4. Enregistrez la valeur du Registre et fermez l'éditeur du Registre.

5. Exécutez l'outil de ligne de commande "iisreset, qui force IIS à lire la nouvelle valeur du Registre.

 Remarque : la définition de "EnableExtensionlessUrls" à 1 active le comportement d'URL sans extension. Il s'agit du paramètre par défaut si aucune valeur n'est spécifiée.

2.3.2.16 Les sites Web qui utilisent Entity Framework et ont été créés en utilisant des versions préliminaires d'ASP.NET 4 ne fonctionnent plus en raison de références d'assembly manquantes

Les références à des espaces de noms et des assemblys qui sont requises par des projets Web qui utilisent Entity Framework ont été supprimées de la version RTM du fichier Web.config racine. Il en résulte que les sites Web Dynamic Data qui utilisent EntityDataSource, ainsi que les applications Web qui utilisent Entity Framework créées à l'aide de versions préliminaires d'ASP.NET 4 ne fonctionnent pas et signalent des erreurs de compilation.

Pour résoudre ce problème :

Vous pouvez insérer les références manquantes à l'assembly et à l'espace de noms dans le fichier Web.config de l'application. L'exemple suivant indique les éléments d'assembly et d'espace de noms qui doivent être insérés manuellement dans le fichier Web.config au niveau de l'application.

<system.web>

<compilation>
        <assemblies>
            <add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
            <add assembly="System.Web.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
            <add assembly="System.Data.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
            <add assembly="System.Data.Entity.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />             
        </assemblies>
    </compilation>

    <pages>
        <namespaces>
            <add namespace="System.Data.Entity.Design" />
            <add namespace="System.Data.Linq" />
        </namespaces>
    </pages>

</system.web>

2.3.2.17 Les versions préliminaires d'ASP.NET 4 qui s'exécutent sur IIS 7 ou IIS 7.5 en mode intégré peuvent signaler une erreur NullReferenceException non gérée levée à partir de la classe RoleManagerModule

Selon l'ordre d'installation pour .NET Framework version 2.0 et version 4 sur Windows Vista, Windows Server 2008, Windows 7 et Windows Server 2008 R2, les applications ASP.NET 4 lèvent une erreur NullReferenceException non gérée à partir de la classe RoleManagerModule. Cela se produit lorsqu'ASP.NET 4 est la seule version d'ASP.NET inscrite avec IIS 7 ou IIS 7.5, et qu'ASP.NET 2.0 n'a jamais été inscrit avec IIS, ou qu'ASP.NET 2.0 a été désinscrit d'IIS 7 ou IIS 7.5.

Dans ces scénarios, l'inscription autonome d'ASP.NET 4 provoque un ordre incorrect dans le fichier de configuration pour deux modules HTTP qui sont utilisés dans les applications en mode intégré.

Pour résoudre ce problème :

Bien que ce problème soit résolu dans la version Release d'ASP.NET 4, les versions préliminaires d'ASP.NET 4 peuvent avoir spécifié un ordre incorrect pour les modules. Si l'exception non gérée se produit toujours sur un ordinateur qui a été mis à niveau d'une version préliminaire d'ASP.NET 4 vers la version RTM, procédez comme suit :

1.  Ouvrez le fichier applicationHost.config, qui se trouve dans le dossier suivant :

%windir%\System32\inetsrv\config

2. Recherchez l'élément suivant

<location path="" overrideMode="Allow">

Dans cet élément se trouve la liste des modules HTTP pour le mode intégré. Les informations se trouvent dans l'élément <modules>.

3. Recherchez l'élément qui commence par la chaîne suivante :

<add name="RoleManager"  ...

4. Déplacez l'élément situé sous l'élément qui commence par la chaîne suivante :

<add name="DefaultAuthentication"...

5. Enregistrez le fichier.

Lorsque vous avez terminé, une portion de la définition <modules> doit ressembler à l'exemple suivant :

<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" preCondition="managedHandler" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" preCondition="managedHandler" />

2.3.2.18 Les applications Web Forms MVC 2 et ASP.NET 4 qui utilisent le routage d'URL peuvent retourner des erreurs HTTP 404 lors d'une tentative de traitement d'URL sans extension sur IIS 7 et IIS 7.5

Les applications Web Forms MVC 2 et ASP.NET 4 qui utilisent des URL sans extension peuvent retourner des erreurs HTTP 404 lorsqu'elles s'exécutent sur Windows Vista, Windows Server 2008, Windows 7 ou Windows Server 2008 R2. Cette situation peut se produire lorsque l'option d'extensibilité .NET Framework est activée et qu'IIS est installé via la boîte de dialogue Fonctionnalités de Windows. Une installation minimale d'IIS n'inclura pas certains modules HTTP. En raison de la façon dont ASP.NET et IIS gèrent les transitions d'événement pipeline HTTP, les modules HTTP manquants empêchent l'exécution du module de routage d'URL ASP.NET au moment opportun. C'est pourquoi, les demandes d'URL sans extension ne sont pas traitées par le module de routage d'URL et une erreur 404 se produit.

Pour résoudre ce problème :

Dans la boîte de dialogue "Activer ou désactiver des fonctionnalités Windows" du Panneau de configuration Windows
application "Programmes et fonctionnalités", procédez comme suit :

1. Placez-vous sur le nœud suivant :

Services Internet (IIS) --> Services World Wide Web--> Fonctionnalités HTTP communes

2. Vérifiez que l'option "Redirection HTTP" est sélectionnée.

- ou -

1. Placez-vous sur le nœud suivant :

Services Internet (IIS) --> Services World Wide Web--> Fonctionnalités de performances

2. Vérifiez que l'option "Compression de contenu statique" est sélectionnée.

Après avoir sélectionné l'une de ces options, cliquez sur "OK" pour enregistrer les modifications.

La réactivation du module de redirection d'erreur HTTP ou du module de compression de contenu statique permet qu'ASP.NET et IIS synchronisent correctement les événements de pipeline HTTP. Cela permet au module de routage d'URL de traiter les URL sans extension.

2.3.2.19 System.Web.Mobile.dll a été supprimé du fichier Web.config racine

Dans les versions antérieures d'ASP.NET, une référence à l'assembly System.Web.Mobile.dll était incluse dans le fichier Web.config racine dans la section <assemblies> sous <system.web><compilation>. Pour améliorer les performances, la référence à cet assembly a été supprimée.

Pour résoudre ce problème :

L'assembly System.Web.Mobile.dll est inclus dans ASP.NET 4, mais il est déconseillé. Si vous souhaitez utiliser des types de l'assembly System.Web.Mobile.dll, ajoutez une référence à cet assembly, dans le fichier Web.config racine ou dans le fichier Web.config d'une application. Par exemple, si vous souhaitez utiliser l'un des contrôles mobiles ASP.NET (déconseillés), vous devez ajouter au fichier Web.config une référence à l'assembly System.Web.Mobile.dll.

2.3.2.20 Des modifications ont été apportées aux fichiers de définition de navigateur et aux fonctionnalités du navigateur

Les fichiers de définition du navigateur ont été mis à jour pour contenir des informations relatives à des navigateurs et appareils nouveaux ou mis à jour. Les anciens navigateurs et appareils tels que Netscape Navigator ont été supprimés et de nouveaux, tels que Google Chrome et Apple iPhone ont été ajoutés.

Pour résoudre ce problème :

Vous pouvez utiliser les anciens fichiers de définition de navigateur avec ASP.NET 4. Les anciens fichiers de définition de navigateur et la documentation associée, sont contenus dans la version Fichiers de définition de navigateur ASP.NET à l'adresse http://go.microsoft.com/fwlink/?LinkID=186493.

2.3.2.21 ScriptManager.EnableCdn et fichiers Microsoft Ajax localisés

Les versions localisées des fichiers Microsoft Ajax JavaScript , tels que MicrosoftAjax.debug.ja.js, ne seront pas ajoutées au Microsoft Ajax Content Delivery Network (CDN) tant que les versions localisées de .NET Framework 4 ne seront pas sorties. Par conséquent, n'activez pas la propriété ScriptManager.EnableCdn lorsque vous utilisez une version localisée du .NET Framework et CDN.

Pour résoudre ce problème :

Attendez que les versions localisées de .NET Framework 4 soient sorties avant d'utiliser Microsoft Ajax Content Delivery Network (CDN). En attendant, vérifiez que les contrôles ScriptManager dans votre application n'utilisent pas EnableCdn="true".

2.3.2.22 Les compteurs de performance ASP.NET génériques ne signalent que des données d'application ASP.NET 4

Une fois ASP.NET 4 installé, les compteurs de performance ASP.NET génériques ne signaleront que des données d'application ASP.NET 4.  Si les compteurs de performance génériques sont utilisés pour des applications ASP.NET 1.1, ASP.NET 2.0, et ASP.NET 3.5, les compteurs de performance ne signaleront pas de données.  Les données de performance pour les applications qui exécutent des versions antérieures d'ASP.NET doivent utiliser les catégories de performance de la version ASP.NET.

Les compteurs de performance ASP.NET génériques inclus les catégories de compteurs de performance suivantes :  "ASP.NET" et "applications ASP.NET".

Les catégories de performance de la version ASP.NET portent des noms semblables à : "ASP.NET v2.0.50727" et "ASP.NET Apps v2.0.50727".

Pour résoudre ce problème :

Ce comportement est voulu.  La dernière version d'ASP.NET installée sur un ordinateur "contient" les catégories de compteurs de performance génériques.  C'est pourquoi, il est recommandé d'utiliser les catégories de compteurs de performance de version lorsque vous collectez des données de performance de plusieurs applications ASP.NET qui exécutent différentes versions d'ASP.NET.

2.3.3 Winforms

Il n'existe aucun problème connu.

2.3.4 Programmation parallèle

Il n'existe aucun problème connu.

2.3.5 Managed Extensibility Framework

Il n'existe aucun problème connu.

2.3.6 Entity Framework

Il n'existe aucun problème connu.

2.3.7 LINQ to SQL

Il n'existe aucun problème connu.

2.3.8 Windows Communication Foundation (WCF)

2.3.8.1 L'erreur "Le fichier spécifié est introuvable" se produit lorsqu'un service est démarré ou IIS est réinitialisé après la mise à niveau Client Profile

Une fois la mise à niveau de .NET Framework 4 de la version bêta à la version RTM effectuée, l'erreur suivante peut se produire lorsque vous démarrez des services ou redémarrez IIS:

"Le système ne trouve pas le fichier spécifié"

Pour résoudre ce problème :

Réparez .NET Framework Client Profile dans l'application Programmes du Panneau de configuration.

2.3.9 Windows Presentation Foundation (WPF)

2.3.9.1 Windows Presentation Foundation (WPF) n'est pas pris en charge sur ia64

Les assemblys WPF ne sont pas installés ou pris en charge sur des ordinateurs ia64.

Pour résoudre ce problème :

Il n'existe aucune solution de contournement. WPF ne peut pas être utilisé sur des systèmes ia64.

2.3.10 Windows Workflow Foundation (WF)

2.3.10.1 La validation du flux de travail ne prend pas en charge l'opérateur sizeof

Lorsqu'un flux de travail qui inclut l'opérateur sizeof est validé, une exception est levée.

Pour résoudre ce problème :

N'utilisez pas l'opérateur sizeof dans les flux de travail.

2.3.11 Client Profile (Produit)

2.3.11.1 .NET Framework 4 Client Profile n'est pas pris en charge sur des systèmes ia64

.NET Framework 4 Client Profile n'est pas pris en charge sur des systèmes ia64

Pour résoudre ce problème :

Si vous désinstallez .NET Framework 4 sur ia64, désinstallez la version complète et la version Client Profile.

3. Liens associés

              * Jeroen Frijters

 

© 2010 Microsoft Corporation. Tous droits réservés.

Conditions d'utilisation  | Marques  | Déclaration de confidentialité