Develop Reference

web.config not app.config being published to xxx.dll.config in Visual Studio 2015

I have an ASP.NET project that outputs a class library as a dll which is then deployed to IIS. Per standard builds a config file is also output along with the dll as xxx.dll.config and it contains many useful environment variables such as connection strings (i.e. it conforms to the application settings architecture requirements).
In VS 2012 the contents of xxx.dll.config file were sourced from app.config in the project root directory.
In VS 2015 it appears xxx.dll.config's contents are instead sourced from web.config in the project root directory.
Steps to reproduce:
Create a ASP.NET application with VS2015.
Add a app.config file in this application.
Build this application.
Open the bin folder and find the application.dll.config file and open it. The content is the same with Web.config.
Do the same operations from Step 1 to Step 4 in Visual Studio 2012, the content is the same with App.config.
This is causing me a bit of a headache as I was relying on app.config to hold variables (connection strings, auth providers) for my functional tests while web.config held variables for deployed code.
Most of the reading I've done on AppDomains and their configuration variables seems to indicate that web.config shouldn't factor into the build output unless explicitly instructed and even then it isn't exactly easy to transform a web.config file, nevermind have it end up as the xxx.dll.config file.
I could rework my test fixtures to set the environment variables directly from the tests but for things like ASP.Identity that requires writing quite a few new classes to load a RoleManager and associated providers which I'd like to avoid.
If anyone could suggest how to engineer the VS build to output a config file that is easily used by the assembly AND the nunit tests when run via the nunit runner or Resharper that would be awesome.

To restore the original behaviour of Visual Studio 2015 back to what I was accustomed to in Visual Studio 2012 I added a post build event:
Go to Project-> Properties
Select Build Events
Add the following to the "Post-build event command line" :
copy /Y "$(ProjectDir)\App.config" "$(TargetDir)\$(TargetName).dll.config"
The .dll.config is now once again the App.config instead of Web.config

Perform a web.config transform before publishing with MSBuild

I am trying to do a web deploy publish using MS Build for two web applications for internal use and testing. I have set up different solution configurations for each of the environments that i want to publish to. IE DevA, DevB. I have updated all the web.configs to do the correct transformations. As a note, the transforms work when i do a right click publish through Visual Studio so I have ruled those out as the problem. My current bat file that I am running uses this command to do the work:
"C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild" project.csproj
/t:Clean;Rebuild;Publish
/p:DeployOnBuild=true;PublishProfile=DevB1_API;AllowUntrustedCertificate=True;username=username;password=password
When i run this command the publish works just fine. However, the web.config is not being transformed. Am i missing a msbuild parameter to force this to happen? Any Help would be appreciated! thanks.

Apparently, for the transform to be executed, you have to specify a build configuration using:
/p:Configuration=Release

Cannot deploy MVC 4 to server

My web application is just a simple web application made in VS 2010 MVC 4 without any code from outside. It's just default application of VS 2010. I have Deluxe Windows Hosting with Plesk. I've never changed any feature in my account. I copy all my files to "//Root Directory". Beside my files I see various folderssuch as: ", plesk, erro-docs, cgi-bin, logs" - I do not have permissions to delete them.
All my projects are "Release" configuration. I've tried all ways which I met in the Internet:
1.I copied three libraries to bin directory:
System.Web.Mvc, System.Web.Routing, System.Web.Abstractions
These dll's I copied from GAC(C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL). I putted such strings in web.config: < trust level="Medium"/>. I used local deployment(to directory) in VS2010 by button "Publish". No result.
2.I copied 9 libraries to bin directory:
System.Web.Abstractions.dll
System.Web.Helpers.dll
System.Web.Mvc.dll
System.Web.Optimization.dll
System.Web.Razor.dll
System.Web.Routing.dll
System.Web.WebPages.Deployment.dll
System.Web.WebPages.dll
System.Web.WebPages.Razor.dll.
These dll's I copied from GAC(C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL). I used local deployment(to directory) in VS2010 by button "Publish". I putted such strings: < trust level="Medium"/>. No result.
3.I copied three libraries to bin directory: System.Web.Mvc, System.Web.Routing, System.Web.Abstractions - these dll's I copied from GAC(C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL). I putted such strings: < trust level="Medium"/>. I used deployment via ftp option in VS2010 by button "Publish". No result.
4.I copied three libraries to bin directory:
System.Web.Abstractions.dll
System.Web.Helpers.dll
System.Web.Mvc.dll
System.Web.Optimization.dll
System.Web.Razor.dll
System.Web.Routing.dll
System.Web.WebPages.Deployment.dll
System.Web.WebPages.dll
System.Web.WebPages.Razor.dll - these dll's I copied from GAC(C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL). I putted such strings: < trust level="Medium"/>. I used deployment via ftp in VS2010 by button "Publish" No result.
5.I've tried to upload files via filezzilla. < trust level="Medium"/>. However it was an idle attempt.
6.I've tried to upload files via browsers. However it was an idle attempt.
7.I've tried to upload zip-files via browser and extract them at godaddy server. < trust level="Medium"/>. However it was an idle attempt.
All above-listed attempts result the word on the screen: "nup.com My site is launching soon."
Nothing changes.
I have a question.
What I do wrong?
I've read all articles by Phil Haack http://haacked.com/archive/2008/11/03/bin-deploy-aspnetmvc.aspx. Any help will be gratefully appreciated!:)

