Web Application Build Error: The CodeDom provider type Microsoft.VisualC.CppCodeProvider could not be located
Asked Answered
S

20

62

I'm building/packing a web application in a build server, and it fails with the following message:

ASPNETCOMPILER error ASPCONFIG: The CodeDom provider type "Microsoft.VisualC.CppCodeProvider, CppCodeProvider, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" could not be located.

This is the build server environment:

  • Windows Server 2008 R2 Standard
  • TeamCity 8.0.4
  • .NET 4.5
  • Windows SDK for Windows 7 and .NET 4
  • Windows SDK for Windows 8 and .NET 4.5
  • Portable Class Library Tools
  • ASP MVC 4

It is a ASP MVC 4 web application, targeting .NET 4.5.

The build configuration consists in building the solution with MSBuild, and deploying it to a package, so I can publish it later.

Through the log of TeamCity, I can see the error arising when MSBuild runs aspnet_compiler.exe.

The builds with no problem in my DEV machine and can also publish it to a local IIS without problems.

Does anyone know what may be causing this issue?

UPDATE

See my answer below.

Suspension answered 12/12, 2013 at 13:45 Comment(0)
S
88

For me this error was popping up in VS2017 when building the web project. The fix was to make the node_modules directory hidden in File Explorer. Apparently this stops the ASP.NET compiler from scanning all these files and thus prevents the error.

Semiweekly answered 7/4, 2017 at 10:0 Comment(3)
This is definitely a workaround (one I couldn't use because having the node_module folder hidden broke other workflows.) I found installing .NET 3.5 made this problem go away.Axle
Had a similar issue, cause was the npm package "uws" and its *.c files. I just moved it out of the folder before the build and put it back after. Not really feasible to hide the whole folder for our purposes either, unfortunately.Sandysandye
Worked for me. This work around really shows the age of Visual Studio.Diplomatist
S
35

This post gave me an important clue: apparently ASP.NET precompilation scans the project and output files and tries to compile every source file it finds in its way, despite its language (see here).

In the case, my web app depends on a project which includes some unmanaged dll along a ".h" file. These files are copied to the output directory ("Copy if newer") so I can pinvoke it at runtime.

It seems ASP.NET precompilation finds the ".h" and tries to compile it, even though there is no need of it. And, as I see it, it fails because my build server does not has the tools for the job (it looks like CppCodeProvider comes with the .NET 2.0 SDK).

When I changed the project not to copy those files to the output directory, the build ran fine. I also tested copying the files, but with "PrecompileBeforePublish" set to false in the publish profile, and it also worked.

Now I have some options, but I don't like any of them:

  • Disable "PrecompileBeforePublish". I believe the main disadvantage of that is the app users experience will be slower on the first site access.

  • Try to exclude files from the output folder and add them again after pre-compilation. That seems a lot of work for something I shouldn't be worrying in first place.

  • Try to tell "aspnet_compiler.exe" to exclude the offending files/folder when executing. I don't know how to do it using the publish profile, because I only have control over "PrecompileBeforePublish". Also, it seems "aspnet_compiler.exe" does not offer that option (here and here).

I think for now I'll disable "PrecompileBeforePublish", because it seems a fast path with few caveats. But I believe there should be a better way to handle it, excluding folders or file types from precompilation using the publish profile.

Suspension answered 7/1, 2014 at 3:0 Comment(6)
My goodness! - Thank you so much for this post - you probably saved me days of frustration since this is exactly what happened to us. Did you ever find a way to ignore a folder? (Though my first choice is to delete the offending files from the repo.)Rib
No, Edward, I had to keep "PrecompileBeforePublish" disabled. However, I stopped working on that project soon after this problem, so maybe the answer is still somewhere out there =]Suspension
@Rib I just ran into this too. I've had good luck so far with marking my no compile necessary folders with the hidden attribute (attrib +H c:\path\to\problem\directory) in my build script before running aspnet_compiler.exe then resetting the hidden attribute when its done.Rebus
That's another good option @twamley. I was able to delete the files, so it is working for me again. Your method sounds like a valid answer to the question, though. ping me if you write it up and I'll vote it up.Rib
This info is golden! We have a node_modules folder in our front-end and this causes problems as some modules include c-files and header files that are not meant for Visual Studio. The only way to avoid this error was to have msbuild delete the folder.Rightly
In my case, I was able to simply remove source code from the AppCode directory that was not needed there. I needed the resulting DLLs, but not the C/C++ source, etcRavo
S
35

