Le type de fournisseur CodeDom «Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider» n'a pas pu être localisé


159

C'est un projet WebApi utilisant VS2015.

Étape pour reproduire:

  1. Créer un projet WebApi vide
  2. Changez le chemin de sortie de la construction de "bin \" à "bin \ Debug \"
  3. Courir

entrez la description de l'image ici

Tout fonctionne parfaitement jusqu'à ce que je change le chemin de sortie de la construction de "bin \" à "bin \ Debug \". En fait, tout chemin de sortie autre que "bin \" ne fonctionnera pas.

Une petite chose supplémentaire est que, avoir un autre chemin de sortie n'importe où fonctionnerait tant que je laisserais une construction dans "bin \".

Veuillez aider à fournir une solution pour résoudre ce problème. Je suppose que cela coûtera un problème lors du déploiement réel.


Puis-je vous demander pourquoi vous avez modifié le chemin de sortie de votre application Web? Je vous remercie.
X-Mao

Cette exception m'arrive chaque fois que j'actualise une application ASP.NET MVC précédemment exécutée pendant la comilation msbuild .
Nikolay Kostov

La même chose m'est arrivée. Cela a commencé après avoir ajouté des références à quelques bibliothèques .dll. Je l'ai corrigé en désinstallant et en réinstallant les bibliothèques. Et je n'ai aucune idée de pourquoi cela s'est produit.
Letie Techera

Réponses:


127

Si votre projet a des références Roslyn et que vous le déployez sur un serveur IIS , vous risquez d'obtenir des erreurs indésirables sur le site Web, car de nombreux fournisseurs d'hébergement n'ont toujours pas mis à niveau leurs serveurs et ne prennent donc pas en charge Roslyn.

