I've been working on a CefSharp WinForms app for a few weeks and I've had no issues with it. This morning, while adding a few things to the application, I tried to run it to test something and got the below error:
System.IO.FileNotFoundException was unhandled Message: An unhandled
exception of type 'System.IO.FileNotFoundException' occurred in
mscorlib.dll Additional information: Could not load file or assembly
'CefSharp.Core.dll' or one of its dependencies. The specified module
could not be found.
After searching for a while I found this:
https://github.com/cefsharp/CefSharp/wiki/Frequently-asked-questions#Runtime_dependencies
I checked bin/Debug/x86 for the project and all of the dependencies appear to be present. More importantly, it had been working fine five minutes earlier, and I didn't touch anything beyond a single class for an Entity Framework migration.
I've tried cleaning and rebuilding the solution, restarting Visual Studio, restarting my PC, and clearing out /bin/Debug, and none of these have helped.
Why would this error appear now after several days without it, and how can I resolve the issue?
Edit: I've done some further experimenting and I'm able to get the application to run in Release mode but not Debug mode. If I change the output path of Release mode to Debug, it fails with the same error (likewise, it succeeds in Debug with the Release output path).
First, make sure you installed the Microsoft Visual C++ Redistributable:
Version v93 and above: use Microsoft Visual C++ 2019 Redistributable or greater
Version v65 - v92: use Microsoft Visual C++ 2015 Redistributable or greater
Older Versions: use Microsoft Visual C++ 2013 Redistributable (exact version)
You could download the Visual C++ Redistributable from Microsoft. See C++ binary compatibility between Visual Studio versions for more detail on the version compatability.
Make sure to match the correct architecture, if your application is x64, you need to install the x64 build of Visual C++ Redistributable. Likewise if your application is x86 then you need to install the x86 build of Visual C++ Redistributable.
The Microsoft Visual C++ Redistributable depends on the Universal CRT. The Universal CRT is included as part of Windows 10/11. On older versions of Windows the Visual C++ Redistributable will install the Universal CRT.
For those wishing to include the Visual C++ Runtime with their application it's technically possible to include the runtime with your application. See also Local Deployment section of the Deployment in Visual C++ article from Microsoft.
I had the same problem until I installed the following redistributable:
SuperBerry's solution of installing VC++ redistribution package solved the problem for me. I'll just provide a little troubleshooting insights from my naïve perspective.
The error message is pretty clear, either the assemble CefSharp.Core.dll is missing or one of it's dependencies. So the question boils down to how do you figure out what is missing?
So first, do you have CefSharp.Core.dll? In the Solution Explorer look at the references for the project that is having this problem. You should find a reference to CefSharp.Core. If you can't find one, you're missing that assembly. If you have one, then the problem is that you're missing one of its required dependencies. When you click on the CefSharp.Core reference, in the detail, you'll get the full path to where it's located. In my case, it was in located at 'C:\Users\tom\source\repos\MyProject\src\packages\CefSharp.Common.41.0.0\CefSharp\x86\CefSharp.Core.dll'.
You then need to get a list of the CefSharp.Core dependencies to figure out which dependency your missing. Dumpbin.exe is a command line tool that you can use to get a list of dependencies. In order to use dumpbin, you need to make sure that it can be found on the path in your system environment variables. I found on the path of the VC Tools bin directory. In my case, I found one at: 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\bin\Hostx64\x64'. Open a Command Prompt terminal and navigate to the folder containing CefSharp.Core.dll and key in the following:
>dumpbin /dependents CefSharp.Core.dll
the result I got was:
Dump of file CefSharp.Core.dll
File Type: DLL
Image has the following dependencies:
KERNEL32.dll
MSVCP110.dll
MSVCR110.dll
libcef.dll
USER32.dll
mscoree.dll
Not having worked with Microsoft Visual Studio for a number of years, I had to try and figure out where those dependencies are suppose to be located so that they can be resolved. I simply did an internet search such as "where is Kernel32.dll located" doing that for each dll until I found the missing dll. In my case, I could not find MSVCR110.dll, so I strongly suspected that was my problem. I then did an internet search for "MSVCR110.dll is missing" and found out that it was part of the vc++ redistribution. (SuperBerry, you were right on your first point). I also found that it could be downloaded from: 'https://www.microsoft.com/en-us/download/details.aspx?id=30679'. I downloaded both the x86 and x64 versions (although I only needed the x86 version for this project). They are executables that when run installs them. After installing them I found a copy of it in 'C:\Windows\SysWOW64' and in 'C:/Windows\System32'. And low and behold this problem was resolved.
What I learned from this process, was that it was difficult to know whether you have the right VC++ redistribution package installed or not. I thought I would have been installed when visual studio was installed with the VC++ features enabled. I'm using visual studio community version 2019. The project I am working with was a project I cloned from a GitHub source. I'm still confused about VC++ redistribution versioning. For example, could I have installed some later version and would it have worked (i.e. backward compatibility)?
I had the same issue. what worked for me is to add
<CefSharpBuildAction>Content</CefSharpBuildAction>
to the first PropertyGroup inside the csproj of the project you are dealing with.
I had the same issue even in release mode. Going through GitHub CefSharp FAQs, NOTE 2 solved my issue.
If compiling from source (not recommended, use the Nuget packages) and you notice that you can no longer build in debug mode, but release builds work just fine you may need to repair your version of Visual Studio. This happens in rare cases where you will get the same exact message as a missing unmanaged .dll file as shown above.
Had to repair Visual Studio and all started working as before.
For my future me, had this same issue and every time i get this error when i start my .net core 3.1 wpf application in visual studio -> Could not load file or assembly 'CefSharp.Core.Runtime.
That cost me hours!
My Solution: Don't initialize Cef in your WinForm or WPF Window class.
You need to initialize this in your startup main/app. In my example i need to add this:
public App()
{
CefSettings _browserSettings = new CefSettings();
...
Cef.Initialize(_browserSettings);
}
Here is a short video of my error.
It is obvious that I have something wrong between 32-bit and 64-bit. However I cant find anything that holds my hand enough to walk through the solution in Visual Studio 2012.
Can anyone give me a more detailed explanation of what and how to change in my settings?
The "startup project" (the one that builds the .exe file) determines whether the process will run 32 or 64 bits. Any library that is referenced must support the same "bitness".
If you use libraries that requires a specific CPU type, you should change the "Target CPU" property in the "Build" tab of the project properties of the project that creates the main executable to that CPU type.
Any managed library that you use, that does not depend on cpu-specific libraries can be compiled as "Any CPU".
I don't know the library you're using, but this link makes me think it requires a 32 bit build.
EDIT: I just realized I only know earlier versions of Visual Studio, so the option may be located elsewhere in 2012.
I've dealt with a similar issue just a few days ago. It wasn't as straightforward as one would expect (given the error), I had to use dependency walker in order to check if all needed dependencies of my dlls were in the correct format, turned out my dll was importing an incorrect dependency.
Dependency Walker
I have two projects, ProjectA and ProjectB. ProjectB is a console application, which depends on ProjectA. Yesterday, everything was working fine, but suddenly today when I run ProjectB I get this:
BadImageFormatException was unhandled:
Could not load file or assembly 'ProjectA, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Both are just regular projects, with no dependencies on any other non-.Net projects. Both are fully .Net - there is no native code, and no P/Invoke. I have other projects which depend on ProjectA and still work just fine.
Things I have tried:
Make sure both projects are set to "Any CPU," with the build checkbox checked. They are.
Make sure both projects are for the same Target Framework (.Net 4.0 Client Profile).
Under ProjectB --> References --> ProjectA --> Properties, make sure "Copy Local" is set to "True" _ (I verified that ProjectA.dll is being copied correctly)
Clean/Rebuild the solution. I even tried manually deleting the /bin and /obj folders in both projects.
Restart Visual Studio. Restart my computer.
Check out an entirely new copy of the repository.
But I still get the same error. I have no idea what I did to cause this, nor how to fix it. Any ideas?
I am pretty sure you're having a 32-bit / 64-bit conflict. It sounds like your main project might be set to 32-bit while the class its referencing is set to 64-bit. Try looking at this SO question and this one too. Between the two of them, you should be able to figure out your problem.
Might be you are facing the problem with your website after deploying on server.
Then you need to adjust your application pool to Enable 32-Bit Applications.
Steps
Open IIS Manager
Click on Application Pools
Select whatever application pool you are using
From right pane, click Advanced Settings...
Set Enable 32-Bit Applications to True
I just had this error message running IIS Express in Visual Studio 2015. In my case I needed to be running the 64 bit version of IIS Express:
Tools → Options → Projects and Solutions → Web Projects
Check the box
that says "Use the 64 bit version of IIS Express for web sites and
projects".
Screenshot:
I had this same problem. I had set Project A's "Platform Target" ("Project A"(Right Click)->Properties->Build->"Platform Target") to x86 but kept Project B's at "Any CPU". Setting Project B's to "x86" fixed this.
I had this problem running unit tests (xunit) in Visual Studio 2015 and came across the following fix:
Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64
You may need to change the Appication Pool setting "Enable 32bit Applications" to TRUE in IIS7 if you have at least 1 32bit dll\exe in your project.
First of all I got this in VS2017 with an old project I needed to make a tiny change to and upraded all the projects to framework 4.7.
Several others have mentioned selecting Any CPU can fix this issue.
There's a couple places you need to do it, and it might not just be as simple as selecting from the dropdown. This fixed it for me:
1) You need to do it both here:
2) And also in Configuration Manager (right click on solution)
But what if it isn't there???
Then click New and choose these settings: (thanks #RckLN)
I had the same issue with multiple projects in the same solution, i ended up setting all of the target frameworks to .NET Framework 4 and x86 for the target CPU and it finally successfully compiled.
None of these solutions worked for me - but by deleting the contents of bin and obj folders everything was cool again.
The following solved the issue for me, uncheck 'Prefer
32-bit' :
For the newer version of visual studio (v16.10 for this answer), it can be fixed by manually changing the solution platform. For me it worked after changing from "Any CPU" to "x86".
Click on solutions platform dropdown, the one in which any CPU is appearing in image below.
Go to configuration manager.
Click on new and add platform x86 or x64 (32 or 64 bits) based on what is working for you.
Restart the project.
I also had this problem. As mention before the problem was related to a 32-bit / 64-bit conflict, but with the site hosted in Azure. To change the plattform in Azure App Service, go to Configuration -> General settings.
I got this when building a project via Visual Studio Online (VSTS) Build using Visual Studio Build Steps.
The solution was:
Delete the existing source folder
Explicitly set 'Any CPU' in the platform for all Visual Studio Builds including dependencies (see screenshot below).
Re-run the build
The Chilkat .NET 4.5 assembly requires the VC++ 2012 or 2013 runtime to be installed on any computer where your application runs. Most computers will already have it installed. Your development computer will have it because Visual Studio has been installed. However, if deploying to a computer where the required VC++ runtime is not available, the above error will occur:
Install all of the bellow packages
Visual C++ Redistributable Packages for Visual Studio 2013 - vcredist_x64
Visual C++ Redistributable Packages for Visual Studio 2013 - vcredist_x86
Visual C++ Redistributable Packages for Visual Studio 2012 - vcredist_x64
Visual C++ Redistributable Packages for Visual Studio 2012 - vcredist_x86
In my case changing IIS Express Bitness from "Default" to "x86" helped.
All my projects had "x86" as the Platform target.
You might also see this issue if you're trying to package a 64bit project with an MSI installer in VS. ("The reason is because the native shim packaged with the .msi file is a 32-bit executable.")
See here for more details: http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx
I encountered the same issue. It popped up out of the blue and that seemed strange to me.
In the Exception snapshot, for the FusionLog, I saw the following within its message:
... C:\Windows\Microsoft.NET\Framework64 ...
More about the fusion log: http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx
All the projects had a Target CPU of AnyCPU. I changed the application project (the project that references all the other projects) to a Target CPU of x86. It now works.
Not sure how the Target CPU mix up occurred for no apparent reason, but it did.
I also face this problem in a project, after a few minutes i found the solution,
this problem is due to CPU configuration,
If you are using Visual Studio 2010 or VS 2013, just goto project 's properties and then select Compile from side bar and there will be 5 drop-down, 5th Drop-down will be Target CPU:, you should set it to x86 or x64 according to your requirements instead of Any CPU.
My problem was solved after changing it to x86.
This also can happen just by having multiple supported frameworks defined in the app.config file and, forcing the app to run in a different .NET framework other than the one mentioned first in the app.config file.
And also this fires when you have both of the mentioned frameworks available in your system.
As a workaround, bring up the target framework you are going to use for the debugging up in the app.config
ex: if you trying to run in .NET 4, config file should have something similar to this,
<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>
In my project for C#, project property->[Build]->Platform target: Any CPU,
and uncheck the Prefer 32-bit to let compiler to choose automatically.
I also had this problem running unit tests by using ReSharper on Visual Studio 2017 and fixed it with following config:
Also you can change the ReSharper's run test setting:
https://resharper-support.jetbrains.com/hc/en-us/articles/207242715-How-to-run-MSTest-tests-using-x64-configuration
Shoot! I knew about this problem. I thought I was doing everything right until I accidentally saw 'x86' in the VS output window and that's when I got hold of the cause. Wasted a few mins on it today.
The configuration under 'Publish' window was set to 'x86'; whereas, everywhere else, it was 'x64'.
Please make sure it's in-sync across configuration manager, publish settings, solution configurations, and IIS settings (if that's your web server).
Also, please keep in mind - VS is a 32-bit app and IIS is 64 bit. 32-bit apps are disabled by default in IIS.
It can be a little funny, but I had the same problem with normal working code. I added StreamWriter and StreamReader and it gave that error.
The solution was I took that code into comment brackets then did debug and it started to work again
If you use LibreOffice from your program via cli .net integration like me, I got the same error. I use the older version of LibreOffice on the production environment on my PC I installed a newer version that was in conflict. Just uninstall LibreOffice. I found the solution here .NET CLI: Could not load file or assembly 'cli_cppuhelper'
In my case a dependency was missing in the dll that threw this exception. I checked with Dependency Walker, added the missing dll and the problem was resolved.
More specifically, I somehow corrupted my opencv_core340.dll by accidentally adding SVN keywords to it, and thus my dll could no longer use it. However I don't believe that the solution to this problem depends on whether the dll is corrupted or missing. I'm just adding this for the sake of giving complete information.
I have detected something different from the other answers. Reaching this exception in my project was the result of a corrupt compilation. Without making any changes, just forcing rebuild, it was fixed.
I had the same issue. Project B in my case was a .Net Core Class Library which has a Nuget "Microsoft.Management.Infrastructure" installed. The error was that i called my project B "MI". I changed the project name to something else and suddenly everything worked again.
Interesting as it goes, this can also happen if the folder path is long, which can cause build issues, oddly enough with this cryptic error message.
Just moving the folder up the path, solved the problem!
Are you trying to run your .exe file from the cmd? This was my mistake. Just run the .exe file by double clicking it. If it's a .NET Core SCD for Windows 8.1/Windows Server 2012 R2 x64.
In my case the error was System.BadImageFormatException: Could not load file or assembly 'vjslib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
It was solved by installing vjredist 64 from here.