For the benefit of those who find this later on Google...

Root Cause

As the error implies, the assembly "Microsoft.VisualC.CppCodeProvider" couldn't be found.

This was added to the Global Assembly Cache (GAC) as part of Visual Studio 2015 installation, but not Visual Studio 2017 or 2022.

The Fix

The proper fix is to add the missing reference to the GAC.

Run the "Developer Command Prompt" as admin, and run the following

gacutil /i "path to CppCodeProvider.dll" or gacutil /i "C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\PublicAssemblies\CppCodeProvider.dll"

e.g.

C:\Windows\System32>gacutil /i "C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\PublicAssemblies\CppCodeProvider.dll"
Microsoft (R) .NET Global Assembly Cache Utility.  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly successfully added to the cache

C:\Windows\System32>

On the next build the following error is no longer thrown.

ASPNETCOMPILER error ASPCONFIG: The CodeDom provider type "Microsoft.VisualC.CppCodeProvider, CppCodeProvider, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" could not be located.

Shifflett answered 8/8, 2019 at 13:30 Comment(6)
This one should be marked as an answer. Thanks DanielHybris
What do you do if you don't have the CppCodeProvider.dll at all? This seems like the answer that would solve my problem, however after searching my entire C: drive I discovered I don't have the .dll anywhere.Vacuva
Try modifying your visual studio installation and choosing "Desktop Development with C++".Shifflett
Resolved for me, thanks! Your path may be different depending on the version of VS you're usingPiecedyed
Solved my problem. This should be The Answer.Hausner
You might need to specify the path for gacutil. See #12386852Saffian
D
10

This started happening when I updating to VS2017. The problem for me was node.js, if I deleted the node_modules folder then the project would build without errors. It turns out that changing the value of MvcBuildViews to false in the csproj file as suggested by anders here fixes it. This isn't ideal though since mvc views won't be compiled until IIS renders them. Personally, I just hide the node_modules folder to get around the issue but I wanted to add this answer in case it helps shed some light on the underlying issue for someone else.

<MvcBuildViews>false</MvcBuildViews>

Dobruja answered 9/5, 2017 at 0:27 Comment(1)
I decided to automate having the folder hidden. Here's the answer if you still need to do that. https://mcmap.net/q/319958/-web-application-build-error-the-codedom-provider-type-microsoft-visualc-cppcodeprovider-could-not-be-locatedDivider
S
6

In my case I had added an angular website to my solution which caused this error.

Resolved the error with following steps.

On the menu bar, choose Build > Configuration Manager.

In the Project contexts table, exclude the angular website (which contained node_modules)

In the Build column for the project, clear the check box.

Choose the Close button, and then rebuild the solution.

Sorrow answered 16/5, 2019 at 6:26 Comment(2)
me too it was because I added my App folder from my React App just because I wanted to see everything in visual studio despite using VS Code for the App and visual studio for the ApiGrip
This is actually the better answer here. Make sure any projects that are not built by VS are unchecked in the configuration manager.Dunghill
T
4

In my scenario, I have to ship a Perl interpreter with my ASP.Net website (don't ask why I need Perl, and I'm sorry I do in advance!), and that included .c files that caused the aspnet_compiler.exe to error out, as others have mentioned being their problem. The perl directory is in my bin folder, and is required at runtime.

The trouble I found was when you attrib +H the folder, it indeed was skipped by aspnet_compiler, but then wouldn't be in my publish output folder. So I had to hack it even more by hiding the folder, compile views, unhide folder, and then copy folder to the right location. This involved modifying the original AspNetPreCompile task. See below:

