Impossible de trouver une partie du chemin… bin \ roslyn \ csc.exe

813

J'essaie d'exécuter le projet Asp.net MVC récupéré du contrôle de source TFS. J'ai ajouté toutes les références d'assembly et je suis capable de construire et de compiler avec succès sans aucune erreur ni avertissement.

Mais j'obtiens l'erreur suivante dans le navigateur:

Impossible de trouver une partie du chemin «C: \ B8akWorkspace \ B8akProject \ B8akSolution \ B8AK.Portal \ bin \ roslyn \ csc.exe».

Voici une capture d'écran complète de la page d'erreur.

entrez la description de l'image ici

Après quelques jours de recherche, j'ai compris que Roslyn est une plate-forme de compilateur .Net qui offre des fonctionnalités de compilation avancées. Cependant, je ne comprends pas pourquoi ma génération essaie de trouver \ bin \ roslyn \ csc.exe car je n'ai configuré aucun élément lié à Roslyn et je n'ai pas l'intention d'utiliser Roslyn dans mon projet.

Eyad
la source
10
Quelqu'un peut-il expliquer pourquoi cela est nécessaire dans le cadre de l'exécution d'une application ASP.NET compilée? À quoi sert csc.exe?
gregmac
1
Je pense que cela explique l'implication de roslyn
andy250
4
Le dossier roslyn n'était pas copié dans le dossier bin Je l'ai corrigé en installant le package d'installation ci-dessous Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Abdullah Tahan
12
La réinstallation de Microsoft.CodeDom.Providers.DotNetCompilerPlatform a résolu mon problème.
SurenSaluka
4
J'avais cela après avoir ouvert mon projet dans VS 2019. Il fonctionnait auparavant sur VS 2017. J'ai trouvé que le simple fait de rétrograder Microsoft.CodeDom.Providers.DotNetCompilerPlatform vers n'importe quelle version précédente puis de revenir à la dernière version a résolu le problème. Il a corrigé quelques problèmes dans mon .csprojdossier.
Neo

Réponses:

436

Le problème avec les modèles VS2015 par défaut est que le compilateur n'est pas réellement copié dans le répertoire tfr \ bin \ roslyn \, mais plutôt dans le répertoire {outdir} \ roslyn \

Ajoutez ce code dans votre fichier .csproj:

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" Condition="!$(Disable_CopyWebApplication) And '$(OutDir)' != '$(OutputPath)'">
    <ItemGroup>
      <RoslynFiles Include="$(CscToolPath)\*" />
    </ItemGroup>
    <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
    <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>
Mitchell
la source
9
Cela ne résout pas mon problème. Maintenant, j'obtiens «Impossible de trouver le fichier» C: \ B8akWorkspace \ B8akProject \ B8akSolution \ B8AK.Portal \ bin \ roslyn \ csc.exe » . Veuillez noter que lorsque je crée un nouveau projet MVC dans VS2015, je ne vois pas la configuration mentionnée dans .csproj et cela fonctionne parfaitement dans le navigateur
Eyad
4
Merci. Je peux maintenant créer et exécuter le projet dans le navigateur après avoir téléchargé le répertoire Roslyn et l'avoir placé dans le dossier / bin. Je n'ai pas mis le PstBuildEvent mentionné ci-dessus et cela fonctionne toujours. Vous souhaitez peut-être modifier votre réponse ci-dessus et mentionner la nécessité de placer manuellement les fichiers Roslyn et de mieux refléter la solution.
Eyad du
2
Eh bien, dans une situation normale; vous devriez avoir le compilateur dans votre dossier $ (OutDir) roslyn *. *, donc ce script copiera le compilateur dans le dossier bin de votre projet. Apparemment, votre installation de vs2015 ne comprenait pas le compilateur.
Mitchell du
9
J'ai trouvé que la mise à jour de Microsoft.CodeDom.Providers.DotNetCompilerPlatform vers 1.0.8 et Microsoft.Net.Compilers 2.6.1 m'a beaucoup aidé. Je n'avais pas besoin d'ajouter cette cible supplémentaire. On dirait que quelque chose de similaire a été ajouté dans une version ultérieure de l'outillage: github.com/aspnet/RoslynCodeDomProvider/commit/…
Ian Robertson
5
J'ai mis à jour la version de Microsoft.Net.Compilers vers la version 2.10.0 du Nuget et cela a été la solution pour moi. J'utilise targetFramework = "4.6.2"
juanytuweb
1163

