Develop Reference

How to fix Error HRESULT 0x8007007E on windows 10 x64 [duplicate]

I have a dll library with unmanaged C++ API code I need to use in my .NET 4.0 application. But every method I try to load my dll I get an error:
Unable to load DLL 'MyOwn.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
I have read and tried several solutions I have found on the internet. Nothing works..
I have tried using following methods:
[DllImport("MyOwn.dll", CallingConvention = CallingConvention.Cdecl)]
[return: MarshalAs((UnmanagedType.I4))]
public static extern Int32 MyProIni(string DBname, string DBuser_pass,
string WorkDirectory, ref StringBuilder ErrorMessage);
When I tried following this article and when I run this example (from the downloaded code) it runs without a problem (the dll used is in the bin/debug folder)
I have copied my dll (along with all the files the it depends on into my bin folder).
I also tried this approach but got the same error:
[DllImportAttribute(MyOwnLibDllPath, EntryPoint="TMproIni")]
[return: MarshalAs(UnmanagedType.I4)]
public static extern int MyproIni(string DBname, string DBuser_pass,
string WorkDirectory, ref StringBuilder ErrorMessage);
Any suggestions?

From what I remember on Windows the search order for a dll is:
Current Directory
System folder, C:\windows\system32 or c:\windows\SysWOW64 (for 32-bit process on 64-bit box).
Reading from the Path environment variable
In addition I'd check the dependencies of the DLL, the dependency walker provided with Visual Studio can help you out here, it can also be downloaded for free: http://www.dependencywalker.com

You can use the dumpbin tool to find out the required DLL dependencies:
dumpbin /DEPENDENTS my.dll
This will tell you which DLLs your DLL needs to load. Particularly look out for MSVCR*.dll. I have seen your error code occur when the correct Visual C++ Redistributable is not installed.
You can get the "Visual C++ Redistributable Packages for Visual Studio 2013" from the Microsoft website. It installs c:\windows\system32\MSVCR120.dll
In the file name, 120 = 12.0 = Visual Studio 2013.
Be careful that you have the right Visual Studio version (10.0 = VS 10, 11 = VS 2012, 12.0 = VS 2013...) right architecture (x64 or x86) for your DLL's target platform, and also you need to be careful around debug builds. The debug build of a DLL depends on MSVCR120d.dll which is a debug version of the library, which is installed with Visual Studio but not by the Redistributable Package.

The DLL has to be in the bin folder.
In Visual Studio, I add the dll to my project NOT in References, but "Add existing file". Then set the "Copy to Output Directory" Property for the dll to "Copy if newer".