Pour résoudre ce problème, vous devrez supprimer le compilateur Roslyn du modèle de projet . La suppression de Roslyn ne devrait pas affecter les fonctionnalités de votre code. Cela a bien fonctionné pour moi et pour certains autres projets (C # 4.5.2) sur lesquels j'ai travaillé.

Suivez les étapes suivantes:

  1. Supprimez les packages Nuget suivants en utilisant la ligne de commande ci-dessous ( ou vous pouvez utiliser l'interface graphique du gestionnaire de packages Nuget en cliquant avec le bouton droit de la souris sur Root Project Solution et en les supprimant ).

    PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
    PM> Uninstall-package Microsoft.Net.Compilers
  2. Supprimez le code suivant de votre fichier Web.Config et redémarrez IIS . ( N'utilisez cette méthode que si l'étape 1 ne résout pas votre problème. )

    <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701" />
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" />
    </compilers>


4
Je suis bloqué sur "une erreur de serveur dans l'application '/'" depuis environ un jour maintenant. Je compile une simple application Hello World dans Visual Studio 2015, je la déploie sur un serveur Web et j'obtiens cette erreur. La suppression des lignes <compiler> ci-dessus a également permis de résoudre ce problème. J'aimerais savoir comment diable cela se produit et s'il existe une meilleure solution. Je trouve assez incroyable que vous ne puissiez pas déployer une application Hello World de cette manière sans rencontrer de problèmes, c'est comme si MS ne
faisait

4
Pour activer Roslyn, vous pouvez consulter l'article suivant Activation de la plate-forme du compilateur .NET («Roslyn») dans les applications ASP.NET Pourquoi la compilation Roslyn dans ASP.NET? L'activation des nouveaux compilateurs Roslyn dans votre application ASP.NET entraînera deux avantages principaux: * Prise en charge des nouvelles fonctionnalités du langage * Temps de démarrage / pré-compilation de l'application potentiellement amélioré
vibs2006

1
Lorsque j'ai créé un nouveau projet Web, ces références étaient déjà en place. Pourquoi sont-ils installés par défaut, quel est leur objectif? À ma connaissance également, Roslyn est le nouveau compilateur C #. Comment le supprimer ne brise-t-il pas Visual Studio?
Jens Mander

@JensMander sont tous deux des runtimes de compilation. Dans IIS, nous devons activer manuellement le compilateur Roslyn. S'il vous plaît voir le lien dans mon commentaire précédent concernant l'article'Enabling the .NET Compiler Platform.
vibs2006

J'ai eu la même erreur, enfin le dernier package mis à jour pour Microsoft.CodeDom.Providers.DotNetCompilerPlatform résolu pour moi.
Rouge

47

Faites attention de suivre les conseils de cette réponse. Bien que cela résout le problème en question, cela peut entraîner des problèmes différents à une date ultérieure.

J'ai le même problème. Apparemment, le compilateur .NET n'a pas été chargé dans le GAC. Ce que j'ai fait pour le résoudre était:

Tout d'abord, dans le type de console du gestionnaire de packages:

PM> Install-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Maintenant, pour une raison quelconque, les gentils messieurs de Microsoft ont décidé de ne pas l'installer sur le GAC pour nous. Vous pouvez le faire manuellement en ouvrant l'invite de commande du développeur et en tapant:

gacutil -i "C:\*PATH TO YOUR APP CODE*\bin\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll"

Conclusion

Microsoft essaie d'encourager tout le monde à tout faire avec des nugets, ce qui pourrait bien fonctionner sans les bogues occasionnels que vous rencontrez avec le système nuget. Essayez d'utiliser le même projet sur différentes solutions, mettez à jour accidentellement (ou non) l'une des nombreuses pépites qu'il utilise sur l'une d'entre elles, et si vous n'êtes pas chanceux, vous verrez ce que je veux dire lorsque vous essayez de construire l'autre solution. D'un autre côté, placer des fichiers dans le GAC peut également causer des problèmes futurs, car les gens ont tendance à oublier ce qu'ils y mettent et, lors de la configuration de nouveaux environnements, ils oublient d'inclure ces fichiers. Une autre solution possible est de placer les fichiers dans un dossier central pour les DLL tierces (même s'il est étrange d'appeler le compilateur tiers), ce qui crée des problèmes de références brisées lors de la configuration de nouveaux environnements. Si vous décidez d'installer la dll sur le GAC, soyez prudent et rappelez-vous que vous l'avez fait. Si vous ne le faites pas, téléchargez à nouveau le nuget pour chaque projet et supportez tous les bugs gênants causés par celui-ci (du moins, cela se produisait lorsque j'en avais enfin marre et que je plaçais les fichiers dans le GAC). Les deux approches peuvent vous donner des maux de tête et créer des problèmes, c'est juste une question de savoir quels problèmes vous préférez traiter. Microsoft recommande d'utiliser le système nuget, et généralement, il est préférable de les écouter que d'un programmeur inconnu dans SO, à moins que vous ne soyez complètement malade du système nuget et que vous ayez l'habitude de traiter avec le GAC assez longtemps pour que ce soit une meilleure alternative pour vous. téléchargez à nouveau le nuget pour chaque projet et supportez tous les bugs gênants causés par celui-ci (du moins, cela se produisait lorsque j'en avais enfin marre et que je plaçais les fichiers dans le GAC). Les deux approches peuvent vous donner des maux de tête et créer des problèmes, c'est juste une question de savoir quels problèmes vous préférez traiter. Microsoft recommande d'utiliser le système nuget, et généralement, il est préférable de les écouter que d'un programmeur inconnu dans SO, à moins que vous ne soyez complètement malade du système nuget et que vous ayez l'habitude de traiter avec le GAC assez longtemps pour que ce soit une meilleure alternative pour vous. téléchargez à nouveau le nuget pour chaque projet et supportez tous les bugs gênants causés par celui-ci (du moins, cela se produisait lorsque j'en avais enfin marre et que je plaçais les fichiers dans le GAC). Les deux approches peuvent vous donner des maux de tête et créer des problèmes, c'est juste une question de savoir quels problèmes vous préférez traiter. Microsoft recommande d'utiliser le système nuget, et généralement, il est préférable de les écouter que d'un programmeur inconnu dans SO, à moins que vous ne soyez complètement malade du système nuget et que vous ayez l'habitude de traiter avec le GAC assez longtemps pour que ce soit une meilleure alternative pour vous.


41
Ce n'est pas censé être dans GAC. L'intérêt de l'approche Nuget est que votre projet utilise une version spécifique de C # ou VB.NET sans rien changer sur le système hôte. Voir cet article de Damian Edwards de MSFT: blogs.msdn.microsoft.com/webdev/2014/05/12/…
Sudhanshu Mishra

30
Ces assemblées n'appartiennent PAS au GAC, point final. Les placer dans le GAC entraînera un éventuel mal de tête lorsque quelqu'un qui a besoin de maintenir votre code ne peut pas déterminer pourquoi le mauvais compilateur est utilisé.
EKW

5
-1 pour les remarques de Microsoft. C'est comme si c'était cool de le faire ces jours-ci. BTW, les pépites ont de nombreux avantages qui les ont rendues très populaires que vous ignorez tout simplement. Imaginez maintenant ce que les messieurs Microsoft en penseraient.
Fabio Milheiro du

2
@YuvalPerelman Microsoft fait beaucoup de choses destructrices ces 3 à 4 dernières années (comme déstabiliser Visual Studio, produire des produits de très mauvaise qualité). Parfois, je prie même que toute la direction du département de développement soit renvoyée. Cependant, ce n'est certainement pas le cas!
Maris

2
GACing cette dépendance est la chose la plus impressionnante que j'ai vue depuis un moment.
Svend

31

Ajoutez simplement le package nuget suivant à votre projet - Microsoft.CodeDom.Providers.DotNetCompilerPlatform.

Avait le même problème.


Soyez juste un peu prudent; il écrase les 'compilerOptions' dans le fichier web.config, assurez-vous donc de sauvegarder toutes les valeurs personnalisées avant l'installation.
Radderz

19

J'ai le même problème que mon application fonctionnait dans Vs2013 mais obtenant l'erreur après la mise à jour vers Vs2015.

  1. Dans Vs2015, cliquez avec le bouton droit sur le dossier Références du projet pour ouvrir NuGet Package Manager
  2. Sous l'onglet Parcourir, recherchez «DotNetCompilerPlatform» et installez la bibliothèque «Microsoft.CodeDom.Providers.DotNetCompilerPlatform»

2
Merci pour le conseil
faites un

3
Essayez de le désinstaller d'abord, puis réinstallez-le dans NuGet. Cela a fonctionné pour moi.
Matt

Vous êtes une légende
Mo D Genesis

16

Je sais que c'est un ancien fil, mais j'aimerais signaler le problème de version possible de DotNetCompilerPlatform.dll, f. ex. après une mise à jour. Veuillez vérifier si le nouveau fichier Web.config généré est différent de votre web.config publié, en particulier la partie system.codedom. Dans mon cas, c'était le changement de version de 1.0.7 à 1.0.8. La nouvelle dll avait déjà été copiée sur le serveur, mais je n'ai pas changé l'ancien web.config (avec quelques paramètres spéciaux du serveur):

<pre>
  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701" />
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" />
    </compilers>
  </system.codedom>
</pre>

Après avoir mis à jour les deux lignes, l'erreur a disparu.


1
J'ai des problèmes avec DotNetCompilerPlatform chaque seule fois la mettre à jour.
LarryBud

2
Si vous supprimez l'attribut de version, fonctionnera également et empêchera l'erreur de se reproduire lors de la prochaine mise à jour.
MiguelSlv

Même problème que je viens d'avoir sauf que j'ai dû mettre à jour de 2.0.0à2.0.1
Rory McCrossan

12

Selon vos étapes de repro, j'ai supposé que changer le chemin de sortie dans la propriété de l'application était votre seul changement après avoir créé l'application. La seule chose que cette modification fait est qu'elle indique à Visual Studio de placer les assemblys de sortie de MSBuild dans le nouveau dossier. Au moment de l'exécution, cependant, ASP.Net n'aurait aucune idée qu'il devrait charger des assemblys à partir de ce nouveau dossier au lieu du dossier \ bin.

Cette réponse montre comment modifier le répertoire de sortie de construction d'une application WebApi. Pour obtenir exactement la même erreur que celle indiquée dans cet article, vous devez commenter toute la section <system.codedom> dans web.config. Et puis vous pouvez suivre les instructions pour changer le chemin de sortie.

Une fois que votre application fonctionne, vous pouvez décommenter la section <system.codedom>. Si vous n'utilisez pas du tout la nouvelle syntaxe C # 6 dans votre application, vous pouvez désinstaller Microsoft.CodeDom.Providers.DotNetCompilerPlatform de votre application; sinon, vous voudrez peut-être ajouter la ligne de commande suivante dans votre événement post-build,

xcopy /Q /Y "$(TargetDir)roslyn\*.*" "$(TargetDir)..\roslyn\"

Le nouveau fournisseur CodeDom recherche toujours le dossier "\ roslyn" dans \ bin. La commande ci-dessus fonctionne comme une solution de contournement et copie le dossier \ roslyn de votre nouveau dossier de sortie vers \ bin.

Dans mes expériences, l'outil de publication de Visual Studio a cependant publié les assemblys de sortie dans le dossier \ bin de l'emplacement de déploiement, quel que soit le paramètre de chemin de sortie. Je suppose que votre application devrait toujours fonctionner sur un déploiement réel.


10

Méthode simple - Projet> Gérer les packages NuGet ...> Parcourir (onglet)> dans l'entrée de recherche, définissez ceci: Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Vous pouvez installer ou mettre à jour ou désinstaller et installer ce compilateur

DotNetCompilerPlatform


8

Une autre solution possible:

Redémarrez votre instance Visual Studio avec des droits d'administrateur

entrez la description de l'image ici


4

Il s'est arrêté après la publication sur le serveur de production. La raison pour laquelle il m'a montré cette erreur était parce qu'il a été déployé dans un sous- dossier. Dans IIS, j'ai cliqué à droite sur le sous-dossier et excuté "Convertir en application" et après cela, cela a fonctionné.


La conversion en application était tout ce dont j'avais besoin. (C'était un nouveau projet qui n'avait jamais été publié auparavant.)
Patrick

L'utilisation d'un sous-dossier était également mon problème, alors je suis passé au dossier de base et les choses ont commencé à fonctionner.
J_L

4

Dans mon cas, cela s'est produit lorsque je modifie l'autorisation du dossier d'application et que le compte IIS_IUSRS a été supprimé. Après avoir ré-ajouté IIS_IUSRS (Gestionnaire IIS-> YourWebApp -> Modifier l'autorisation -> Ajouter IIS_IUSRS) au dossier de l'application et son fonctionnement.


