Csc compiler error after upgrading to VS2015 Update 3 (order of import statements)
See original GitHub issueDescription
After upgrading to VS2015 Update 3 I noticed that some WebAPI projects targeting framework v4.6.1 were coming up with the following error:
Build FAILED.
"D:\Code\my-project\src\WebApiProject.Tests.Unit\WebApiProject.Tests.Unit.csproj" (Build target) (1) ->
"D:\Code\my-project\src\WebApiProject\WebApiProject.csproj" (default target) (5) ->
(CoreCompile target) ->
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.CSharp.Core.targets(76,11): error MSB4064: The "ChecksumAlgorithm" paramete
r is not supported by the "Csc" task. Verify the parameter exists on the task, and it is a settable public instance property. [
D:\Code\my-project\src\WebApiProject\WebApiProject.csproj]
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.CSharp.Core.targets(67,5): error MSB4063: The "Csc" task could not be initi
alized with its input parameters. [D:\Code\my-project\src\WebApiProject\WebApiProject.csproj]
Repro steps
Paket orders the import statements like so;
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Choose>
<When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And ($(TargetFrameworkVersion) == 'v4.6.1' Or $(TargetFrameworkVersion) == 'v4.6.2')">
<PropertyGroup>
<__paket__Microsoft_Net_Compilers_props>Microsoft.Net.Compilers</__paket__Microsoft_Net_Compilers_props>
</PropertyGroup>
</When>
</Choose>
<Import Project="..\packages\Microsoft.Net.Compilers\build\$(__paket__Microsoft_Net_Compilers_props).props" Condition="Exists('..\packages\Microsoft.Net.Compilers\build\$(__paket__Microsoft_Net_Compilers_props).props')" Label="Paket" />
<Choose>
<When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And ($(TargetFrameworkVersion) == 'v4.6.1' Or $(TargetFrameworkVersion) == 'v4.6.2')">
<PropertyGroup>
<__paket__Microsoft_CodeDom_Providers_DotNetCompilerPlatform_props>Microsoft.CodeDom.Providers.DotNetCompilerPlatform</__paket__Microsoft_CodeDom_Providers_DotNetCompilerPlatform_props>
</PropertyGroup>
</When>
</Choose>
<Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform\build\$(__paket__Microsoft_CodeDom_Providers_DotNetCompilerPlatform_props).props" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform\build\$(__paket__Microsoft_CodeDom_Providers_DotNetCompilerPlatform_props).props')" Label="Paket" />
Ordering them instead like this fixed the issue;
<Choose>
<When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And ($(TargetFrameworkVersion) == 'v4.6.1' Or $(TargetFrameworkVersion) == 'v4.6.2')">
<PropertyGroup>
<__paket__Microsoft_Net_Compilers_props>Microsoft.Net.Compilers</__paket__Microsoft_Net_Compilers_props>
</PropertyGroup>
</When>
</Choose>
<Import Project="..\packages\Microsoft.Net.Compilers\build\$(__paket__Microsoft_Net_Compilers_props).props" Condition="Exists('..\packages\Microsoft.Net.Compilers\build\$(__paket__Microsoft_Net_Compilers_props).props')" Label="Paket" />
<Choose>
<When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And ($(TargetFrameworkVersion) == 'v4.6.1' Or $(TargetFrameworkVersion) == 'v4.6.2')">
<PropertyGroup>
<__paket__Microsoft_CodeDom_Providers_DotNetCompilerPlatform_props>Microsoft.CodeDom.Providers.DotNetCompilerPlatform</__paket__Microsoft_CodeDom_Providers_DotNetCompilerPlatform_props>
</PropertyGroup>
</When>
</Choose>
<Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform\build\$(__paket__Microsoft_CodeDom_Providers_DotNetCompilerPlatform_props).props" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform\build\$(__paket__Microsoft_CodeDom_Providers_DotNetCompilerPlatform_props).props')" Label="Paket" />
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
Expected behavior
Microsoft.CSharp.targets
is below that of the Net.Compilers and CodeDom.Providers prop imports.
Actual behavior
Microsoft.CSharp.targets
is above that of the Net.Compilers and CodeDom.Providers prop imports.
Known workarounds
Move them manually and correct after each Paket update.
Related information
Paket version 3.4.0.0
Issue Analytics
- State:
- Created 7 years ago
- Reactions:4
- Comments:22 (11 by maintainers)
Top Results From Across the Web
Visual Studio 2015 Build errors - The "Csc" task could not ...
I have encountered the same issue. In my case, I got a duplicate Microsoft.CodeDom.Providers.DotNetCompilerPlatform and Microsoft.Net.
Read more >Error - This update requires Visual Studio 2015 Update 3 to ...
Resolves an error that occurs because a required Cumulative Update (KB3165756) to Visual Studio 2015 is missing.
Read more >Could not find a part of the path ... bin\roslyn\csc.exe
The error above appears when I tried to view a cshtml in browser. The error fixed after the two items above updated to...
Read more >Microsoft.CppClean.targets(76,5) - MSBuild forum
Cpp\v4.0\V140\Platforms in order to get VS 2015 Update 2 to build the Compact x86 and ... I am getting this error when I...
Read more >C# Compiler Options to report errors and warnings
The following options control how the compiler reports errors and warnings. The new MSBuild syntax is shown in Bold. The older csc.exe ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I am having the same issue. After updating to update 3 of VS 2015 there is a compiler error. Moving the line
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
as described fixes the compiler error, but breaks the loading of roslyn files to the\bin\roslyn\
-directory, causing the application to be unable to load.As part of our .csproj we have
to ensure roslyn files are loaded. This no longer seems to work when the above line is moved.
@isaacabraham Possibly, this one was also fixed by uplifting the version of imports used (I think to 1.2 and something), if the change in that uplift is that described in #1887 I’d think it is the same.