TL; DR

exécutez ceci dans la console du gestionnaire de packages:

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Plus d'information

Ce problème n'est pas lié à Visual Studio lui-même, donc les réponses suggérant d'ajouter des étapes de génération pour copier des fichiers sont plutôt une solution de contournement. Idem avec l'ajout manuel de binaires du compilateur au projet.

Le compilateur Roslyn provient d'un package NuGet et il y a / il y avait un bug dans certaines versions de ce package (je ne sais pas exactement lesquelles). La solution consiste à réinstaller / mettre à niveau ce package vers une version sans bogue. À l'origine, avant d'écrire la réponse en 2015, je l'ai corrigée en installant les packages suivants dans des versions spécifiques:

  • Microsoft.Net.Compilers 1.1.1
  • Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.1

Ensuite, j'ai regardé dans .csproj et je me suis assuré que les chemins d'accès aux packages sont corrects (dans mon cas .. \ .. \ packages \ *. *) À l'intérieur des balises <ImportProject>en haut et <Target>avec le nom "EnsureNuGetPackageBuildImports" en bas. C'est sur MVC 5 et .NET Framework 4.5.2.

andy250
la source
11
C'était mon problème - le dossier bin / roslyn est là quand un projet est créé, cependant, si vous le supprimez ou, comme le contrôle de code source, il n'est pas copié, alors il n'est pas reconstruit. Je pense qu'il y a un peu un problème de "synchronisation" avec les versions, une fois que 1.0.1 est installé et met à jour le fichier d'importation dans le projet pour corriger la version, une version copiera alors automatiquement le dossier Roslyn - pas besoin de ces messages construire des commandes.
Jester
16
Je suis presque sûr que c'est la meilleure solution ... en essayant moi-même avec un package de mise à jour
-reinstall -projectname myprojectname
5
Après avoir fait tout cela, rien n'a changé pour mon projet. Le dossier bin est toujours aplati.
brianary
8
Une remarque: la version 1.0.3 du package Nuget Microsoft.CodeDom.Providers.DotNetCompilerPlatform fonctionne pour moi, mais la version 1.0.6 provoque l'erreur dans cette question.
Daniel Neel
176

Votre build essaie de trouver \bin\roslyn\csc.execar les packages suivants ont été ajoutés à votre projet. Examinez simplement votre packages.configdossier, vous pouvez les avoir tous les deux là-bas

Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Microsoft.Net.Compilers

Qu'est-ce que Roslyn et qui les a ajoutés (packages) dans le projet: Si vous utilisez .net Framework 4.5.2 pour créer des projets à l'aide de VS2015, vous avez peut-être remarqué que les modèles de projet utilisent Roslyn par défaut. En fait, Roslyn est l'un des compilateurs open-source pour les langages .NET de Microsoft.

Pourquoi devrions-nous supprimer Roslyn: si votre projet a des références Roslyn et que vous souhaitez le déployer sans serveur, vous obtiendrez des erreurs indésirables sur le site Web car de nombreux hébergeurs 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.

si vous n'êtes pas intéressé à utiliser Roslyn, suivez les étapes ci-dessous pour le supprimer

1. Supprimez les packages NuGet, utilisez les commandes suivantes à partir de Nuget Package Console

PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Uninstall-package Microsoft.Net.Compilers

