We Keep Coding

Visual Studio 2019 Error - Could not load file or assembly or one of its dependencies

I have some trouble with running my project. When I try to run, the following error appears:
FileNotFoundException: Could not load file or assembly 'Dapper,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. The system cannot find the file specified
Context:
I have a Class Library X and a Web Application Y which have dependencies on X. When I try to run my API project, it throws the above error.
BUT, when my colleagues try to run the same API project, it works fine (no errors, and in /bin folder, it loads all the .dll libraries..)
I did those approaches:
Restart Visual Studio, clean and build a solution
Remove the class library references and add it again
Tools > Import and Export Settings Wizard > Reset all settings (maybe some setting was not well configured). I also tried to import colleague settings and didn't work either.
I tried various approaches(even in a different machine, but same VS settings) but none of these worked for me.
Visual studio 2019 16.4 Enterprise.

I'd also try:
1) Deleting your bin and obj folders in your solution before a rebuild.
2) Check that you've not got multiple versions of the same package across the solution (right click on solution in solution explorer -> manage nuget packages for solution).
3) Check that the properties of the reference (right click in solution explorer on the reference in question) shows a path to the package that you'd expect relative to the solution (eg not in mydocuments/nuget packages or something!).
4) Try a fresh clone of the repo (this should in effect replicate your co-workers' set up) and see if the problem still exists then.
I suppose another cause could be that your coworkers have a locally installed package / dll that they're happily referencing without realising, but you don't have?

When you copy a project from someone or another system, you need to download and install all components. normally VS will give you the option to "restore packages" when you load a newly imported from git but not sure if it does when you open an existing solution from a different system.
Right Click your project, Manage Nuget Packages
Browse -> Search for Dapper. Install
In the error you receieve, it tells you what version of the package should be installed as well. Installing a significantly different version might cause other unexpected errors.

thank you for your solutions but I found the problem:
The project solution has some projects with .net standard 2.0 and some with .net framework 4.8. Somehow, when I run the app, some packages are not loaded correctly and it throws an error.
That line below solved my problem:
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
Put it in all .net framework 4.8 projects on first XML tag.
Thank your for all.
Regards.

I had exactly the same Dapper error message today when referencing a .Net Standard 2.1 class library in a .Net Core 3.1 WinForm app. My resolution was to double-click the class library name in Solution Explorer to open the .csproj file, and then add a CopyLocalLockFileAssemblies tag to the PropertyGroup tag and setting it to true.

MSBuildWorkspace.OpenSolutionAsync(solutionPath) fails to compile because of processor architecture mismatches

In Visual Studio 2017 I created a Stand-Alone Code Analysis Tool project targeting 4.6.2. I used the templated code as-is except that I specified the .sln file for the workspace.OpenSolutionAsync() call.
The solution I am attempting to compile with this Roslyn method contains both projects where Platform=Any CPU, and projects where Platform=x64. The solution compiles fine in VS2017 when set to Mixed Platforms.
However, the OpenSolutionAsync() call generates several of these compile errors:
Msbuild failed when processing the file 'C:\MyProj.csproj' with message: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets: (2110, 5): There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\MyUnmanagedLibrary.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
Why is it complaining about x86 when the MyUnmanagedLibrary project has been set to build using Platform=x64 in the Configuration Manager? How do I resolve this? This code was working fine one day ago and to the best of my knowledge nothing has changed except that I copied code to a different directory on my PC.

The cause of this behavior was that some of my projects had an output path of bin\Debug\, and others had an output path of bin\x64\Debug. However, the build process performed when you call OpenSolutionAsync() appears to assume bin\Debug. It was finding old x86 versions of DLLs in bin\Debug\ folders instead of looking at the DLLs in bin\64\Debug\ folders. Once I changed all the projects' output paths to bin\Debug\, the OpenSolutionAsync() process worked fine.

Portable Class Library and code analysis ca055/ca0052

I read the following both articticles about the using of portable class library(PCL) in application design:
http://www.dotnetcurry.com/showarticle.aspx?ID=843
and
http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx
I created an PCL and a unit test project to test the PCL. I build everything with my visual studio 2012 and it works great, i was also able to start my application using this PCL.
I use a TFS for source controll and nightly tests.
If i try to build the the unit test project or my apllication via TFS i retrieve two errors:
CA0055 : * Could not load file: 'C:...\MyPCL.dll'.
CA0052 : No targets were selected.
The PCL use .Net Framework 4.5 and .Net for Windows Store apps as targets and all projects which are no PCL are configured to use .Net Framework 4.5. I does not use any other reference as the default ".Net Protable Subset" reference.
If i check the build server there is a compiled and working version of my PCL.
If i disable the code analysis while building there are no errors and all unit test works fine.
But it is no solution for me to disbale the code analysis. So has anybody an idea why it crashed and how to get it working with code analyse?

I ran into the same problem after renaming the project. Check the AssemblyInfo.cs file, make sure the assemblyTitle is correct. Better to have it same as the project name, and is not conflicting with any other projects

Is your local build working fine when code analysis is enabled in Visual Studio?
If yes then one of the possible reason for this issue can be build output path in TFS Build. In local builds, output files are generated in bin directory of respective projects where as in TFS Build all the project output files are copied in binaries directory.

Switching from 32bit to 64bit results in Metadata not found?

My solution contains a lot of project, when switching from AnyCPU(32bit) to x64 I get alot of Metadata file X could not be found?
To build all projects in x64 I use the Configuration Manager where I set it to release and x64.

Sometimes the trouble is caused by references between projects where the project dependencies are not updated. You can confirm them under Project -> Project Dependencies for each project giving trouble.

Setup targeting both x86 and x64?

I have a program that requires both x64 and x86 dlls (it figures out which ones it needs at run time), but when trying to create a setup, it complains:
File AlphaVSS.WinXP.x64.dll' targeting 'AMD64' is not compatible with th project's target platform 'x86'
File AlphaVSS.Win2003.x64.dll' targeting 'AMD64' is not compatible with th project's target platform 'x86'
File AlphaVSS.Win2008.x64.dll' targeting 'AMD64' is not compatible with th project's target platform 'x86'
How can I make my setup target both platforms like my program does?

The MSI created by the setup project (in Visual Studio) can only target one platform at a time. Your option is to either make 2 MSI's, merge them together and make a custom setup boot strapper that choose between the two.
There are some 3rd party products,like Advanced Installer for example, that can do this for you.

I ran into this too and wrote a blog post about my solution:
deflate the file using deflate.exe, naming it with a different extension (e.g. .x64)
add it to your main project as a content file
add a custom action project to your solution
add the custom action to the setup projects "Install" custom actions
inflate the file inside the custom actions Install method using
System.IO.Compression.DeflateStream (see code above)
do a little dance around your desk, down the hall, and past as many coworkers as you care to annoy :)
The deflate.exe file can be downloaded from its repository on google code.

.Net has an "Any CPU" option. It's tempting to think of it as more of a "generic" option that's going to only use the lesser x86 features, but really it lets the JIT compiler on each machine pick the appropriate cpu type for that machine.
The only time you shouldn't use it is if you know you have dependencies or requirements that aren't good for one architecture or the other. For example: you know you need a lot of ram, you have a dependancy on a 32-bit native dll, or you want to pre-compile the app.
There's a danger here because you have a platform-specific dll dependancy. But you have dlls for both types and it sounds like you know how to pick the right one at runtime. So will the 'Any CPU' option work for you?

Open a deployment project.
In the Solution Explorer, select the deployment project.
In the Properties window, select the TargetPlatform property.
Choose either Itanium for an Intel Itanium 64-bit platform, or x64 for any other 64-bit platform (such as AMD64 and EM64T instruction sets).
At installation time, an error will be raised and installation will be halted if the target computer is not compatible with the specified platform.