This is a 'kludge' but you could at least use it to sanity-test:
Try hard-coding the path to the DLL in your code
[DllImport(#"C:\\mycompany\\MyDLL.dll")]
Having said that; in my case running dumpbin /DEPENDENTS as suggested by #anthony-hayward, and copying over 32-bit versions of the DLLs listed there into my working directory solved this problem for me.
The message is just a bit misleading, becuase it isn't "my" dll that can't be loaded - it's the dependencies

Try to enter the full-path of the dll.
If it doesn't work, try to copy the dll into the system32 folder.

"Unable to load DLL 'xxx.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)" means the file CAN be found BUT it's not able to load it. Try to copy the DLL file to the root folder of your application, some DLL libraries need to be available in the root folder of the application in order for it to work. Or check if there are any other depending DLL files required by it.
"Cannot find DLL 'xxx.dll': ..." means the file CANNOT be found. Try to check the path. For example, [DllImport(#"\Libraries\Folder\xxx.dll")]

Ensure that all dependencies of your own dll are present near the dll, or in System32.

Turn on the fusion logging, see this question for lots of advice on how to do that. Debugging mixed-mode apps loading problems can be a right royal pain. The fusion logging can be a big help.

Make sure you set the Build Platform Target to x86 or x64 so that it is compatible with your DLL - which might be compiled for a 32 bit platform.

There is one very funny thing (and has a technical relevance) which might waste your hours so thought of sharing it here -
I created a console application project ConsoleApplication1 and a class library project ClassLibrary1.
All the code which was making the p/invoke was present in ClassLibrary1.dll. So before debugging the application from visual studio I simply copied the C++ unmanaged assembly (myUnmanagedFunctions.dll) into the \bin\debug\ directory of ClassLibrary1 project so that it can be loaded at run-time by the CLR.
I kept getting the
Unable to load DLL
error for hours. Later on I realized that all such unmanaged assemblies which are to be loaded need to be copied into the \bin\debug directory of the start-up project ConsoleApplication1 which is usually a win form, console or web application.
So please be cautious the Current Directory in the accepted answer actually means Current Directory of main executable from where you application process is starting. Looks like an obvious thing but might not be so at times.
Lesson Learnt - Always place the unamanaged dlls in the same directory as the start-up executable to ensure that it can be found.

I had the same problem when I deployed my application to test PC. The problem was development PC had msvcp110d.dll and msvcr110d.dll but not the test PC.
I added "Visual Studio C++ 11.0 DebugCRT (x86)" merge module in InstalledSheild and it worked. Hope this will be helpful for someone else.

In my case one unmanaged dll was depending on another which was missing. In that case the error will point to the existing dll instead of the missing one which can be really confusing.
That is exactly what had happen in my case. Hope this helps someone else.

If the DLL and the .NET projects are in the same solution and you want to compile and run both every time, you can right click the properties of the .NET project, Build events, then add something like the following to Post-build event command line:
copy $(SolutionDir)Debug\MyOwn.dll .
It's basically a DOS line, and you can tweak based on where your DLL is being built to.

I think your unmanaged library needs a manifest.
Here is how to add it to your binary. and here is why.
In summary, several Redistributable library versions can be installed in your box but only one of them should satisfy your App, and it might not be the default, so you need to tell the system the version your library needs, that's why the manifest.

Setup: 32-bit Windows 7
Context: Installed a PCI-GPIB driver that I was unable to communicate through due to the aforementioned issue.
Short Answer: Reinstall the driver.
Long Answer:
I also used Dependency Walker, which identified several missing dependency modules. Immediately, I thought that it must have been a botched driver installation. I didn't want to check and restore each missing file.
The fact that I was unable to find the uninstaller under Programs and Features of the Control Panel is another indicator of bad installation. I had to manually delete a couple of *.dll in \system32 and registry keys to allow for driver re-installation.
Issue fixed.
The unexpected part was that not all dependency modules were resolved. Nevertheless, the *.dll of interest can now be referenced.

I have come across the same problem, In my case I had two 32 bit pcs.
One with .NET4.5 installed and other one was fresh PC.
my 32-bit cpp dll(Release mode build) was working fine with .NET installed PC but Not with fresh PC where I got the below error
Unable to load DLL 'PrinterSettings.dll': The specified module could not be
found. (Exception from HRESULT: 0x8007007E)
finally,
I just built my project in Debug mode configuration and this time my
cpp dll was working fine.

Also faced the same problem when using unmanaged c/c++ dll file in c# environment.
1.Checked the compatibility of dll with 32bit or 64bit CPU.
2.Checked the correct paths of DLL .bin folder, system32/sysWOW64 , or given path.
3.Checked if PDB(Programme Database) files are missing.This video gives you ans best
undestand about pdb files.
When running 32-bit C/C++ binary code in 64bit system, could arise this because of platform incompatibility. You can change it from Build>Configuration manager.

I faced the same problem when import C++ Dll in .Net Framework +4, I unchecked Project->Properties->Build->Prefer 32-bit and it solved for me.

It has nothing to do with dependencies if you checked all dependencies and you know you got them all, it has nothing to do with the file being in the wrong directory either or incorrect ARGUMENTS passed to dll, the DLL Fails to load using LoadLibrary itself.. you could check the address returned from LoadLibrary is always 0x0000000 (not loaded).
I couldn't figure this error out either it worked fine on Windows 7, but on Windows 10 it doesn't work. I fixed the problem though it had nothing to do with missing dependencies or Runtime redistributable packs.
The problem was I had to pack the DLL with upx and it started working again.
Something with the file being unpacked and compiled on old Windows XP operating system created a bad PE Header or Bad file format or something, but packing it with UPX did the trick works fine now and the DLL got 3x smaller haha.

I got this error for one C++ project in our solution, and only on our buildmaster's machine. The rest of us could build it with no problem.
In our case it was because that particular project had <WindowsTargetPlatformVersion> in the .vcxproj file set to "10.0" vs. "10.0.18362.0" as in all our other C++ projects.
Not specifying the entire SDK version number seems to have allowed MSBuild to choose the newest(?) SDK and associated build tools.
Our buildmaster likely had the remnants of a newer SDK on his machine, and MSBuild was trying to use it (and thus RC.exe was not found).
In any case, bringing up the project's property page and changing Configuration Properties > General > Windows SDK Version to "10.0.18362.0" (or whichever specific version of the SDK you have installed) for all of the project's configurations/platforms did the trick.

Unable to load libraries (.dll) in a C# Website Application

We have a .Net application that successfully "load" .dll libraries from a specific folder in Windows Operative System. The .Net framework we have been using so far is 4.6. All the .dll libraries that the application loads were compiled in x86. The following code is an excerpt of how we are loading the libraries and getting their types:
1. try{
2. AssemblyFileDescriptor assemblyFile = new AssemblyFileDescriptor(assemblyPath);
3. var assm = Assembly.LoadFrom(assemblyPath);
4. var types = assm.GetExportedTypes();
5. ...
6. }catch (Exception e) {
7. ...}
The libraries in a specific folder, let's say
C:\Program Files (x86)\FOLDER
, are loading to the variable assm without any exception. The problem occurs when we migrated our .Net "stand alone" application to a website application with a Web.config file. In the website application, the load function fails when getting the types. Then the 4th line throws the exception. We have been using the ISS Express.
We have already tried:
Using a different Load function such as "UnsafeLoadFrom".
Re-compiling all the .dll libraries in x86 and x64.
Setting up different configurations for the Web.Config file such as including <trust level="Full" /> or <loadFromRemoteSources enabled="true" />.
Debugging the loading function of each library. Some of them can load successfully, but there are others that throw a Loading Exception.
Setting in the ISS Express "True" the variable "Enable 32-bit applications".
The specific error states "System.Reflection.ReflectionTypeLoadException":
Any idea of how tackling this issue? Let me know if you need further information.

I'm guessing you're running this under IIS, and IIS usually runs as a different user than you (usually IUSR), and usually has limited permissions. Converting a standalone program to an ASP.NET program changes a lot of things in subtle ways. I'd check to make sure you aren't running into a file-permission issue because IIS is a restricted user.
Also, as others pointed out, you should probably provide the exception details (at least its typename and message) so people don't have to guess at it.

According to the answers of this question and several loading experiments that we had been performing in the website application. We observed a pattern related to the framework version that we used for compiling the DLLs and the ReflectionTypeLoadException. Some DLLs were compiled with framework 3.5, this version does not allow loading libraries in ISS with .Net CLR2. Then, we must rebuild all the DLLs and their dependencies with a higher version of the framework (.Net v4.0). Finally, we re-loaded the updated DLLs in ISS express with .NET CLR4. The DLLs were loaded without any exception.

Oracle.DataAccess.Client Dependencies

First of all, I want to use the Oracle.DataAccess.dll to use OracleBulkCopy.
I want to know all the dlls that I need to be able to read from a database and then perform a bulkcopy in Oracle. Currently, we are using only one dll to perform all the reads from databases, we are using Oracle.ManagedDataAccess.Client. But I can't use it to perform a bulkCopy.
I don't want to install ODP.NET for the users, I want to include the dll directly in the program. So I want to know the minimum required dlls to be able to use the Oracle.DataAccess.dll in 32bit and in 64bit.
I know that there are some old post about this, but it's quiet old and the listed dlls are out of date. I can't event find some of them.
I installed the ODP.net for ODAC12 and I retreived all the listed dlls in this post. I also tried with with this post. The listed dlls are pointing out the version 11.
I made a dummy project that opens a connection, reads a table and bulk it in another table. I copied the listed dlls from the posts in the root of the project and I included Oracle.DataAccess.dll in the project.
When I run my program in 64 bit I get the following error:
Could not load file or assembly 'Oracle.DataAccess, Version=4.121.2.0,
Culture=neutral, PublicKeyToken=89b483f429c47342'
When I run it in 32 bit, I get this error:
Unable to load DLL 'OraOps12.dll': The specified module could not be
found. (Exception from HRESULT: 0x8007007E)"
The dlls that I included are:
oci.dll
ociw32.dll
Oracle.DataAccess.dll
orannzsbb12.dll
oraocci12.dll
oraociei12.dll
OraOps12.dll

I managed to make it work.
Download the good version of the ODAC that will target your project.
For a 32bit project you need to download the ODAC12..._x32.zip (ODAC121021Xcopy_32bit.zip).
For the 64bit project you need to download the ODAC12..._x64.zip
Unzip it in an empty folder depending on the version you want (32bit vs 64bit).
Locate in the instantclient_12_1 folder all the dlls by searching *.dll in the windows search bar. You need to grab:
oci.dll
ociw32.dll
orannzsbb12.dll
oraociei12.dll
oraons.dll
Locate in the odp.net4 or odp.net20 folder depending on your .NET version this two dlls:
OraOps12.dll
Oracle.DataAccess.dll
Copy the those 32bit dlls or 64bit dlls and put them directly in the Output path of your project. For example in C:\...\vsProjects\BulkInsert\BulkInsert\bin\Debug.
Browse Oracle.DataAccess.dll in your project by pointing on the Output path.
UPD: recent versions of the ODP.NET provider (downloaded from here) have "19" suffix instead of "12" in their filenames:
oci.dll
ociw32.dll
orannzsbb19.dll
oraociei19.dll
oraons.dll
OraOps19.dll
Oracle.DataAccess.dll

I experienced similar problem; install oracle data access components (odac ODTwithODAC122010.zip) for solution.

Looks like you did not install the Oracle Instant client (or any other version of Oracle Client). This is a prerequisite for unmanaged ODP.NET provider.
Install the Oracle Instant client and you are fine. Otherwise you will get nothing but trouble.

Connecting to Oracle DB from .NET/C#

After finding this tutorial, I downloaded and extracted the files needed. But when I try to add their reference I get this error message:
A Reference to '..\oci.dll' could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.
Any help with this?

You should download and install ODP.NET (Oracle Data Provider for .NET)
http://www.oracle.com/technetwork/topics/dotnet/index-085163.html
For deployment look at the http://www.oracle.com/technetwork/issue-archive/2008/08-nov/o68odpnet-101744.html, but basically is xcopy deployment as V4Vendetta noted
Update: Client application need these dll's (32 bit version):
oci.dll
Oracle.DataAccess.dll
oraociei11.dll
OraOps11w.dll

Error message 'Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.'

I have developed an application using Entity Framework, SQL Server 2000, Visual Studio 2008 and Enterprise Library.
It works absolutely fine locally, but when I deploy the project to our test environment, I am getting the following error:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information
Stack trace: at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)
at System.Reflection.Assembly.GetTypes()
at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadTypesFromAssembly(LoadingContext context)
at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.InternalLoadAssemblyFromCache(LoadingContext context)
at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache(Assembly assembly, Boolean loadReferencedAssemblies, Dictionary2 knownAssemblies, Dictionary2& typesInLoading, List`1& errors)
at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache(ObjectItemCollection objectItemCollection, Assembly assembly, Boolean loadReferencedAssemblies)
at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType(Type type)
at System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType(Type type, Assembly callingAssembly)
at System.Data.Objects.ObjectContext.CreateQuery[T](String queryString, ObjectParameter[] parameters)
Entity Framework seems to have issue, any clue how to fix it?

This error has no true magic bullet answer. The key is to have all the information to understand the problem. Most likely a dynamically loaded assembly is missing a referenced assembly. That assembly needs to be in the bin directory of your application.
Use this code to determine what is missing.
using System.IO;
using System.Reflection;
using System.Text;
try
{
//The code that causes the error goes here.
}
catch (ReflectionTypeLoadException ex)
{
StringBuilder sb = new StringBuilder();
foreach (Exception exSub in ex.LoaderExceptions)
{
sb.AppendLine(exSub.Message);
FileNotFoundException exFileNotFound = exSub as FileNotFoundException;
if (exFileNotFound != null)
{
if(!string.IsNullOrEmpty(exFileNotFound.FusionLog))
{
sb.AppendLine("Fusion Log:");
sb.AppendLine(exFileNotFound.FusionLog);
}
}
sb.AppendLine();
}
string errorMessage = sb.ToString();
//Display or log the error based on your application.
}

I solved this issue by setting the Copy Local attribute of my project's references to true.

One solution that worked for me was to delete the bin/ and obj/ folders and rebuild the solution.
Update:
Or you can try to right-click the Solution node in the "Solution Explorer" and click "Clean Solution", then click "Rebuild Solution" (thanks Emre Guldogan)

Two possible solutions:
You are compiling in Release mode but deploying an older compiled version from your Debug directory (or vise versa).
You don't have the correct version of the .NET Framework installed in your test environment.

As it has been mentioned before, it's usually the case of an assembly not being there.
To know exactly what assembly you're missing, attach your debugger, set a breakpoint and when you see the exception object, drill down to the 'LoaderExceptions' property. The missing assembly should be there.
Hope it helps!

The solution was to check the LoaderException: In my case, some of the DLL files were missing.

Make sure you allow 32 bits applications on IIS if you did deploy to IIS. You can define this on the settings of your current Application Pool.

I encountered this error with an ASP.NET 4 + SQL Server 2008 R2 + Entity Framework 4 application.
It would work fine on my development machine (Windows Vista 64-bit). Then when deployed to the server (Windows Server 2008 R2 SP1), it would work until the session timed out. So we'd deploy the application and everything looked fine and then leave it for more than the 20 minute session timeout and then this error would be thrown.
To solve it, I used this code on Ken Cox's blog to retrieve the LoaderExceptions property.
For my situation the missing DLL was Microsoft.ReportViewer.ProcessingObjectModel (version 10). This DLL needs to be installed in the GAC of the machine the application runs on. You can find it in the Microsoft Report Viewer 2010 Redistributable Package available on the Microsoft download site.

My instance of this problem ended up being a missing reference. An assembly was referred to in the app.config but didn't have a reference in the project.

Initially I tried the Fusion log viewer, but that didn't help
so I ended up using WinDbg with the SOS extension.
!dumpheap -stat -type Exception /D
Then I examined the FileNotFoundExceptions. The message in the exception contained the name of the DLL that wasn't loading.
N.B., the /D give you hyperlinked results, so click on the link in the summary for FileNotFoundException. That will bring up a list of the exceptions. Then click on the link for one of the exceptions. That will !dumpobject that exceptions. Then you should just be able to click on the link for Message in the exception object, and you'll see the text.

If you're using the EntityDataSource in your project, the solution is in Fix: 'Unable to load one or more of the requested types' Errors. You should set the ContextTypeName="ProjectNameNameSpace.EntityContainerName" '
This solved my problems...

Another solution to know why exactly nothing works (from Microsoft connect):
Add this code to the project:
foreach (var asm in AppDomain.CurrentDomain.GetAssemblies())
{
asm.GetTypes();
}
Turn off generation serialization assemblies.
Build and execute.

If you are using Entity Framework, try copying the following references locally.
System.Data.Entity
System.Web.Entity
Change the property "Copy Local" to "True" for these references and publish.

I had a .NET 4.0, ASP.NET MVC 2.0, Entity Framework 4.0 web application developed in Visual Studio 2010. I had the same problem, that it worked on one Windows Server 2008 R2 server but not on another Windows Server 2008 R2 server, even though the versions of .NET and ASP.NET MVC were the same, throwing this same error as yours.
I went to follow miko's suggestion, so I installed Windows SDK v7.1 (x64) on the failing server, so I could run !dumpheap.
Well, it turns out that installing Windows SDK v7.1 (x64) resolved the issue. Whatever dependency was missing must have been included in the SDK. It can be downloaded from Microsoft Windows SDK for Windows 7 and .NET Framework 4.

Adding my specific problem/solution to this as this is the first result for this error message. In my case, the error was received when I deployed a second application within the folder of my first application in IIS. Both were defining connection string with the same name resulting in the child application having a conflict and in turn generating this (to me) non-obvious error message. It was solved by adding:
<clear/>
in the connection string block of the child web application which prevented it from inheriting the connection strings of web.config files higher in the hierarchy, so it looks like:
<connectionStrings>
<clear/>
<add name="DbContext" connectionString="MySERVER" providerName="System.Data.SqlClient" />
</connectionStrings>
A reference Stack Overflow question which helped once I determined what was
going on was Will a child application inherit from its parent web.config?.

This worked for me. Add it in your web.config
<system.web>
<trust level="Full" />

My issue has been resolved after I deleted the redundant assembly files from the bin folder.

In case none of the other answers help you:
When I had this problem, it turned out my Windows service was built for an x64 platform, and I was inadvertently running the 32-bit version of InstallUtil.exe. So make sure you're using the right version of InstallUtil for the platform you built for.

Other suggestions are all good. In my case, the problem was that the developer box was a 64-bit machine using the x86 location of various APIs, including Silverlight.
By changing the target platform to match the 32-bit server where the web application was being deployed removed the majority of the errors related to not being able to load one or more of the requested types.

I changed the Specific Version Property of the Refrences to false and that helped.

I had the same error message reported when compiling a Visual Studio package (VSPackage). The whole solution compiles and the error is thrown when the package is being created by CreatePkgDef. Having said that, it is clear that I cannot catch the LoaderExceptions as it is not my application that throws it, but Microsoft's own tool. (Though I am responsible for the confusion of CreatePkgDef.)
In my case the root cause was that my solution creates a MyDll.dll that has already been registered to the GAC (and they are different), so the CreatePgkDef got confused which one to use and it decided just to throw an error which isn't really helpful. The MyDll.dll in the GAC was registered by the installer of the same product (obviously an earlier version, with /slightly/ different content).
How to fix it
Preferred way: Make sure you use the correct version of MyDll.dll
When compiling your project make sure you use a different version number than you used in the previous version located in the GAC. Make sure the following attributes are correct:
[assembly: AssemblyVersion("1.0.0.1")] // Assuming the old DLL file was versioned 1.0.0.0
[assembly: AssemblyFileVersion("1.0.0.1")] // Assuming the old DLL file was versioned 1.0.0.0
If needed, specify the fully qualified assembly name (for example, "MyDll.dll, Version=1.0.0.1, Culture=neutral, PublicKeyToken=1234567890abcdef") when you reference it in your other projects.
If the above failed: You can uninstall the old MyDll.dll from GAC
How to Uninstall an Assembly from the GAC
Uninstall the application that includes MyDll.dll
Changing the AssemblyVersion was good enough for me. :)
I hope this was helpful.

I had the same issue (but on my local) when I was trying to add Entity Framework migration with Package Manager Console.
The way I solved it was by creating a console application where Main() had the following code:
var dbConfig = new Configuration();
var dbMigrator = new DbMigrator(dbConfig);
dbMigrator.Update();
Make sure the Configuration class is the migration Configuration of your failing project. You will need System.Data.Entity.Migrations to use DbMigrator.
Set a breakpoint in your application, and run it. The exception should be caught by Visual Studio (unless you have that exception type set to not break the debug session), and you should be able to find the info you are looking for.
The missing reference in my case was EFProviderWrapperToolkit.

I got this problem when I installed a NuGet package on one of the projects and forgot to update the other project.
I solved this by just making both projects having the same reference assembly.

It happened for me also. I solved the problem as follows:
Right click Solution, Manage NuGet Packages for Solution...
Consolidate packages and upgraded the packages to be in the same version.

I had this issue while referencing a nuget package and later on using the remove option to delete it from my project. I had to clear the bin folder after battling with the issue for hours. To avoid this its advisable to use nuget to uninstall unwanted packages rather than the usual delete

Set 32 bit IIS mode to true, debug mode to true in the configuration file, deleting the temp directory and resetting IIS fixes the issue temporally and it comes back after some time.

Verify that each of your projects is setup correctly in the Configuration Manager.
Similar to William Edmondson's reason for this issue, I switched my Configuration Manager setting from "Debug" "Any CPU" to "Debug" ".NET". The problem was that the ".NET" version was NOT configured to build ALL of the projects, so some of my DLLs were out of date (while others were current). This caused numerous problems with starting the application.
The temporary fix was to do Kenny Eliasson's suggestion to clean out the \bin and \obj directories. However, as soon as I made more changes to the non-compiling projects, everything would fail again.

I also got this issue when create new Microsoft Word add-in with Visual Studio 2015. The issue is about I have 2 versions of MS Office, 2013 and 2016. I uninstall MS Office 2013 and then it works.

I build a few projects for SharePoint and, of course, deployed them. One time it happened.
I found an old assembly in C:\Windows\assembly\temp\xxx (with FarManager), removed it after reboot, and all projects built.
I have question for MSBuild, because in project assemblies linked like projects and every assembly is marked "Copy local", but not from the GAC.

I am able to fix this issue by marking "Copy Local=True" on all referenced DLL files in the project, rebuilding and deploying on a testing server.