2. Après cela, votre fichier web.config doit être mis à jour automatiquement. Dans le cas contraire, recherchez le code ci-dessous dans le web.configfichier et s'il est trouvé, supprimez ce morceau de code.

<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>
      <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+"></compiler>
    </compilers>
</system.codedom>
Malik Khalil
la source
28
Ce n'est pas vraiment une solution si vous voulez réellement utiliser le nouveau compilateur et les nouvelles fonctionnalités.
Matti Virkkunen
14
Vous plaidez contre l'avenir.
cchamberlain
2
@cchamberlain pourquoi est-ce l'avenir? Je pense simplement qu'il devrait être simple à utiliser, mais il semble que beaucoup de gens ont des problèmes avec cela.
Alisson
1
@Alisson - Roslyn est la direction dans laquelle les choses évoluent. Il contient de nouvelles fonctionnalités de langage, est plus performant, multiplateforme et open source. Il est sorti après les autres outils - donc futur. Rien ne dit que vous devez l'utiliser, la plupart des mises à niveau entraînent des coûts. Voir la "Pourquoi la compilation de Roslyn dans ASP.NET?" section: blogs.msdn.microsoft.com/webdev/2014/05/12/…
cchamberlain
1
si vous souhaitez publier un projet MVC sur l'hébergement Windows partagé GoDaddy, voici la réponse. GoDaddy n'exécute pas d'exécutables comme csc.exe
Jeson Martajaya
141

Un nettoyage et une reconstruction ont fonctionné pour moi!

pipedreambomb
la source
4
Je ne pense pas que le nettoyage soit nécessaire. Selon cette discussion sur le problème, une reconstruction qui n'est pas une version standard remettra toujours le fichier roslyn. github.com/dotnet/roslyn/issues/15556
leemicw
J'ai également simplement exécuté Build> Rebuild Solution et l'erreur a disparu.
Matt Merrill
Reconstruire résolu pour moi, je l'ai remarqué dans la sortieCopying file from "C:\Users\medmondson\Source\UK\Portal\Branches\v12\Source\packages\Microsoft.Net.Compilers.1.3.2\tools\csi.exe" to "bin\Debug\roslyn\csi.exe".
m.edmondson
12
La reconstruction n'a pas fonctionné pour moi. Après Clean + Rebuild, l'erreur a disparu.
Bruno Miquelin
2
DotNetCompilerPlatform 1.0.3, Microsoft.Net.Compilers 1.3.2, VS Pro 2017 15.9.4 ici. Un nettoyage / reconstruction n'a pas fonctionné pour moi, même avant et après le redémarrage de Visual Studio. Enfin, un Build> Batch Build ...> Rebuild All a fait l'affaire. Il a dû chuchoter juste le bon-rien pour que VS voie qu'il manquait le répertoire bin / roslyn dans la sortie.
Johann
59

Voici une façon plus MSBuild de procéder.

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" Condition="!$(Disable_CopyWebApplication) And '$(OutDir)' != '$(OutputPath)'">
    <ItemGroup>
      <RoslynFiles Include="$(CscToolPath)\*" />
    </ItemGroup>
    <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
    <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>

Mais je remarque que les fichiers roslyn sont également dans mon répertoire bin (pas dans un dossier). Cependant, l'application semble fonctionner.

Rob Cannon
la source
4
Vous pouvez le placer n'importe où dans votre fichier .csproj, au même niveau qu'une autre balise <Target>. Je le mets généralement vers le bas.
Rob Cannon
Cela devrait vraiment être la réponse acceptée. Vous pouvez vérifier cela dans la source et le prochain pauvre schmuck qui tire votre repo n'aura pas à passer par le même problème.
Andrew Clear
37

Comme indiqué dans un problème du projet Roslyn sur GitHub , une solution (qui a fonctionné pour moi) consiste simplement à décharger et recharger le projet dans Visual Studio.