<!-- Overwrite AspNetPreCompile task because it was trying to compile .c files found in the Perl directory. This prevents that but still copies Perl to publish file. -->
<!-- Taken from: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\Web\Transform -->
<Target Name="AspNetPreCompile" DependsOnTargets="$(AspNetPreCompileDependsOn)"  Condition="'$(AspNetPreCompile)' != 'false'">

    <PropertyGroup  Condition="'$(UseMetabasePath)' == 'true'" >
        <_PreAspnetCompileMergeSingleTargetFolderFullPath></_PreAspnetCompileMergeSingleTargetFolderFullPath>
        <_AspNetCompilerVirtualPath></_AspNetCompilerVirtualPath>
    </PropertyGroup>
    <PropertyGroup  Condition="'$(UseMetabasePath)' != 'true'" >
        <_PreAspnetCompileMergeSingleTargetFolderFullPath>$([System.IO.Path]::GetFullPath($(_PreAspnetCompileMergeSingleTargetFolder)))</_PreAspnetCompileMergeSingleTargetFolderFullPath>
    </PropertyGroup>

    <PropertyGroup>
        <_PostAspnetCompileMergeSingleTargetFolderFullPath>$([System.IO.Path]::GetFullPath($(_PostAspnetCompileMergeSingleTargetFolder)))</_PostAspnetCompileMergeSingleTargetFolderFullPath>
    </PropertyGroup>

    <!-- Modification #1. -->
    <Exec Command="attrib +H &quot;$(IntermediateOutputPath)AspnetCompileMerge\Source\bin\perl&quot;" />

    <AspNetCompiler
        PhysicalPath="$(_PreAspnetCompileMergeSingleTargetFolderFullPath)"
        TargetPath="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)"
        VirtualPath="$(_AspNetCompilerVirtualPath)"
        Force="$(_AspNetCompilerForce)"
        Debug="$(DebugSymbols)"
        Updateable="$(EnableUpdateable)"
        KeyFile="$(_AspNetCompileMergeKeyFile)"
        KeyContainer="$(_AspNetCompileMergeKeyContainer)"
        DelaySign="$(DelaySign)"
        AllowPartiallyTrustedCallers="$(AllowPartiallyTrustedCallers)"
        FixedNames="$(_AspNetCompilerFixedNames)"
        Clean="$(Clean)"
        MetabasePath="$(_AspNetCompilerMetabasePath)"
        ToolPath="$(AspnetCompilerPath)"
        />

    <!-- Modification #2. -->
    <Exec Command="attrib -H &quot;$(IntermediateOutputPath)AspnetCompileMerge\Source\bin\perl&quot;" />

    <!--
        Removing APP_DATA is done here so that the output groups reflect the fact that App_data is
        not present
        -->
    <RemoveDir Condition="'$(DeleteAppDataFolder)' == 'true' And Exists('$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\App_Data')"
                Directories="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\App_Data" />


    <CollectFilesinFolder Condition="'$(UseMerge)' != 'true'"
        RootPath="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)" >
        <Output TaskParameter="Result" ItemName="_AspnetCompileMergePrecompiledOutputNoMetadata" />
    </CollectFilesinFolder>

    <ItemGroup Condition="'$(UseMerge)' != 'true'">
        <FileWrites Include="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\**"/>
    </ItemGroup>

    <!-- Modification #3. -->
    <ItemGroup>
        <Perl Include="$(IntermediateOutputPath)AspnetCompileMerge\Source\bin\perl\**\*.*" />
    </ItemGroup>

    <!-- Modification #4. -->
    <Copy SourceFiles="@(Perl)" DestinationFolder="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\bin\perl\%(RecursiveDir)"></Copy>

</Target>

DO NOT modify the original .targets file, copy this into your .csproj file as a child to the <project> node.

Key takeaways:

Use Exec command to attrib +H Directory before running aspnet_compiler.exe via the AspNetCompiler task, and attrib -H Directory afterwards.

Create an ItemGroup to suck in all the files that still need to be copied.

Run the Copy task, utilizing that ItemGroup to put the files where they need to be in order for the rest of the publish task to include them. We get to use all of the variables that Microsoft made when authoring this Task, so we can use those here too.

Pro to modifying the original task: very little changes about the normal behavior, so it should still just work.

Possible con to modifying the original task: Microsoft might change this task in the future, making our copy out of date.

If you don't have my weird requirements, the simpler solution to hiding a folder is as follows:

<Target Name="Test" BeforeTargets="AspNetPreCompile">
    <Exec Command="attrib +H Directory" />
</Target>
<Target Name="Test" AfterTargets="AspNetPreCompile">
    <Exec Command="attrib -H Directory" />
</Target>

Answer inspired by the comment twamley made in Arthur Nunes answer.

Thracophrygian answered 26/5, 2017 at 19:49 Comment(0)
D
3

In my case it was the node_modules folder. I made this change in my csproj file for my .net 4.8 app to fix it.

This will just add the hidden attribute to the node_modules folder and then unhide it after the Razor pages are compiled.

<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
  <Exec Command="attrib +H &quot;$(ProjectDir)node_modules&quot;" />
  <AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
  <Exec Command="attrib -H &quot;$(ProjectDir)node_modules&quot;" />
</Target>
Divider answered 12/7, 2021 at 6:41 Comment(0)
A
0

Try doing the folowing.

Setting RequireTargetFramework to 4.0.

