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
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
In my case changing IIS Express Bitness from "Default" to "x86" helped.
All my projects had "x86" as the Platform target.
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.
I am somewhat new to using the Global Assembly Cache in .NET, and have a question regarding how it works since I haven't been able to find anything online.
My msi(created using Visual Studio Installer extension (using Visual Studio 2015)) installs a number of assemblies into the GAC and my application(the assemblies need to be in the GAC because 3rd party application need to access them too). After running the installer and starting the application, I noticed that when I start my application, copies of the dlls from the GAC are made in the application execution directory.
My question is, is this how using assemblies from GAC normally works? I assumed that the assemblies would just be loaded from the GAC without making local copies. Or is this some error on my part and how I built my application(CopyLocal is set to true but from what I understand, this only matters for Visual Studio and has no effect on actual execution after deployment).
Based on Hans' input, the issue is with my msi and is not GAC related. While msi installs the assemblies to GAC and not the execution directory, when the application is run it is msi "self-healing" that creates the files, they are not copied from GAC.
I have a perfectly working windows forms C# .NET 4 application that uses a SQLite3 database file to store data and display forms.
When I deploy my app on any machine other then the dev machine, I get an exception thrown and it's message is "Could not load assembly System.Data.SQLite.dll or one of its dependencies. The specified module could not be found."
The System.Data.SQLite.dll reference in the project is set to Copy Local = True. Also, I tried manually loading the assembly with Assembly.LoadFile. The dll is placed in the output directory. I also tried setting the platform target to Any CPU as well as x86, no difference. All machines I am working with are 32-bit. What is the issue here? Why is my application trying to load the assembly and can't find it?
Thanks!
I had the same problem after publishing my program to a separate computer. Installing Microsoft Visual C++ 2010 Redistributable Package (x86) on the separate computer fixed the problem.
Note: the separate computer already had Microsoft Visual C++ 2010 Redistributable Package (x64) installed, the x86 version was needed.
'System.Data.SQLite.dll" requires "msvcr100.dll" which is one of it's Dependencies. This will be available only if you installed latest "Microsoft Visual C++ Redistributable" or any other product which internally provides this.
For example, VS2010 will install C++ Redistributable by default. Thats the reason your application doesnot works in some machine but works in others.
You could try pasting the "msvcr100.dll" in your application bin folder and distribute if you dont want to install VC++ 2010 Redist in all the PC's.
Some of the System.Data.Sqlite.dll modules depend on the "Microsoft Visual C++ 2012 Redistributable Package" .
You can find required dependencies on the official download page : http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
The answers already given didn't solve my problem. I tried to deploy to a VMware server. The solution that did help where given here: http://sqlite.1065341.n5.nabble.com/System-Data-SQLite-Deployment-Mystery-td71752.html Two methods are described there.
When i install this sqlite-netFx45-setup-bundle-x86-2012-1.0.88.0.exe, my app is able to find the right dll.
The second method is to add the dll to de app.exe.config in the debug or release dir. If you edit this file directly, there is a change VC will overwrite the file.
My main problem was that i installed the sqlite package manually. I didn't use NuGet, because i'm behind a proxy. If you do use Nuget, the information in the app.exe.config will be provided automatically.
Using NuGet behind a proxy is described here: NuGet Behind Proxy
I have developed an application using C# (Visual Studio) which runs without issue on my Windows 10 development PC. However, when I copy the application to its intended target PC and run it (Server 2012 R2), I get an exception informing me that a file or assembly could not be loaded: Microsoft.SqlServer.ConnectionInfo, Version=13.100.0.0.
If I copy version 13 of the dll to the program directory of the target PC and run the app, I then get an exception informing me that it cannot find version 14 of the dll. Copying version 14 to the target then give me the original exception, and so on.
I have references to all the required dlls in the application, namely:
Microsoft.SqlServer.ConnectionInfo.dll (the one which is giving me
the issue). Microsoft.SqlServer.Management.Sdk.Sfc.dll
Microsoft.SqlServer.Smo.dll Microsoft.SqlServer.SqlClrProvider.dll
Microsoft.SqlServer.SqlEnum.dll Microsoft.Web.Administration.dll
All are set as: specific version = false.
All of the necessary frameworks are installed on the server. Additionally, the following is also installed on the server, which the program interacts with:
• ColdFusion
• SQL Server 2012 (and 2008 but this instance is not used by the program)
The .exe is installed via an installer and that installation includes the necessary dlls, which are installed in the same directory as the exe.
Full permissions are available on the directory, and the program itself has the highest access level.
The connection string is selectable by the user and defaults to the correct one, depending on where the program is installed.
Does anyone have any ideas which may help me to resolve this conflict?
Thanking everyone in advance.
Regards,
Ken.
ADDITIONAL INFORMATION
The version number of Microsoft.SqlServer.ConnectionInfo.dll shown within Visual Studio is 13.100.0.0. I copied the DLL from the path shown in properties, to the program directory. Guess what? When I ran the program an exception informed me that it could not find version 14.100.0.0!
This is the version of the same DLL as shown on the file's Properties page: 13.0.16106.4.
SMO is always installed in the GAC, so it doesn't matter what files you copy to your /bin folder. GAC'd assemblies override local ones.
You have referenced the SQL 2016 version of SMO. So you must either install that on your target server, or build you project against the version of SMO already present on the target server.
See
https://learn.microsoft.com/en-us/sql/relational-databases/server-management-objects-smo/files-and-version-numbers
Note that because of the hassles with loading and deploying SMO, and SMO's really old API style, it's often better to have your app perform SQL Server administration with just TSQL and System.Data.SqlClient.
[RESOLVED]
Dumbassary was afoot.
I removed all the references from the Visual Studio project, re-added them and it worked.
The issue was caused by a DLL reference which was pointing to the program's installation directory and not to C:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies. As the Properties box was not fully expanded, I failed to notice it.
Hopefully, someone else can benefit from my experience.
Thank you for your comment David.
I downloaded setup.exe, and then begin to install and it immediately crashes.
On win7 it worked fine. On XP it doesn't work.
Error text:
Unable to install or run the
application. The application requires
that assemble stdole Version
7.0.3300.0 be installed in the Global Assembly Cache (GAC) first.
You'll need to include stdole.dll as a required file in your Publish settings in Visual Studio. Once you publish your app again, it should then include that file in your app when it's installed.
More info can be found here.
This happened to a few people that i had to install a click once application i developed. Basically something happened in their installation of .NET and the needed .DLL's were not moved to the GAC. It's very simple to fix, basically You need to copy stdole.dll from C:\Program Files\Microsoft.NET\Primary Interop Assemblies\ to C:\Windows\Assembly ... that should fix your issue. Including them in the application isn't the best idea, this will fix it for ALL click once applications rather then just that one you are currently building.
P.S. Dragging the files to the location will work, you might get an error if you try to copy it.