J'avais ajouté des autorisations IUSR, mais ce n'était pas suffisant. J'ai dû ajouter "IIS_IUSRS" et puis cela a fonctionné.
zacharydl

3

Voici comment je l'ai résolu :

  1. Supprimé le bindossier dans le répertoire du projet.
  2. Cliquez sur Build Solution. Dans VS2017 (Exécuter en tant qu'administrateur)> Build> Build Solution .


2

J'avais un certain nombre de projets dans la solution et le projet Web (problème donnant cette erreur) n'a pas été défini comme projet de démarrage. J'ai défini ce projet Web comme projet de démarrage, et j'ai cliqué sur l'élément de menu "Déboguer" -> "Démarrer le débogage" et cela a fonctionné. J'ai arrêté le débogage, puis j'ai essayé à nouveau et maintenant il fonctionne de nouveau. Bizarre.


2

Puis le problème est revenu. Je désinstallé à la fois Microsoft.CodeDom.Providers.DotNetCompilerPlatformet , Uninstall-package Microsoft.Net.Compilersmais aucune aide. Puis installé - aucune aide. Projet nettoyé et construit aucune aide. Serveur redémarré sans aide.Ensuite, j'ai remarqué que le projet n'avait pas besoin du dernier qui est actuellement 1.0.5 mais 1.0.3 car c'était l'erreur ne pouvait pas charger la version 1.0.3. J'ai donc installé cette version dll à la place et maintenant cela fonctionne.


1

ASP.NET ne recherche bin/debugni aucun sous-dossier sous bin pour les assemblys comme le font les autres types d'applications. Vous pouvez demander au runtime de chercher dans un endroit différent à l'aide de la configuration suivante:

<configuration>
   <runtime>   
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin\Debug;bin\Release"/>
      </assemblyBinding>
   </runtime>   
</configuration>

1

Vous devez mettre à jour les packages «Microsoft.CodeDom.Providers.DotNetCompilerPlatform» et «Microsoft.Net.Compilers» dans votre projet.


1

Dans mon cas, j'ai eu l'erreur lorsque j'avais mon application Web en 4.5.2 et les bibliothèques de classes référencées en 4.6.1. Lorsque j'ai mis à jour l'application Web vers la version 4.5.2, l'erreur a disparu.


Vous avez en effet la même erreur lors de l'installation d'Umbraco 8, pour la mauvaise version .Net (nécessaire 4.7.2) au lieu de 4.5.2 (VS 2017 par défaut)
Bunkerbuster

1

J'obtenais cette erreur car l'utilisateur de mon pool d'applications était défini sur ApplicationPoolIdentity. Je l'ai changé en un compte utilisateur / service qui a accès au dossier et l'erreur a disparu.


1

Voici mes conclusions. J'ai également fait face à ce problème aujourd'hui matin. Je viens d'ajouter mon utilisateur actuel au pool d'applications sur lequel l'application était en cours d'exécution.

Pas:

  1. Ouvrez IIS

  2. Cliquez sur le pool d'applications

  3. Sélectionnez votre pool d'applications sur lequel vous rencontrez un problème

  4. Clic droit -> paramètres avancés

  5. Cliquez sur l'icône à trois points à côté de l' identité

  6. Maintenant, sélectionnez un compte personnalisé

  7. Donnez le nom d'utilisateur et le mot de passe de votre PC

  8. sauver

Actualisez votre application .. et elle commencera à fonctionner. Il y avait un problème de sécurité pour accéder à la DLL.


1

désinstallez simplement le package de la console du gestionnaire de packages à partir de la commande ci-dessous

PM> Package de désinstallation Microsoft.CodeDom.Providers.DotNetCompilerPlatform

PM> Désinstaller-package Microsoft.Net.Compilers

puis réinstallez-le à partir du gestionnaire de nuget entrez la description de l'image ici


1

Si vous avez récemment installé ou mis à jour le Microsoft.CodeDom.Providers.DotNetCompilerPlatformpackage, vérifiez que les versions de ce package référencées dans votre projet pointent vers la version correcte et identique de ce package:

  • Dans ProjectName.csproj, assurez-vous qu'une <Import>balise pour Microsoft.CodeDom.Providers.DotNetCompilerPlatformest présente et pointe vers la version correcte.

  • Dans ProjectName.csproj, assurez-vous qu'une <Reference>balise pour Microsoft.CodeDom.Providers.DotNetCompilerPlatformest présente et pointe vers la version correcte, à la fois dans l' Includeattribut et dans l'enfant <HintPath>.

  • Dans ce projet web.config, assurez-vous que la <system.codedom>balise est présente et que ses <compiler>balises enfants ont la même version dans leur typeattribut.

Pour une raison quelconque, dans mon cas une mise à jour de ce paquet de 1.0.5 à 1.0.8 causé la <Reference>balise dans le .csprojd'avoir son Includepointage à l'ancienne version 1.0. 5 .0 (que j'avais supprimé après la mise à niveau du package), mais tout le reste pointait vers la nouvelle version correcte 1.0. 8 .0.


1

Assurez-vous que votre projet est entièrement construit!

Cliquez sur l'onglet 'Sortie' et assurez-vous que vous n'avez pas quelque chose comme:

========== Tout reconstruire: 14 réussi, 1 échec, 0 ignoré =========

Et ouvrez votre bindossier et vérifiez s'il est à jour.

J'ai eu tout un tas d'erreurs dactylographiées que j'ai ignorées au début, oubliant qu'elles cassaient la construction et conduisaient à ce qu'aucune DLL ne soit copiée.



1

Dans mon cas, mon projet Web n'était pas chargé correctement (il montrait le projet indisponible), puis j'ai dû recharger mon projet Web après avoir ouvert mon studio visuel en mode administrateur, puis tout fonctionnait bien.


0

J'ai juste eu le même problème et c'est parce que j'ai déplacé l'emplacement du projet et que j'avais simplement besoin de recréer le répertoire virtuel.


0

L'exception que nous avons rencontrée n'était pas sur le serveur local mais sur le serveur distant, Azure CI la lisait à partir du dossier packages mais les versions du compilateur mentionnées ci-dessus n'ont pas été trouvées.

Pour résoudre ce problème, nous avons modifié le fichier du projet pour en faire quelque chose comme

Il ne fait référence à aucun des packages ici référençant directement les variables d'environnement.

Cela a résolu le problème, mais dans nos cas, nous n'utilisons pas les packages directement à partir de "package.config" à la place, nous avons un dossier séparé pour maintenir l'intégrité des versions entre les équipes.


0

Accédez à inetmgr à partir de la commande de démarrage Dans la console du gestionnaire IIS, choisissez le dossier d'application sous Site Web par défaut, cliquez avec le bouton droit sur ce dossier, puis Convertir en application Exécutez le fichier .asmx en l'activant. Il a résolu le problème


0

Vérifiez si le BINdossier est téléchargé complètement ou s'il manque dans les fichiers.


Je suis également confronté au même problème, assez nouveau sur asp.net
Prashant Pimpale

0

Concernant cette erreur, j'ai essayé:

  • Nettoyage et reconstruction du projet
  • Déchargement et rechargement du projet
  • Modification du cadre cible
  • Modification du chemin de sortie
  • Ajouter des pépites au GAC
  • Supprimer les packages uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform uninstall-package Microsoft.Net.Compilerset les réinstaller.

Bien que toutes ces solutions semblent valables, je n'ai pu générer que de nouvelles erreurs et à la fin, l'erreur semble pouvoir s'afficher lorsque certaines références / pépites sont manquantes.

Dans mon cas, j'avais récemment réinstallé Microsoft Office et référençais des assemblys comme Microsoft.Office.Core. La nouvelle installation ne semblait pas inclure les packages requis, ce qui empêchait ma solution de se construire correctement.

J'ai pu résoudre ce problème en retravaillant mon code au point que je n'avais pas besoin de faire référence à Microsoft.Office, mais j'aurais pu le résoudre en recherchant les packages requis et en les installant en conséquence.

Cela ressemble à un message d'erreur peu clair de Visual Studio.


0

Si vous avez travaillé sur un projet et que cela vient de s'afficher comme une erreur. Redémarrez votre ordinateur (ou serveur dans mon cas), cela a résolu le problème pour moi.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.