Link:ASPNETCOMPILER error ASPCONFIG: Could not load file or assembly 'Microsoft.VisualBasic.Activities.Compiler' or one of its dependencies

Adamite answered 12/12, 2013 at 15:29 Comment(0)
J
0

In my case the issue was that the web config of a parent solution (root level project) in IIS had this in it's web config (by mistake, not sure how it got there). Took a long time to track down, because nothing I could do in my solution/project could affect it in any way.

So might be worth checking the web.config of all that might be involved.

Jiggermast answered 8/9, 2015 at 6:8 Comment(0)
S
0

For me this error was showing when my website's physical path was invalid in IIS. To resolve that right click on website (Manage website -> Advanced settings -> Physical Path).

Solomon answered 16/5, 2016 at 14:17 Comment(0)
I
0

In my case, on a new machine, installed VS2017 and opened an asp.net core 1.1 web application from source control. The error showed up. I installed node.js and the project compiled.

Ingeborg answered 15/8, 2017 at 1:35 Comment(0)
L
0

My solution to this error was a combination of two pre-existing answers on this page. I had a .h file in my web project directory that had not caused a problem until I tried to build the project on a VS 2017 machine.

In my case I simply zipped it up, but the upshot seems to be that you can no longer keep unrelated code files in the web directory or VS will trip up trying to compile them.

Langlois answered 20/6, 2018 at 9:13 Comment(0)
S
0

I solved it with deleting node modules folder then running npm i from git bash and not from VS2019 built in terminal.

Sufficient answered 27/1, 2021 at 16:22 Comment(0)
L
0

Copy cppprovider.dll from Visual Studio 2015 installation path to:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies

Logorrhea answered 27/3, 2021 at 7:6 Comment(0)
M
0

An easy way to solve is that to reference the CppCodeProvider.dll. It may locate at

C:\Program Files (x86)\Microsoft Visual Studio{version}\{edition}\Common7\IDE\PublicAssemblies

For example:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\PublicAssemblies\CppCodeProvider.dll

It will be in the bin folder.

enter image description here

Mcnabb answered 19/8, 2021 at 9:50 Comment(0)
T
0

I moved my solution from VS2019 to VS2022 and was having this error when I tried to publish solution. This is how I made the error disappear.

  • Right-click on References>> Add References
  • Then Search for Microsoft.VisualC
  • tick Microsoft.VisualC and Microsoft.VisualC.VSCodeProvider
  • click ok. Error gone!
Tommi answered 16/12, 2021 at 9:24 Comment(0)
K
0

I installed VS2019 on a new laptop but kept getting the same error message as the OP. (it still worked fine on my desktop PC).

After a day or so of trying every answer on here and Google, and getting no joy, I tried using, from the toolbar, Build -> Publish Web App, which built my website into the Publish folder ok.

I then took this 'Publish' folder and copied it to a new place on my C:drive.

Then after closings and re-opening VS2019, started with "continue without code".

Then File -> Open -> Web Site... select my 'Publish' folder, and hooray I can now build and debug my project locally.

Kipton answered 10/5, 2022 at 11:34 Comment(0)
E
0

The issue was occurring for me when I was building a web project with node_modules. I fixed the error by enabling Desktop development with C++ option in my Visual Studio installer.

Source: https://developercommunity.visualstudio.com/t/cppcodeprovider-not-properly-installed-with-vs2017/240322#T-N333161

In Visual Studio 2017 CppCodeProvider.dll is getting shipped with “Desktop development with C++” as a result installing “Desktop development with C++” should resolve the issue.

Esthete answered 12/9, 2022 at 6:12 Comment(0)
D
0

Not a good look for Microsoft that this is still an issue 10 years later than the question was asked, but here is a different solution than those already listed that was quick and worked for me. I traced the issue to *.h files in some of my node modules. The solution is to ignore them. Add a file on the root of your project with node modules called Directory.Build.props. Paste the xml below into it and save. Rebuild.

<Project>
 <ItemGroup>
  <Compile Remove="**/*.h" />
 </ItemGroup>
</Project>
Disconcert answered 8/5 at 22:19 Comment(0)
D
0

Not a good look for Microsoft that this is still an issue 10 years later than the question was asked, but here is a different solution than those already listed that was quick and worked for me. I traced the issue to *.h files in some of my node modules. The solution is to ignore them. Add a file on the root of your project with node modules called Directory.Build.props. Paste the xml below into it and save. Rebuild.

Blockquote

Blockquote

Disconcert answered 8/5 at 22:20 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.