Reputation: 14249
I am trying to run an ASP.NET MVC (model-view-controller) project retrieved from TFS (Team Foundation Server) source control. I have added all assembly references and I am able to build and compile successfully without any error or warning.
But I get the following error in the browser:
Could not find a part of the path 'C:\B8akWorkspace\B8akProject\B8akSolution\B8AK.Portal\bin\roslyn\csc.exe'.
Here is a full screenshot of the error page.
After few days of research, I understood that Roslyn is a .NET compiler platform that offers advanced compiling features. However, I do not understand why my build is trying to find \bin\roslyn\csc.exe because I did not configure anything related to Roslyn. Nor did I intend to use Roslyn in my project.
Upvotes: 1343
Views: 866192
Reputation: 2786
Upvotes: 3
Reputation: 5787
As already noted in the currently highest voted answer, the quick fix is to use the package manager, Tools > Nuget Package Manager > Package Manager Console, to run
Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r
Here is code that reproduces the error:
https://user.it.uu.se/%7Ehesc0353/SrvrErr-reproduce.zip
(Originally from
https://github.com/aspnet/AspNetDocs/tree/master/aspnet/web-api/overview/advanced/calling-a-web-api-from-a-net-client/sample/server/ProductsApp)
Consider trying the example code provided in the zip file above.
If no changes are made, Ctrl+F5 will reproduce
the error.
An alternative solution is to remove an attribute from the project's
Web.config
file.
(Web.config
is in the same directory as the .csproj
file.)
This will automatically and silently recreate your packages if they
are missing.
Open the Web.config
file in a text editor or in Visual Studio.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings></appSettings>
...
<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=\"Web\" /optionInfer+"/>
</compilers>
</system.codedom>
</configuration>
In the tag configuration > system.codedom > compilers >
compiler language="c#;cs;csharp", completely remove
the type
attribute.
– In short, remove the line that starts with
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider,
.
1
Visual Studio will take care of the rest.
– No more Server Error in '/' Application
.
In the example provided above, hitting Ctrl+F5 will now result in an HTTP Error 403.
Try replacing http://localhost:64195
in your web browser with
http://localhost:64195/api/products
.
The web API now displays correctly:
As a provocation, I tried removing the whole package
directory from
the Visual Studio project.
It was automatically and silently recreated as soon as the project was
rebuilt.
1 Presumably, the same fix works for Visual Basic as well as for C#, but I haven't tried it.
Upvotes: 67
Reputation: 6925
NOTE: If you are not interested in using Roslyn, follow this answer to strip away Roslyn entirely
The Roslyn:
Your build is trying to find \bin\roslyn\csc.exe
because the following packages have been added to your project. Just review your packages.config
file, you can have both of them there
Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Microsoft.Net.Compilers
What is Roslyn and Who added them(packages) in the project : If you’re using .net Framework 4.5.2 to create projects using VS2015, you might have noticed that the project templates use Roslyn by default. Actually, Roslyn is one of open-source compilers for .NET languages from Microsoft.
Why should we delete Roslyn: If your project has Roslyn references and you are interested in deploy it on the server, you will get unwanted errors on the website as many hosting providers still have not upgraded their servers and hence do not support Roslyn. To resolve this issue, you will need to remove the Roslyn compiler from the project template.
How to remove it:
1. Remove NuGet packages, use the following commands from Nuget Package Console
PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Uninstall-package Microsoft.Net.Compilers
2.
After you do this, your web.config
file should be auto-updated. In case it is not, look for the below code in web.config
file and if it is found, delete this piece of 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>
Upvotes: 214
Reputation: 659
I have multiple .NET Framework 4.8 ASP.Net web apps in the same solution. They are still using packages.config
and are using Microsoft.CodeDom.Providers.DotNetCompilerPlatform
version 4.1.0
.
Consistently and reproducibly I get this problem of the roslyn
folder not being created in the bin
folder when building in Visual Studio 2022. To reproduce:
packages
folder and all the obj
and bin
foldersMicrosoft.CodeDom.Providers.DotNetCompilerPlatform
exists in packages
folder).Every single time the bin
folders of the web apps do not contain the roslyn
folder. I have to do multiple cleans and builds and/or rebuilds and eventually the roslyn
folder shows up and the web apps work. I haven't been able to identify a pattern as to when a build will finally copy the roslyn
folder.
I have updated the .csproj
files of the web apps to include
<PropertyGroup>
<RoslynCopyToOutDir Condition="$(RoslynCopyToOutDir) == ''">true</RoslynCopyToOutDir>
<RoslynToolPath Condition="'$(RoslynToolPath)' == ''">..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.4.1.0\tools\Roslyn-4.1.0</RoslynToolPath>
</PropertyGroup>
Now following the same reproduction steps above the roslyn
folder is copied to the bin
folder the very first time the solution is built.
I copied this from the Microsoft.CodeDom.Providers.DotNetCompilerPlatform.targets
file located in \packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.4.1.0\build\net472
.
Since this now works consistently I am assuming something is going wrong with the import of the targets configured in the .csproj
files. They do contain the below import statement, so I am not sure what is interfering with the imports intermittently.
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.4.1.0\build\net472\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.4.1.0\build\net472\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.targets'))" />
</Target>
<Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.4.1.0\build\net472\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.targets" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.4.1.0\build\net472\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.targets')" />
Upvotes: 0
Reputation: 177
I had a project running in VS2019 and then i open(in VS2019) another project for the first time and i got the above issue. what I did as follow:
Only point no. 2 was not working for me.
Upvotes: 2
Reputation: 7087
The problem with the default VS2015 templates is that the compiler isn't actually copied to the tfr\bin\roslyn\
directory, but rather the {outdir}\roslyn\
directory
Add this code in your .csproj file:
<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>
Upvotes: 598
Reputation: 373
On my case, i Noticed that the "build" folder was not present in "packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0" path. And that was the reason why the roslyn folder was not beeing created.
So the solution for me was:
And there you go. None of the solution above worked for me . Hope this helps anyone
Upvotes: 2
Reputation: 19
I was also facing same issue got resolve by running the below command in nuget console
Install-Package Microsoft.Net.Compilers -Version 3.3.1
Upvotes: -1
Reputation: 81
For those struggling through this when compiling on the build server (TFS or Bamboo), I was able to solve this by removing the "clean" option from the "/t:" msbuild options.
Upvotes: 4
Reputation: 23
Install nudget package: Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix https://www.nuget.org/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix/1.0.0
Upvotes: -1
Reputation: 348
I tried multiple top answers until the below steps worked (ASP.NET project targeting .NET Framework 4.6.2, Visual Studio 2019 on a system with crazy restrictive group policies, March 2021).
I needed to:
run VS as Admin
in package manager console run
Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -v 2.0.1
Clean & Rebuild Solution
Without running VS as Admin, group policies blocked ps1 scripts that Update-Package needed to run.
PS. Before this worked, I tried numerous other answers (and ran git reset --hard after they failed). I do not know if any of them contributed to this eventually working. I tried:
Upvotes: 4
Reputation: 7791
In my case, before trying any of the other solutions, I switched to a "Release" configuration, rebuilt (the folder got created) and then switched back to "Debug", while the folder remained intact.
This was a checkout from source control of an older solution and apparently the original (automatic) package restore and building the project didn't create that folder in the bin directory.
Note that at time of writing this, the blamed component has reached v.2.
Upvotes: 18
Reputation: 1169
Too late for an answer but still posting incase it helps anyone.
Following the below steps fixed the error for me:
Upvotes: 72
Reputation: 594
Upgrading Microsoft.CodeDom.Providers.DotNetCompilerPlatform
from 1.0.0 to 1.0.1 fixed this for me.
Upvotes: 9
Reputation: 1412
I was also having same issue while running the project. Here are the steps that I followed.
This time I didn't see the same error. This works as expected.
Upvotes: 34
Reputation: 309
In my case by just Deleting everything inside the bin folder and recompiling did all the work for me.
Upvotes: 8
Reputation: 20454
TL; DR
run this in the Package Manager Console:
Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r
More information
This problem is not related to Visual Studio itself, so answers suggesting adding build steps to copy files over are rather a workaround. Same with adding compiler binaries manually to the project.
The Roslyn compiler comes from a NuGet package and there is/was a bug in some versions of that package (I don't know exactly which ones). The solution is to reinstall/upgrade that package to a bug-free version. Originally before I wrote the answer back in 2015 I fixed it by installing following packages at specific versions:
Then I looked into .csproj and made sure that the paths to packages are correct (in my case ..\..\packages\*.*) inside tags <ImportProject>
on top and in <Target>
with name "EnsureNuGetPackageBuildImports" on the bottom. This is on MVC 5 and .NET Framework 4.5.2.
Upvotes: 2001
Reputation: 373
The following solved this issue for me:
Updating to the latest version of Visual Studio 2017 (using the installer app)
Clean and rebuild the solution
Upvotes: 3
Reputation: 13298
For VS 2019 remove the following node completely:
<system.codedom>
</system.codedom>
Upvotes: 20
Reputation: 2185
None of the other answers worked for me. After doing a folder compare before/after vs my expected committed files, i discovered that GIT was ignoring a required folder. If you are tracking the compiler in a repository, make sure the BUILD folder is tracked. If it's not, the compiler won't ever be built and will throw this exact error after publish. I added this line to my .gitignore file:
!**/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1/build/
and now it's deploying to other computers properly.
Upvotes: 0
Reputation: 2460
I had this issue on the server I was deploying to, and determined that I did not need
Microsoft.CodeDom.Providers.DotNetCompilerPlatform
So, I uninstalled it via nuget, and removed the reference in the web config. No more issues.
I originally tried to added target node to the .proj file as mentioned in some of the other answers, but that just lead to another error where the msbuild
could not copy the pagefile.sys
which seemed from what I read to be a bug in the nuget package.
Upvotes: 3
Reputation: 5329
Reboot Windows.
This is the only solution that worked for me after trying rebuild, delete contents of bin
and rebuild, restart Visual Studio.
It's yet another example of how terrible C#/.NET build tools are.
I think (after reading many of the answers), the overall conclusion is that the cause and solution of this problem heavily depends on the setup and project, so if one answer does not work, just try another. Try non-intrusive/destructive solutions, such as restarting Visual Studio, rebooting, rebuilding, etc., FIRST, before messing with NuGet packages or reinstalling development tools. Good luck!
(NOTE: Using Visual Studio 2019, and project file was originally created in Visual Studio 2015. Maybe this helps someone investigate the issue)
(EDIT: Could this be caused by not rebooting after installing/modifying the Visual Studio installation or updating Visual Studio when the installer prompts to reboot?)
Upvotes: 4
Reputation: 31
In my situation, our team don't want to keep 'packages' folder, so we put all dlls in other directory like 'sharedlib'.
I used build event to solve this problem.
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
Upvotes: 0
Reputation: 41
Other than deleting the Bin diretory from all projects inside the solution, delete the obj folders too.
In the main solution diretory remove the folder .vs
Worked for me when trying to bring an already done project into a blank solution created on git.
Upvotes: 4
Reputation: 18207
As noted in an issue in the Roslyn project on GitHub, a solution (that worked for me) is to simply unload and reload the project in Visual Studio.
The "bin\roslyn" folder wasn't created on build or rebuild until I reloaded the project.
Upvotes: 54
Reputation: 1890
A lot of these answers are referring to the Nuget packages and/or cleaning and reloading your project.
If you have WCF service references and invalid endpoints, you can also get this error message. Make sure your endpoints are correct and update the service configuration with the correct endpoint in the .config and when you configure the service reference from the GUI.
Upvotes: 1
Reputation: 33437
In my case I have had issue in Jenkins when it tried to deploying it in Octopus with following error:
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
After spending some time, I was using an internal developed component that was using Microsoft.Net.Compilers
. The reason the internal component was using Microsoft.Net.Compilers
was to overcome this issue (C#: throw invalid expression compilation) and was solved this way (How to use C# 7 with Visual Studio 2015?). This result in, when I installed the component on the main program, the Microsoft.Net.Compilers
get added it selves automatically.
Solution
My work around was, uninstall following from our internal component by (following @malikKhalil answer)
PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Uninstall-package Microsoft.Net.Compilers
And chose C# 7 compiler in Jenkins instead of C# 6 and rebuild, this is to ensure everything is working and building correctly.
Than finally in my main program I tried to update my internal component. And everything than build again. It has built without any problems or issues.
Upvotes: 11
Reputation: 2773
The answer for this is different for Website project and Web application Project. The underlying issue is same that NuGet package is behaving differently on different machine. It may be rights issue or some execution policy which stops it from copying to Bin folder As you know Roslyn is new compiler. you should have it in Bin folder for these Projects Go to your website NuGet Packages check this Folder Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0 \code\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0 Do you see it ? Can you see code\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\tools\RoslynLatest in it Now as part of compiling this Folder should get copied to your website under bin like this. \code\WebSite1\Bin\Roslyn some how that is not happening for you . Try running Visual studio as Admin . Copy Roslyn folder manually. Try uninstall and install of NuGet Package. Remember this package compile your folder and if its not there you cannot compile anything and so you cannot add anything too. Try copying this package to offline version tools -> options-> nuget package Manager->Package source-> Microsoft Visual Studio Offline Packages C:\Program Files (x86)\Microsoft SDKs\NuGetPackages
Upvotes: -1