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'm using VS2019 under Windows 10 and I'm trying to figure out how to compile for the non-Windows platforms. I'm aware that only some languages support cross-compilation (C# being one of them). So I decided to start off with one of Microsoft's own examples (the Console App for .NET Core). When asking VS2019 to create the Console project, it shows me various image icons which suggest that it'll be buildable for Windows, Linux and macOS - but no matter what I do, I can only make it build the Windows target.
After a bit of research I realized that I need to add this line to my C# project file:-
<RuntimeIdentifiers>win10-x64;osx.10.11-x64;ubuntu.16.10-x64</RuntimeIdentifiers>
but even after adding that line (and re-loading / re-building the project) it staunchly refuses to build anything apart from the Windows target. Over on CodeGuru, one of the devs there tried it for me (under VS2017) and managed to make it work - but I've tried it in VS2019 and also VS2015 and I can't make it work in either of them. Any ideas what I might be doing wrong??
[Edit...]
Thanks Magnetron - if I press Build->Publish I see a totally different dialog from the one you're seeing (and it's the same in both VS2015 and VS2019):-
Even if I follow the Next or Finish buttons I never see the Create Profile option :(
Go to Build > Publish, select Folder and click on Create Profile
Then Click on Edit and change the Deployment Mode to Self-contained. At last, you can specify the target OS in Target Runtime
You can create multiple profiles for each OS, and publish each one individualy as needed.
Edit:
The posted publish dialog is for a .Net Framework Console app, not an .Net Core one. The .Net framework is Windows only, you have to create your project as a .Net Core
Woohoo!! I just ran the VS2019 installer to remind myself how to uninstall (in preparation for tomorrow) and it told me there's already a 16.3.5 available. 16.3.4 only got installed a few hours ago but for the hell of it, I figured I might as well try the newer version - and it's now working !!!
We have some code that uses Entity Framework against a DB2 database.
When we try to use transaction scope, we get a message "The Under lying provider failed on Open".
We only get this error when to run from the WPF client.
We do not get this error when we run from a unit test.
The DB2 provider is 64bit
The difference that we have been able to find is that the unit test is configured as Any CPU, but the WPF project is configured as x86.
The problem is that the Visual Studion UI does not allow us to select anything other than x86 for the WPF project.
Is this a limitation of WPF projects? If not how do we configure a WPF project as Any CPU?
Perhaps you are confusing the Visual Studio C# Platform with the Platform target?
Each Visual Studio C# project can be built to one of several platforms. This allows you to use the same project to build to several hardware platforms like 32 and 64 bit Intel/AMD CPU or even a different CPU like Itanium.
However, when you create a new project it will by default only contain a single platform, and in your case you also want to build to only a single platform, i.e. x64. For new projects the platforms used by Visual Studio are these:
A library project (including a test project) will have the Any CPU platform.
An executable project (including a WPF project) will have the x86 platform.
What is slightly confusing is that these platforms are just names hinting at what is actually built. You control what is emitted by the compiler in the Build tab of the project settings. Here you can set the Platform target to values like Any CPU, x86 or x64.
You will have to set the Platform target to x64 in your WPF project.
To fully configure your platforms you will have to use the Configuration Manager which is on the menu Build -> Configuration Manager.
There is no such limitation. You can select target in Platform Target combobox on Build page of project properties
The only x86 I wasn't able to change was the Platform, which to be honest I have no Idea what it is. but as you can see I can select x64 as the Platform target, are you sure you don't have such option?
In the latest version of Visual Studio (at least 2019) in the project properties, in the build settings, there is an option for the platform target to prefer 32-bit.
You might want to uncheck it otherwise your app will run as x32 even on a x64 machine.
The solution to this problem is very simple.
We have copied copied 64 bit console PowerShell.exe to debug folder of the current VisualStudio Project and provided the same path (.\debug RR .\debug) to trigger the powershell script, and it works fine.
How do I start using Mono in Linux as a beginner when I want to switch from Visual Studio?
Is there some easy way to install it like Visual Studio and get started?
So far,with what I've seen,it looks complex to even get started.
Installing and configuring Mono in linux is a lot of work right?
or Is there some distro which I can directly install and get started with applications in Linux?
I recently started to dabble in Mono myself and have so far realized that the MonoProject has made huge advancements in this area. It's well worth it to investigate.
With that said, the easiest method is to get setup with a Linux distro that is Mono friendly such as Suse, or Ubuntu. Personally, I tried it using Ubuntu 8.10.
Once you've got your Linux distro setup properly download and install MonoDevelop. This is an open source IDE that's tightly integrated to work with the Mono platform. MonoDevelop was taken as a branch of SharpDevelop and designed to work with the Mono compiler from the ground up.
This is by far the easiest and fastest way to get setup with Mono. The MonoDevelop IDE is very similar to that of Visual C# Express even. It comes complete with Project/Solution management, GUI development using the GTK# framework, an integrated debugger and a host of other features you would expect in an IDE such as code-completion, line numbers, code-folding etc.
The folks at the MonoProject are on to something with this suite of tools.
Hope this helps you get started.
Mono Project Homepage
Mono Develop Homepage
There are a few interesting books on Mono, although they're probably a little bit old. Still, probably it's worth to grab one and take a look in order to start up.
Practical Mono
Mono: A developer's notebook
Cross-Platform .NET development
Mono Kick-start
Then, I'd install latest Mono (2.4) on a Linux box (OpenSuse is the one they use, so it will always go smoothly for development, but we also use Ubuntu internally) and start playing around with the compiler, MonoDevelop (which is quite good since 2.0) and so on.
The only tough point will be writing GUI applications, although my team make extensively use of MWF on different Unix flavors. But everything else will go as you'd expect. I'm specially happy with how great remoting works, for instance.
If you're used to Linux then it will be much easier, otherwise I'd also recommend you getting used to it following some tutorial.
Remember tools such us NUnit and NAnt will be also available, so you can start writing your code on both Windows and Linux and testing and compiling on both platforms.
With the just released Ubuntu 9.04 a very current Mono development environment is as close as:
apt-get install monodevelop
I used to agree with you that it was somewhat difficult to get going with Mono, but the latest version of Ubuntu has melted that barrier away. And the latest version of Monodevelop is an absolute joy to use.
Don't use Ubuntu? Then I would go with Peter's advice of using a VMWare image.
For a very easy start with mono under linux u can download
a vmware image
a linux live distro
with everything included to start.
If you are accustomed to using visual-studio, you can still develop in Visual Studio, and copy your binaries to Linux/OSX or whatever. Or even better, if you have a shared drive, just reconfigure your VS-Project output directory to the shared location.
There might be advantages to using the mono compiler, or monodevelop, but since you are getting started, the above is really the easiest thing to do. If you want to run on Linux, the mono installer is an excellent option for getting up and running in a hurry. Unfortunately, there's no installer available for the newest mono release, so you'll either need admin permission, or need to compile from source.
http://ftp.novell.com/pub/mono/archive/1.9.1/linux-installer/2/mono-1.9.1_2-installer.bin
For installing newest Mono 3.2.5+ with MonoDevelop 4.2.1+ it is better is use tpokorra repository.
The simplest way I could find is to download the OpenSUSE VMWare Image on their site and just run it. You get all the tools you need :) Preconfigured.
Debian and Ubuntu, and probably all other children, have mono in the repository. So, setting up mono in Linux can be as easy as
aptitude install monodevelop
However I would suggest version 2 which requires using the 'sid' repository in Debian (don't know about Ubuntu).
vim /etc/apt/sources.list [ :%s/squeeze/sid/g ]