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

Question

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

ASPNETCOMPILER error ASPCONFIG: The CodeDom provider t

Answer 1

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:

    
        <_PreAspnetCompileMergeSingleTargetFolderFullPath>
        <_AspNetCompilerVirtualPath>
    
    
        <_PreAspnetCompileMergeSingleTargetFolderFullPath>$([System.IO.Path]::GetFullPath($(_PreAspnetCompileMergeSingleTargetFolder)))
    

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

    
    

    

    
    

    
    


    
        

    

    
        
    

    
    
        
    

    
    

DO NOT modify the original .targets file, copy this into your .csproj file as a child to the 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:

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