Le dossier "bin \ roslyn" n'a pas été créé lors de la construction ou de la reconstruction tant que je n'ai pas rechargé le projet.

Christian Davén
la source
Merci, ça a marché pour moi. Le problème sur le référentiel dotnet était ouvert en 2016 et nous avons toujours ce problème sur Visual Studio 2019. Je ne peux pas croire qu'il soit réel!
Felipe Oriani
26

J'ai suivi ces étapes et cela a parfaitement fonctionné

  • Supprimer tous les dossiers bin et obj
  • Solution propre et reconstruction
  • Exécutez cette commande dans PowerShell

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Masoud Darvishian
la source
22

Après avoir essayé toutes les corrections sans cigare, je l'ai corrigé en mettant à jour ce package Nuget dans Visual Studios:

Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Le mien était de 1.0.0 à 2.0.0 pour référence (l'erreur ne s'affiche plus)

josh.thomson
la source
3
C'était tout pour moi comme wel. Même 2.0.0 était trop faible pour mon projet, il exigeait 2.0.1.
yesman
3
Cela l'a résolu pour moi. J'ai rétrogradé, ce qui a dû résoudre le problème, puis j'ai mis à jour la dernière version.
Daniel Jackson
1
J'ai fait ça aussi. Maintenant, le roslyndossier est créé dans mon chemin de sortie. Je ne vois pas non plus de référence "roslyn" dans mon csproj. Il se pourrait que ce Target Name="CopyRoslyn...soit une chose VS2015 et non nécessaire dans (la version de) 2017 que j'ai. À noter: depuis que j'ai mis à jour DotnetCompilerPlatform avant de jouer avec l'ajout d'une cible de copie (celle que j'ai mentionnée), j'ai un csproj plus propre.
LosManos
1
Celui-ci vient de m'arriver. Ce message est une bouée de sauvetage. J'ai ce même message d'erreur à plusieurs reprises et cela semble toujours être une raison entièrement différente!
Brian Knoblauch
19
  1. Solution propre
  2. Solution de reconstruction, ces deux étapes ont fonctionné pour moi.
nischa
la source
Merci, cela a aussi fonctionné pour moi.
Joey Phillips
1
Travaux. J'ai accidentellement appuyé Ctrl Clorsque j'étais en train de vérifier une succursale gitet cela a foiré mon repo. git reset --hardn'a pas fonctionné, j'ai donc git clean -xdfdû reconstruire le projet. Cependant, j'ai rencontré cette erreur, j'ai donc simplement nettoyé et reconstruit le projet à nouveau et cela a fonctionné pour moi.
Paul Carlton
15

Gestionnaire de packages NuGet

Vous devez installer Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix, a été spécialement créé pour cette erreur

Adrian Berca
la source
Cela n'a pas fonctionné - je soupçonne que le package n'est pas réellement destiné à cet usage précis.
Drew Miller
J'ai testé avec VS 2017 et cela fonctionne bien, cela pourrait être un problème avec d'autres versions.
Juan Acosta
11
Je n'installe pas de packages aléatoires d'une personne aléatoire avec «dsx» comme surnom. C'est une grande sécurité non ...
Mateusz
1
@Mateusz ou un qui corrigerait la structure de mon dossier nonAPS.NET [sic]
Eliasar
14
  • Faites un clic droit sur votre projet et sélectionnez Gérer les packages Nuget
  • Rechercher "Microsoft.CodeDom.Providers.DotNetCompilerPlatform"
  • Mettez simplement à jour vers une version plus ancienne ou plus récente (peu importe laquelle), puis effectuez une nouvelle mise à jour vers votre version d'origine.

Cela réinstalle toutes les dépendances et les fichiers du package (comme csc.exe)

Nuget - DotNetCompilerPlatform

Bojan
la source
Cela l'a corrigé pour moi! Merci!
Mason
11