Ok - you have a lot of questions inside your single question. I am going to try and take these one at a time as well as some of your commentary so that we can a) understand the build/publish process of an MVC app and b) hopefully get your project running over at GoDaddy.
1.If I change in web.config , then should I recompile my project and upload again?
No, unless you change the web.config locally and you need to upload those changes. If you FTP/connect to the web.config on the actual web server, IIS will automatically restart (reload) your application so that it can apply the web.config changes. After a web.config change, you will notice the first request will take 10-20 seconds. This is IIS restarting your application. If you change the web.config locally, then yes, you should rebuild/reupload.
2.Is it correct to copy a project to root of directory?
The way you have phrased this question makes me think that yes, you are doing it wrong. When you create a project in Visual Studio, you get a solution folder on your actual hard drive. If you are compiling that project, then copying the entire solution folder to your web server, then yes, this is not the correct way to do it. What you want to do is create a Publishing Profile. You can either deploy your application via Web Deploy (unsure if GoDaddy supports this), FTP, or File System. By going through the Visual Studio publishing process, the compiler a) compiles your application per your settings (Debug or Release), b) applies the proper Web.Config transformations and c) only outputs the files necessary to run your application. The third part is important. All of your .cs files (controllers, models, etc) get compiled into a .dll and that is what needs to be deployed, not the actual source code files. The publishing process does this for you.
I would recommend you create a folder on your dev machine somewhere, and then create a publishing profile that publishes your application to that folder. It is the contents of that folder that you want to FTP to your web server. To create a publishing profile, right click your MVC project and select Publish. This will bring up the wizard for you to set things up.
3.What I do wrong?
Kind of hard to say at this point. It could be that you are not compiling your application correctly. FTP sounds bonked, but that is not an MVC/Visual Studio issue. For FTP issues with Plesk on GoDaddy (and other items), check this help link here.
4.how can I see the errors? Should I write a message or what should I do to know more about errors?
You should be able to control this in your web.config. Open your web.config file up and check for a couple of lines. You want to turn off custom errors and set the compilation to debug mode. This does two things. One, the error you get back from the server will be way more detailed and being in debug mode allows IIS/.NET to actually show you the line of code that is causing the problem.
<system.web>
<compilation debug="true" targetFramework="4.5" />
<customErrors mode="Off"></customErrors>
</system.web>
Be aware that if you do have a web.config transformation, this could actually turn these setting off. Ensure that your publishing profile is set to deploy the Debug configuration while you test deploying your site. Once you are happy with your results, set it back to Release configuration so that your site runs faster as well as does not display code lines to potentially bad people if an error does occur.
5.I copied 9 libraries to bin directory...
Ok, this could also be a problem. You do not need to copy anything to your bin directory. If you want to include referenced assemblies in your published project, all you need to do is open the References folder under your project. From there, right click any assembly that you want to include in your project when you publish and select Properties. Inside of the properties pane, you will see the option to Copy Local. Set this to true. This tells the compiler to copy that assembly to the output folder during the publishing process (see, that publishing thing does lots of good stuff for you!) I would do this for all assemblies in your project that are MVC related. You can experiment with this (like one at a time) until you find the right combination of assemblies that you need to include in your project to make it run on the GoDaddy server. I have not used GoDaddy hosting in quite a while, so I do not know what their current capabilities are.
Last thoughts, I think MVC 4 is .NET 4 or higher. Ensure that GoDaddy supports .NET 4 or higher or else you really won't be able to host this on that server (even using bin deploy) and will need to find additional hosting. Azure has some really great deals right now and Gearhost is very reliable but a little pricey (though they are completely simple to use).
EDIT
Just a little more info on GoDaddy - ensure that you set your site up correctly before you try any of this. You need to have Windows hosting (most likely) and it should be setup to use the Integrated App pool (else, it would appear you never uploaded anything since there is no 'default document'). At this point, I wonder if your hosting account was provisioned correctly for what you want to do. http://support.godaddy.com/help/article/6639/do-your-hosting-accounts-support-mvc3-applications (Yes, I know it says MVC 3, but the setup applies equally to MVC 4)

Have you tried bin deploying MVC4?
http://haacked.com/archive/2011/05/25/bin-deploying-asp-net-mvc-3.aspx/
or
http://forums.asp.net/t/1884928.aspx
To answer your question:
Changes to web.config should not require the project to be recompiled.

