Impossible de trouver une partie du chemin ... bin\roslyn\csc.exe
J'essaie d'exécuter le projet Asp.net MVC extrait du contrôle de source TFS. J'ai ajouté toutes les références à 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.
Après quelques jours de recherche, j'ai compris que Roslyn est une plate-forme de compilateur .Net offrant des fonctionnalités de compilation avancées. Cependant, je ne comprends pas pourquoi ma construction essaie de trouver\bin\roslyn\csc.exe car je n’ai rien configuré en rapport avec Roslyn, ni j’ai l’intention d’utiliser Roslyn dans mon projet.
Le problème avec les modèles VS2015 par défaut est que le compilateur n'est pas copié dans le répertoire tfr\bin\roslyn \, mais plutôt dans le répertoire {
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>
Dans mon cas, la solution consistait à réinstaller/mettre à niveau les paquets Nuget:
- Microsoft.Net.Compilers 1.1.1
- Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.1
Ensuite, j'ai examiné .csproj et vérifié que les chemins d'accès aux packages sont corrects (dans mon cas,\..\packages\*. *) Dans les balises <ImportProject> en haut et dans <Target> avec le nom "EnsureNuGetPackageBuildImports" en bas. C'est sur MVC 5 et .NET Framework 4.5.2.
Réponse courte - lancez-le dans la console du gestionnaire de packages:
Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r
Votre version essaie de trouver \bin\roslyn\csc.exe car des packages suivants ont été ajoutés à votre projet. Il vous suffit de passer en revue votre fichier packages.config, vous pouvez les avoir tous les deux à cet emplacement.
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 en utilisant VS2015, vous avez peut-être remarqué que les modèles de projet utilisent Roslyn par défaut. En fait, Roslyn fait partie de open-source compilateurs pour les langages .NET de Microsoft.
Pourquoi devrions-nous supprimer Roslyn: Si votre projet contient des références Roslyn et que vous êtes intéressé à déployer Si vous n’avez pas de serveur, vous obtiendrez autant d’erreurs indésirables sur le site Web les fournisseurs d’hébergement n’ont toujours pas mis leurs serveurs à niveau et par conséquent ne le font pas pas pris 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é par l'utilisation de Roslyn,suivez les étapes ci-dessous pour le supprimer
1. Supprimer les packages Nuget, utilisez les commandes suivantes de la console de packages Nuget
PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Uninstall-package Microsoft.Net.Compilers
2. Ensuite, votre fichier web.config doit être mis à jour automatiquement. Dans le cas contraire, recherchez le code ci-dessous dans le fichier web.config et, le cas échéant, 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=\"Web\" /optionInfer+"></compiler>
</compilers>
</system.codedom>
Voici une façon plus MSBuild de le faire.
<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). L'application semble fonctionner, cependant.
Un nettoyage et une reconstruction ont fonctionné pour moi!
Edit: / Les commentateurs disent que l'étape de nettoyage n'est pas nécessaire. Vous pouvez simplement reconstruire.
Vous devez installer Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix, A été spécialement créé pour cette erreur
Ainsi, la réponse de Rob Cannon a essentiellement fonctionné pour moi, mais je devais modifier une poignée d'options. Plus précisément, je devais supprimer la condition sur la cible, ainsi que modifier l'attribut Include, car $ CscToolPath était vide lors de la génération du projet 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>
Après avoir essayé tous les correctifs sans cigare, je l'ai corrigé en mettant à jour ce paquet Nuget dans Visual Studios:
Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Mine était de 1.0.0 à 2.0.0 pour référence (l'erreur ne s'affiche plus)
Il s'agit d'un problème connu avec Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.6. Le déclassement à 1.0.5 a corrigé cela pour moi.
Par 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
Le passage à la version 1.0.3 a résolu ce problème pour moi.
Dans mon cas, je devais simplement accéder au répertoire bin de Visual Studio Solution Explorer (projet d'application Web) et inclure le projet roslyn directement. En faisant un clic droit sur le dossier et en sélectionnant Inclure dans le projet. Et vérifiez à nouveau dans la solution pour déclencher le processus de construction.
Le dossier roslyn n'était pas inclus par défaut.
Mettre à jour les packages de nuget a fonctionné pour moi Cliquez avec le bouton droit de la souris sur la solution> Gérer les packages de NuGet pour la solution Et mettez à jour tous les packages, notamment: Microsoft.Net.Compilers Et Microsoft .CodeDom.Providers.DotNetCompilerPlatform
J'ai suivi ces étapes et cela a fonctionné parfaitement
- Supprimer tous les dossiers bin et obj
- Solution propre et reconstruction
- Exécuter cette commande dans Powershell
Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r
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é un certain temps, j'utilisais un composant développé en interne qui utilisait Microsoft.Net.Compilers. Le composant interne utilisait Microsoft.Net.Compilers pour résoudre ce problème ( C #: lancer une compilation d'expressions non valide ) et a été résolu de cette manière ( Comment utiliser c # 7 avec Visual Studio 2015? ). Cela a pour résultat que, lorsque j'ai installé le programme compétent dans le programme principal, le Microsoft.Net.Compilers est ajouté automatiquement.
Solution
Mon travail était, désinstallez suite à notre composant interne par (suite @malikKhalil réponse)
PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Uninstall-package Microsoft.Net.Compilers
Et choisir le compilateur C # 7 dans Jenkins au lieu de C # 6 et le 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 ce que construire à nouveau. Il a construit sans aucun problème ou problèmes.
Ouvrez le fichier de projet et remove all references avec Import Project = "..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0 ....
Ouvrez web.config et remove tous les attributs des compilateurs system.codedom
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 {outdir}_PublishedWebsites\tfr\bin\roslyn\, mais plutôt dans le répertoire {outdir}\roslyn\. Ceci est probablement différent de votre environnement local car AppHarbor construit des applications en utilisant un répertoire de sortie au lieu de créer la solution "sur place".
Pour résoudre ce problème, ajoutez ce qui suit vers la fin du fichier .csproj 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>
Si vous ajoutiez ASPNETCOMPILER pour compiler vos vues Razor dans MVC, comme dans cette question StackOverflow , changez PhysicalPath pour indiquer l'emplacement où se trouve le paquet de nuget Roslyn (généralement indiqué via la variable $ CscToolPath):
<Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(CscToolPath)" />
La mise à niveau de Microsoft.CodeDom.Providers.DotNetCompilerPlatform de 1.0.0 à 1.0.1 a résolu ce problème.
Dans mon cas, semblable à Basim, il y avait un paquet NuGet qui disait au compilateur que nous avions besoin de C # 6, ce que nous n'avions pas fait.
Nous avons dû supprimer le package NuGet Microsoft.CodeDom.Providers.DotNetCompilerPlatform qui a ensuite supprimé:
<package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.0" targetFramework="net452" />à partir du fichier packages.config<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=\"Web\" /optionInfer+" /> </compilers> </system.codedom>
Dans le nœud system.codedom, vous pouvez voir pourquoi il introduisait roslyn: compilerOptions="/langversion:6
- Solution propre
- Reconstruire la solution, ces deux étapes ont fonctionné pour moi.
J'ai un projet Web sans fichier csproj et les solutions mentionnées ici ne fonctionnaient pas 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 changer le framework cible après cette opération (assurez-vous de réinstaller les paquets Nuget après).
Redémarrez Windows.
C’est la seule solution qui a fonctionné pour moi après avoir essayé de reconstruire, supprimer le contenu de bin et reconstruire, redémarrer Visual Studio.
C’est encore un autre exemple de la gravité des outils de compilation 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 énormément de la configuration et du projet, donc si une réponse ne fonctionne pas, essayez-en une autre. Essayez non solutions intrusives/destructives, telles que le redémarrage de Visual Studio, le redémarrage, la reconstruction, etc., en premier, avant de jouer avec les packages NuGet ou de réinstaller les outils de développement. Bonne chance!
(REMARQUE: à l'aide de Visual Studio 2019, le fichier de projet a été créé à l'origine dans Visual Studio 2015. Cela peut peut-être aider quelqu'un à enquêter sur le problème.)
(EDIT: cela pourrait-il être causé par le fait que vous n'avez pas redémarré après l'installation/la modification de l'installation de Visual Studio ou la mise à jour de Visual Studio lorsque le programme d'installation vous invite à redémarrer?)
J'ai eu le même problème lors de l'installation de mon application sur le serveur quand 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 ceci:
- sur mon projet d'installation, clic droit, voir> système de fichiers
- créer un dossier
bin/roslyn - 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.
J'avais aussi le même problème lors de l'exécution du projet. voici les étapes que j'ai suivies.
- Clic droit dans la solution
- sélectionnez Solution propre
- Après le nettoyage réussi, construisez à nouveau votre projet
Exécutez le projet à nouveau
Cette fois, je ne vois pas la même erreur. Cela fonctionne comme prévu
Ajouter PropertyGroup à votre fichier .csproj
<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>
Supprimez le dossier Bin dans votre solution Explorer et générez à nouveau la solution. Cela résoudrait le problème
J'ai rencontré ce problème après la mise à jour de paquets via NuGet. Une reconstruction (au lieu d'une construction normale) a fonctionné pour moi.
ma solution utilise Nuget pour mettre à jour les éléments ci-dessous vers la dernière version: - Microsoft.Net.Compilers - Microsoft.CodeDom.Providers.DotNetCompilerPlatform Ensuite, reconstruisez le projet. Étant donné que mon projet est un site Web, aucun fichier * .csproj .
L'erreur corrigée après la mise à jour des deux éléments ci-dessus vers la dernière version . Je suis dans VS2015 et Windows7 SP1
FYI ...
À partir du 31/08/2017, la mise à niveau vers Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.7 fonctionne.
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 génération ou de la reconstruction tant que je n'ai pas rechargé le projet.
J'ai eu le même problème après la mise à jour DotNetCompilerPlatform . Résolu en redémarrant Visual Studio> Nettoyer le projet> Construire le projet.
J'ai eu cette erreur pour Microsoft.CodeDom.Providers.DotNetCompilerPlatform1.06 mais aussi avec 1.0.7 qui a fonctionné pour @PrisonerZERO. Cependant, lorsque Microsoft a publié le 1.0.8 2017-10-18, il a finalement repris son travail et je n'ai pas eu à déclasser.
https://www.nuget.org/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform/
Outre la suppression du répertoire Bin de tous les projets de la solution, supprimez également les dossiers obj.
Dans le répertoire principal de la solution, supprimez le dossier .vs
Travaillé pour moi lorsque j'essayais d'intégrer un projet déjà réalisé dans une solution vierge créée sur git.
J'ai rencontré cette erreur sur un serveur de génération Jenkins exécutant MSBuild, qui exporte les fichiers de construction dans un dossier distinct (_PublishedWebsites). Exactement la même chose - le dossier roslyn n'était pas dans le répertoire bin et tous les fichiers roslyn ont été regroupés avec les fichiers bin.
La réponse de @ igor-semin était la seule chose qui fonctionnait pour moi (comme j'utilise les fonctionnalités du langage C # 6, je ne peux pas simplement désinstaller les paquets de nuget comme indiqué dans les autres réponses), mais comme je lance aussi CodeAnalysis , Je recevais une autre erreur sur mon serveur cible de déploiement:
Une tentative de remplacement d'un mappage existant a été détectée pour le type Microsoft.CodeAnalysis.ICompilationUnitSyntax avec le nom "", actuellement mappé vers le type Microsoft.CodeAnalysis.CSharp.Syntax.CompilationUnitSyntax, pour saisir Microsoft.CodeAnalysis.CSharp.Syntax.CompilationUnitSyntax
La raison en est que, lorsque les fichiers roslyn sont vidés dans le répertoire bin principal, lorsque vous exécutez xcopy pour les recréer dans le dossier imbriqué roslyn, vous avez maintenant 2 copies de ces fichiers en cours de compilation et il y a un conflit entre eux. . Après beaucoup de frustration, j'ai opté pour une solution de 'piratage' - une tâche post-construction supplémentaire pour supprimer ces fichiers du répertoire bin, éliminant ainsi le conflit.
Le .csproj de mes projets incriminés ressemble maintenant à:
................... plus ici ......................
<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>
<Target Name="DeleteDuplicateAnalysisFiles" AfterTargets="AfterBuild">
<!-- Jenkins now has copies of the following files in both the bin directory and the 'bin\rosyln' directory. Delete from bin. -->
<ItemGroup>
<FilesToDelete Include="$(WebProjectOutputDir)\bin\Microsoft.CodeAnalysis*.dll" />
</ItemGroup>
<Delete Files="@(FilesToDelete)" />
</Target>
................... plus ici ......................
Un grand nombre de ces réponses font référence aux packages Nuget et/ou au nettoyage et au rechargement de votre projet.
Si vous avez des références de service WCF et des terminaux non valides, vous pouvez également obtenir ce message d'erreur. Assurez-vous que vos noeuds finaux sont corrects et mettez à jour la configuration du service avec le bon noeud final dans le fichier .config et lorsque vous configurez la référence de service à partir de l'interface graphique.
Dans mon cas, notre équipe ne veut pas conserver le dossier 'packages', nous avons donc placé toutes les dll dans un autre répertoire comme 'sharedlib'.
J'ai utilisé build event pour résoudre ce problème.
if "$(ConfigurationName)" == "Release" (
goto :release
) else (
goto:exit
)
:release
if not exist $(TargetDir)\roslyn mkdir $(TargetDir)\roslyn
copy /Y "$(ProjectDir)..\..\Shared Lib\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\tools\Roslyn45\*" "$(TargetDir)\roslyn"
goto :exit
:exit
Cela peut être fait de la manière simple suivante:
- Créez un nouveau projet de type similaire n'importe où dans votre système. Construisez-le et copiez le dossier roslyn dans votre répertoire bin.
La réponse à cette question est différente pour les projets Web et les applications Web Projet . Le problème sous-jacent est identique à celui de Le package NuGet se comporte différemment sur différentes machines. Il peut s’agir d’un problème de droits ou d’une politique d’exécution qui l’empêche de copier dans le dossier Bin Comme vous le savez, Roslyn est un nouveau compilateur. vous devriez l'avoir dans le dossier Bin pour ces projets aller sur votre site web NuGet Packages vérifiez ce dossier Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0 \code\packages\Microsoft.CodeDom .Providers.DotNetCompilerPlatform.2.0.0 Le voyez-vous? Pouvez-vous voir le code\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\tools\RoslynLatest dedans Maintenant, dans le cadre de la compilation de ce dossier devrait être copié sur votre site Web sous bin comme ceci .\code\WebSite1\Bin\Roslyn Voici comment cela ne se produit pas pour vous . Essayez d’exécuter Visual Studio en tant qu’administrateur . Copiez le dossier Roslyn manuellement . Essayez de désinstaller et d'installer NuGet Package . N'oubliez pas que ce paquet compile votre dossier et que s'il ne se trouve pas là, vous ne pouvez rien compiler et vous ne pouvez donc rien ajouter trop . Essayez de copier ce paquet dans une version hors connexiontools -> options-> paquet de nuget > Packages hors ligne Microsoft Visual Studio C:\Program Files (x86)\SDK Microsoft\NuGetPackages
J'ai eu cette erreur après avoir renommé une solution et certains projets inclus, et joué avec la suppression de paquets de nuget. J'ai comparé le nouveau projet avec le dernier projet en cours et constaté que les lignes suivantes étaient manquantes et devaient être rajoutées:
<Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
<Import Project="..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" />
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
Cela a résolu le problème pour moi.
J'ai rencontré ce problème avec le pipeline de publication (qui produit un répertoire _PublishedWebsites) et je l'ai utilisé comme cible dans le projet:
<Target Name="CopyRoslynCompilerFilesToPublishedWebsitesDirectory" AfterTargets="AfterBuild" Condition="Exists('$(OutDir)\_PublishedWebsites\$(TargetName)')">
<Copy SourceFiles="@(RoslyCompilerFiles)" DestinationFolder="$(OutDir)\_PublishedWebsites\$(TargetName)\bin\roslyn" ContinueOnError="true" SkipUnchangedFiles="true" />
</Target>
L'inconvénient est qu'il y aura deux copies des fichiers Roslyn dans la sortie.
- Faites un clic droit sur votre projet et sélectionnez Gérer les paquets de pépites
- Trouvez "Microsoft.CodeDom.Providers.DotNetCompilerPlatform"
- Il suffit de mettre à jour vers une version plus ancienne ou plus récente (peu importe), puis de revenir à votre version d'origine.
Cela réinstalle toutes les dépendances et les fichiers du paquet (comme csc.exe)
J'ai dû modifier les fichiers de projet WebAPI et MVC pour ne pas générer de vues:
<MvcBuildViews>false</MvcBuildViews>
Cela a résolu mon erreur de serveur TFS 2015 Build avec roslyn. Vous ne savez toujours pas pourquoi csc.exe a été copié dans\bin\csc.exe, le processus de publication recherchait toujours\bin\Roslyn\csc.exe ... impossible de trouver la transformation à l'origine de cet écart.
Dans mon cas, je rencontrais ce problème lorsque j’exécutais simultanément deux visual studio IDE. La solution consistait donc à nettoyer le projet et à fermer l'autre instance.
Dans mon cas, tout en supprimant tout dans le dossier bin et en recompilant a fait tout le travail pour moi.
Bonne chance à tous ceux qui ont ce problème.