Donc, la réponse de Rob Cannon a essentiellement fonctionné pour moi, mais j'ai dû modifier quelques options. Plus précisément, j'ai dû supprimer la condition sur la cible, ainsi que modifier l'attribut Include, car $ CscToolPath était vide lorsque le projet était en cours de génération sur notre serveur de génération. Curieusement, $ CscToolPath n'était PAS vide lors de l'exécution locale.

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" >
  <ItemGroup>
    <RoslynFiles Include="$(SolutionDir)packages\Microsoft.Net.Compilers.1.1.1\tools\*" />
  </ItemGroup>
  <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
  <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>
jonnybot
la source
1
Le comportement est encore pire. Localement, si vous allez dans votre dossier de package et supprimez les deux dossiers Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.nn et que vous créez du code, le $ CscToolPath sera vide. Si vous construisez une deuxième fois, ce ne sera pas vide. Le problème se produit tout le temps sur votre serveur de build, car il est toujours considéré comme une "première build". Votre code fonctionne parfaitement, mais si vous mettez à jour le package Microsoft.Net.Compilers , vous devrez mettre à jour le .csproj . Je vous remercie.
Julien D.
3
Notez que cette solution échouera (ou doit être ajustée) si la version de Microsoft.Net.Compilers change.
JanDotNet
J'ai mis à niveau la plateforme Microsoft.CodeDom.Providers.DotNetCompilerPlatform, puis j'ai pu continuer.
iowatiger08
10

La mise à jour des packages nuget a fonctionné pour moi Cliquez avec le bouton droit sur la solution> Gérer les packages NuGet pour la solution et mettre à jour tous les packages et spécialement: Microsoft.Net.Compilers et Microsoft.CodeDom.Providers.DotNetCompilerPlatform

hichamkazan
la source
Cela a fonctionné pour moi cette fois. L'erreur Roslyn / csc.exe manquante revient constamment pour moi et la solution est assez souvent différente ...
Brian Knoblauch
10

Il s'agit d'un problème connu avec Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.6. La rétrogradation vers 1.0.5 a résolu ce problème pour moi.

jrummell
la source
C'est juste. J'ai rencontré ce problème avec la version 1.0.6 uniquement lors de la publication sur Azure. Rétrogradation à 1.0.5
Augusto Barreto
Rétrogradé de 2.0.0 à 1.0.5 et cela a fonctionné. Cependant, je mangeais un sandwich à la dinde à l'époque qui était probablement en partie responsable de la solution. Allez comprendre.
barneymc
10

Pour VS 2019, supprimez complètement le nœud suivant:

<system.codedom>
</system.codedom>
Shadi Namrouti
la source
9

Selon un commentaire de Daniel Neel ci-dessus:

la version 1.0.3 du package Nuget Microsoft.CodeDom.Providers.DotNetCompilerPlatform fonctionne pour moi, mais la version 1.0.6 provoque l'erreur dans cette question

La rétrogradation vers 1.0.3 a résolu ce problème pour moi.