Hope this helps...
Depends what you've changed, some changes might at least require an application pool reset.
Root of what directory? It should generally be inside inetpub/YOURWEBSITEFOLDERHERE
You have assumed that GoDaddy supports MVC 4, I could only find references to them supporting MVC 3 Support
There are rumours that if you deploy the bin and mvc dll there is a way around this but I couldn't find any details.
Have a read of the MVC 3 deploy instructions
EDIT: In answer to comment below:
Editing could have a knock on effect and so i would advise towards a recompile, e.g. change to medium trust might have an affect if DLLs don't work in partial trust mode, and recompilation might well highlight these issues.
Sounds ok, test by putting a html file up with some text and try and get to it in your browser.
I've seen people talking about it, mostly saying it's not supported, try the MVC deploy instructions above to bin deploy MVC 4; it works with 3, it might work with 4.

I had the same problem with a MVC4 I had running on hosting on Godaddy using Plesk. Suddenly, without any changes, site began to display "Site Launching Soon" Page. At first I thought it was hacked. After calling godaddy support, the agent told me that the site must need at least one html file as a start point (index.html, index.aspx, default.aspx - source: http://support.godaddy.com/help/article/60/what-file-displays-when-someone-browses-to-my-domain-name?locale=en&ci=46061), which seemed odd because it was working fine all the time.
Then, after some trial - error stuff, I could solve my problem by going to the Plesk hosting management, and navigate to:
Websites & Domains > [domain name] > Web Server Settings for domain. And there, change the Default Document setting to "Default".
We never touched that setting, not sure really why it suddenly changed.
Hope that helps!

Hope this helps . . .
Global.asax should be your default index . . . in godaddy server settings.
I had a similar problem and was able to solve it.
I have two other mvc application sites hosted on godaddy, but not with their new plesk hosting.
After calling tech support and not having any luck there I did some reading on their hosting.
Their plesk hosting must have an index.
So, a few hours later it dawned on me to point their start point to my Global.asax in their server settings.
And, viola! my site was up and running.

I've done all actions to deploy correctly but I copied all files to a wrong folder. The problem was that I just copied all my files to a wrong directory. I called to godaddy support and they said that I copied my files to wrong directory.
When I copied all files to "httpdocs" directory then my mvc 4 application start working!:).
Thank you a lot, guys. Good luck.

I was having the same issue until I set customErrors to off (first line). then I started seeing security policy issues which was remedied (second line).
(I'm using Godaddy)

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

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.

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.

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.

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.
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 (x86)\Microsoft Visual Studio\2
017\Professional\Common7\IDE\PublicAssemblies\CppCodeProvider.dll"
e.g.
C:\Windows\System32>gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2
017\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 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.

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>

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.

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 "$(IntermediateOutputPath)AspnetCompileMerge\Source\bin\perl"" />
<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 "$(IntermediateOutputPath)AspnetCompileMerge\Source\bin\perl"" />
<!--
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.

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 "$(ProjectDir)node_modules"" />
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
<Exec Command="attrib -H "$(ProjectDir)node_modules"" />
</Target>

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

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.

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).

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.

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.

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

Copy cppprovider.dll from Visual Studio 2015 installation path to:
C:\Program Files (x86)\Microsoft Visual Studio
11.0\Common7\IDE\PublicAssemblies

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.

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!

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.

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.

Why doesn't switching to release in VS set the debug parameter to false in web.config

In VS2008 (and earlier if I'm not mistaking) I have dropdown that lets me choose between Debug and Release mode. All well.
When I switch VS to Release, the debug attribute in my web.config files isn't set to false at all though.
Is this the way it is supposed to be? I am bound to forget to set it to the correct value on deploying.. What measures should I take to make sure this is working like it should?

This is one solution to this problem:
http://blog.aggregatedintelligence.com/2009/04/aspnet-never-again-fear-publishing-your.html

Well your web.config would probably be different for debug and release (connection string, passwords, etc...) but if it's not, look at a postbuild event which would copy over a different file.
Also check this blog post from Scott Guthrie.

Changing release mode will not change web.config, however when you build your web app, it will build the dll for only C# files in release mode where else your web.config's debug on/off is used by IIS to build debug/release version of ASPX markup files.

The build flavour just affects how the code is compiled, it does not affect your configuration files. So yes, to answer your question, this is how it is supposd to be.

The element is a good solution if you have access to the machine.config of your server, which hosts only production applications.
I usually modify the web.config file when generating the deployed files as part of the automated build process. For example web deployment projects can perform web.config section replacement. There are a number of reasons I don't like web deployment projects and I tend to do it with a simple VBS file that modifies the file using MSXML.

The answer you selected from Bobby is not correct. Visual Studio builds the files for you in release while you are in VStudio.
IIS compiles the code at startup with that setting when you deploy. Not the bin directory, but the App_Code and the code behind files.
You should precompile your app before deployment which will compile your code behinds and App_Code dir into dlls in the bin directory.
The deployment tools automatically switch that setting if you set the deployment tool to Release
I use web deployment projects. http://weblogs.asp.net/scottgu/archive/2008/01/28/vs-2008-web-deployment-project-support-released.aspx