Jason Coyne
la source
@akatakritos cela a aidé. Je cherchais des heures. Merci à vous deux.
erincerol
2
1.0.7 est toujours affecté dans certains scénarios github.com/aspnet/RoslynCodeDomProvider/issues/17
altso
1
1.0.5 est la version la plus récente qui a fonctionné pour moi (1.0.6 et 1.0.7 génèrent l'erreur)
Patrick
Pareil, j'étais en 1.0.7 et ça ne marcherait pas. 1.0.3 fonctionne. Je n'ai rien essayé de plus élevé car je viens de perdre la dernière heure de ma vie avec ce problème et je ne m'occupe plus de ça maintenant ça marche!
Philip Stratford
9

Dans mon cas, j'ai eu un problème dans Jenkins quand il a essayé de le déployer dans Octopus avec l'erreur suivante:

MSBUILD : OctoPack error OCT-1676060969: Failed to build the path for '\bin\roslyn\csc.exe' relative to 'T:\workspace\machine.engine\Machine.engine.Test': Invalid URI: The format of the URI could not be determined.. See the inner exception for more details. [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969: System.Exception: Failed to build the path for '\bin\roslyn\csc.exe' relative to 'T:\workspace\machine.engine\Machine.engine.Test': Invalid URI: The format of the URI could not be determined.. See the inner exception for more details. ---> System.UriFormatException: Invalid URI: The format of the URI could not be determined. [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind) [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at System.Uri..ctor(String uriString) [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.Util.OctopusPhysicalFileSystem.GetPathRelativeTo(String fullPath, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\Util\OctopusPhysicalFileSystem.cs:line 211 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    --- End of inner exception stack trace --- [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.Util.OctopusPhysicalFileSystem.GetPathRelativeTo(String fullPath, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\Util\OctopusPhysicalFileSystem.cs:line 224 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.CreateOctoPackPackage.AddFiles(XContainer nuSpec, IEnumerable`1 sourceFiles, String sourceBaseDirectory, String targetDirectory, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 443 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.CreateOctoPackPackage.Execute() in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 190 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
Done Building Project "T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj" (default targets) -- FAILED

Cause

Après avoir passé quelque temps, j'utilisais un composant développé en interne qui utilisait Microsoft.Net.Compilers. La raison pour laquelle le composant interne utilisait Microsoft.Net.Compilersétait de résoudre ce problème ( C #: jeter la compilation d'expressions non valides ) et a été résolu de cette façon ( Comment utiliser C # 7 avec Visual Studio 2015? ). Ce résultat, lorsque j'ai installé le composant sur le programme principal, l' Microsoft.Net.Compilersajout s'ajoute automatiquement.

Solution

Mon travail a consisté à désinstaller le suivi de notre composant interne par (suite à la réponse @malikKhalil)

PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Uninstall-package Microsoft.Net.Compilers

Et choisi le compilateur C # 7 dans Jenkins au lieu de C # 6 et reconstruire, c'est pour s'assurer que tout fonctionne et se construit correctement.

Enfin, dans mon programme principal, j'ai essayé de mettre à jour mon composant interne. Et tout à reconstruire. Il a construit sans aucun problème ni problème.

maytham-ɯɐɥʇʎɐɯ
la source
8

Dans mon cas, je devais simplement aller dans le répertoire bin dans Visual Studio Solution Explorer (projet d'application Web) et inclure directement le projet roslyn. En cliquant avec le bouton droit sur le dossier et en sélectionnant Inclure dans le projet. Et archivez à nouveau la solution pour déclencher le processus de génération.

Le dossier roslyn n'était pas inclus par défaut.

Martijn van Halen
la source
8

J'avais également le même problème lors de l'exécution du projet. Voici les étapes que j'ai suivies.

  1. Clic droit dans la solution
  2. sélectionnez Clean solution
  3. Après le nettoyage réussi, construisez à nouveau votre projet
  4. Réexécutez le projet

Cette fois, je n'ai pas vu la même erreur. Cela fonctionne comme prévu.

Narendra
la source
Des collègues ont signalé que la mise à jour du package NuGet à partir de la console fonctionne, mais cela fonctionne également sans exécuter de commande. Ma réponse choisie.
tsemer
7

La mise Microsoft.CodeDom.Providers.DotNetCompilerPlatformà niveau de 1.0.0 vers 1.0.1 a corrigé cela pour moi.

Ben
la source
6

Ouvrez le fichier de projet et supprimez toutes les références avec Import Project = ".. \ packages \ Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0 ....

Ouvrez web.config et supprimez tous les attributs des compilateurs system.codedom

user6326076
la source
6

Comme nous l' avons noté /programming/32780315#34391473 , la solution rapide est d'utiliser le gestionnaire de paquets, Tools> Nuget Package Manager> Package Manager Console, pour exécuter

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Packet Manager Console - comment ouvrir

Mais une solution alternative (qui recrée automatiquement et silencieusement vos packages s'ils sont manquants) consiste à supprimer un attribut du Web.configfichier de votre projet .
(se Web.configtrouve dans le même répertoire que votre .csprojfichier.)

Ouvrez le Web.configfichier dans un éditeur de texte (ou dans Visual Studio).
- Dans la balise configuration> system.codedom> compilers> compiler language="c#;cs;csharp", supprimer complètement l' typeattribut.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!-- ... -->
  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs"
        type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.5.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.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+"/>
    </compilers>
  </system.codedom>
</configuration>

En bref, supprimez la ligne commençant par type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.

(Vraisemblablement, le même correctif fonctionne pour Visual Basic ainsi que pour Csharp, mais je ne l'ai pas essayé.)

Visual Studio s'occupe du reste. Pas plus Server Error in '/' Application.

Dans l'exemple de code que j'ai fourni dans le fichier zip ci-dessus, vous obtiendrez maintenant HTTP Error 403 lorsque vous appuyez sur Ctrl+ F5.

Erreur HTTP 403.14 - Interdit

Essayez de remplacer http://localhost:64195dans votre navigateur Web par http://localhost:64195/api/products.
L'API Web s'affiche désormais comme il se doit:

Une API web contenant des produits

Par provocation, j'ai essayé de supprimer tout le packagerépertoire de ma solution Visual Studio.
Il a été recréé automatiquement et silencieusement dès que je l'ai (re) construit.


Enfin, voici le code qui reproduit l'erreur: http://schulze.000webhostapp.com/vs/SrvrErr-reproduce.zip (à l'origine de https://github.com/aspnet/AspNetDocs/tree/master/aspnet / web-api / présentation / avancé / appeler-un-web-api-à-partir-d'un-net-client / exemple / serveur / ProductsApp )

erreur du serveur

Henke
la source
6

Dans mon cas, simplement en supprimant tout dans le dossier bin et en recompilant tout le travail pour moi.

Juan Martí
la source
2
Je pense que c'est plus simple et efficace. Habituellement, j'obtiens cette erreur après le clonage d'un projet d'un référentiel dans un nouveau computir.
Jonathan Ortega
Après avoir essayé cela, j'ai obtenu 403 Interdit d'IIS Express lors de l'exécution dans le débogueur. Le redémarrage de Visual Studio n'a pas aidé non plus, mais le redémarrage de Windows l'a été.
Florian Winter du
5

Si vous ajoutez ASPNETCOMPILER pour compiler vos vues Razor dans MVC, comme dans cette question StackOverflow , changez PhysicalPath pour placer où se trouve le package de nuget Roslyn (généralement pointé via la variable $ CscToolPath ):

<Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(CscToolPath)" />

Anrijs Vītoliņš
la source
5

Le problème avec les modèles VS2015 par défaut est que le compilateur n'est pas réellement copié dans le {outdir}_PublishedWebsites\tfr\bin\roslyn\répertoire, mais plutôt dans le {outdir}\roslyn\répertoire. Ceci est probablement différent de votre environnement local, car il AppHarborcrée des applications à l'aide d'un répertoire de sortie au lieu de créer la solution "sur place".

Pour le corriger, ajoutez ce qui suit vers la fin du .csprojfichier juste après le bloc xml<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">...</Target>

<PropertyGroup>
  <PostBuildEvent>
    if not exist "$(WebProjectOutputDir)\bin\Roslyn" md "$(WebProjectOutputDir)\bin\Roslyn"
    start /MIN xcopy /s /y /R "$(OutDir)roslyn\*.*" "$(WebProjectOutputDir)\bin\Roslyn"
  </PostBuildEvent>
</PropertyGroup>

Référence: https://support.appharbor.com/discussions/problems/78633-cant-build-aspnet-mvc-project-generated-from-vstudio-2015-enterprise

Korayem
la source
1
L'option / d copie uniquement les fichiers les plus récents (signifie "date"). Gardez à l'esprit le déploiement dans le cloud / azur où l'heure pourrait être derrière / devant l'heure locale.
Max
4

Dans mon cas, similaire à Basim, il y avait un package NuGet qui indiquait au compilateur que nous avions besoin de C # 6, ce que nous n'avions pas.

Nous avons dû supprimer le package NuGet Microsoft.CodeDom.Providers.DotNetCompilerPlatformqui a ensuite supprimé:

  1. <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.0" targetFramework="net452" /> à partir du fichier packages.config
  2. <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> </system.codedom>

Dans le system.codedomnœud, vous pouvez voir pourquoi il apportait roslyn:compilerOptions="/langversion:6

Mark C.
la source
1
Tout ce que j'avais à faire était de désinstaller le package NuGet "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" et cela l'a résolu pour moi (mon projet cible .NET 4.5.2).
BlueSky
1
Cela a fonctionné pour moi. Vous souhaiterez également supprimer Microsoft.Net.Compilers car il n'y a aucune raison de conserver cette dépendance supplémentaire.
Always Learning
4

Supprimez le dossier Bin dans votre explorateur de solutions et générez à nouveau la solution. Cela résoudrait le problème

user1903050
la source
Merci! Cela a également fonctionné pour moi. En plus de cela, j'ai mis à jour tous mes paquets de pépites
Andre Kraemer
4

J'ai eu le même problème lors de l'installation de mon application sur le serveur lorsque tout fonctionnait parfaitement sur localhost.

Aucune de ces solutions n'a fonctionné, j'ai toujours eu la même erreur:

Could not find a part of the path 'C:\inetpub\wwwroot\myApp\bin\roslyn\csc.exe'

J'ai fini par faire ça:

  • sur mon projet d'installation, clic droit, voir> système de fichiers
  • créer un bin/roslyndossier
  • sélectionnez ajouter> fichiers et ajoutez tous les fichiers de packages\Microsoft.Net.Compilers.1.3.2\tools

Cela a résolu mon problème.

Alexandre Hamon
la source
4

Redémarrez Windows.

C'est la seule solution qui a fonctionné pour moi après avoir essayé de reconstruire, supprimer le contenu binet reconstruire, redémarrer Visual Studio.

C'est encore un autre exemple de la gravité des outils de construction C # /. NET.

Je pense (après avoir lu beaucoup de réponses), la conclusion générale est que la cause et la solution de ce problème dépendent fortement de la configuration et du projet, donc si une réponse ne fonctionne pas, essayez simplement une autre. Essayez les solutions non intrusives / destructives, telles que le redémarrage de Visual Studio, le redémarrage, la reconstruction, etc., D'ABORD, avant de jouer avec les packages NuGet ou de réinstaller les outils de développement. Bonne chance!

(REMARQUE: l'utilisation de Visual Studio 2019 et du fichier de projet a été initialement créé dans Visual Studio 2015. Cela peut peut-être aider quelqu'un à enquêter sur le problème)

(EDIT: cela peut-il être dû au fait de ne pas redémarrer après avoir installé / modifié l'installation de Visual Studio ou mis à jour Visual Studio lorsque le programme d'installation vous invite à redémarrer?)

Florian Winter
la source
3

J'ai un projet Web sans fichier csproj et les solutions mentionnées ici n'ont pas fonctionné pour moi.

Changer le framework .NET cible, réinstaller les packages ( Update-Package -reinstall) puis construire le projet a fonctionné pour moi. Vous pouvez même modifier le framework cible après cette opération (assurez-vous de réinstaller les packages de nuget après).

Miroslav Adamec
la source
Il s'agit d'un "projet de site Web". J'ai utilisé cette commande pour réinstaller le seul package:update-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -reinstall
GarDavis