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've written a large C# 4.0 App in Visual Studio 2010. Some time ago I added the CEF framework (version 43.0.0.0) in order to utilize a web-browser inside my WinForms application.
If I run my app from Visual Studio, the browser runs correctly. However, upon using ClickOnce to deploy my app, it threw the following error: "Could not load file or assembly 'CefSharp.Core.dll' or one of its dependencies. The specified module could not be found." Although all the CEF files are present in the bin\Debug folder. In fact I found a page on GitHub listing which files are required, and a careful check verifies that all are present in the executable folder.
A list of required files can be found here:
One of the points made in the above article, are that the Visual C++ Redist files are required and asks in question 6. How do I include the Visual Studio C++ 2012/2013 redistributables on the target app?
It specifically states that CefSharp version 43.0.0 and below needs VC++ Version 2012. Therefore, I downloaded vcredist_x86.exe (the 2012 version)
I created a package.xml and product.xml Bootstrapper files in the Microsoft SDKs folder. I included these as a prerequisite in Visual Studio 2010's Publish screen.
However, upon a ClickOnce deployment and an attempt to launch the CEF Web Browser, it immediately throws the exception "Could not load file or assembly 'CefSharp.Core.dll' or one of its dependencies. The specified module could not be found."
I am at a loss as to what to do, in order to get the browser to work outside of my development environment, i.e., for the End-User to successfully use.
I've followed all the steps that I've found on line, both on Stackoverflow and Github for CefSharp. What else is required to get this working?
Please help!
I'm adding this addendum in case anyone working with CefSharp has run into the same issue, namely "Could not load file or assembly 'CefSharp.Core.dll' or one of its dependencies. The specified module could not be found.". It turned out to be a ClickOnce issue. ClickOnce included all the "managed" resources, but did not include the unmanaged ones, i.e., cef.pak, cef_100_percent.pak, d3dcompiler, libcef.dll, icudtl.dat, etc.
If I right-clicked on References and attempted to browse to these resources to add them, Visual Studio complained about them being unmanaged and would not allow them to be added.
After working with the Microsoft ClickOnce and Deployment forum, it was suggested that I right-click on the project, Add > Existing Item and add them. Then set their Build Action to "Content" and Copy to Output Directory to "Copy Always."
This allowed the resources to show up in Application Files... on the Publish tab. After another ClickOnce deployment, launching the Web browser was successful. No more complaints about missing files.
A while ago I developed a custom TFS check-in policy that was working fine with Visual Studio 2015.
Now I installed Visual Studio 2017 and wanted to register the check-in policy assembly the same way as I did with VS2015 before. But this does not work. How can I register custom check-in policy assemblies with VS2017?
For VS2015, I had these registry keys:
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"
and
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\14.0_Config\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"
and accordingly I added those keys for VS2017 (15.0):
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\15.0_Config\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"
But unfortunately this does not work:
If I open the Team Project SourceControl settings, go to the "Check-in Policy" tab and try to Add... a policy, MyCheckInPolicy does not appear1
If I open the team project that uses this check-in policy already and do the above, I got an error message telling me that the assembly (mycheckinpolicy) "has not been registered".
Of course I restarted the IDE after the registry change, but even rebooting my machine did not help.
The information I found so far seems to suggest that check-in policies now have to be part of an extension (vsix), which I don't want to believe.
I guess that the problem comes from some references that cannot be resolved when the assembly is loaded into the IDE.
The MyCheckInPolicy project references the Microsoft.TeamFoundation.VersionControl.Client.dll v14.0 from the VS2015 folder C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer.
I tried to reference the respective dll from the VS2017 folders, but then the assembly does not work in both IDEs.
I also tried to use the Nuget package "Microsoft.TeamFoundation.VersionControl.All" v12.0.30723.2 instead and deployed all files from the output directory (which seem to contain all assemblies of the package) to the location mentioned in the registry keys. This had the same result: the policy cannot be loaded in neither VS2015 nor VS2017.
We are using TFS 12.0.30723.0.
1So it seems VS2017 doesn't even try to load the assembly and does not care about the registry keys?
In Visual Studio 2017 there are breaking changes to extensibility. Much of the registry configuration has been moved into a "private" registry:
To reduce the impact on the registry, Visual Studio now uses the
RegLoadAppKey function to store registry keys in a private binary file
under %VsAppDataFolder%\privateregistry.bin. Only a very small number
of Visual Studio-specific keys remain in the system registry. (link)
By defining the registry keys as part of a .pkgdef file in a vsix, on installation VS 2017 will (I assume) write the keys to the private registry as opposed to the actual registry, which was the case in previous versions of VS. This will allow the policy to be picked up.
So, here are the steps I went through to get our policies working in VS 2017:
Install the Visual Studio SDK (can be done by modifying your installation if you didn't select the workload originally).
Add a new VSIX Project to your checkin policy solution
Add a .pkgdef file to the VSIX project with the following (this is the registry key entry):
[$RootKey$\TeamFoundation\SourceControl\Checkin Policies]
"YourPolicy"="$PackageFolder$\YourPolicy.dll"
Modify source.extension.vsixmanifest (using the GUI wizard) in the VSIX project:
Install Targets: Add your lowest supported VS Version:
Microsoft.VisualStudio.Community [15.0,16.0)
Microsoft.VisualStudio.IntegratedShell [15.0,16.0)
Assets:
Microsoft.VisualStudio.Assembly
A Project in current solution
Project: Select your checkin policy project
Microsoft.VisualStudio.VsPackage
File on filesystem
Path: Select your .pkgdef file from step 3.
Prerequisites: Visual Studio core editor [15.0,16.0)
Build the VSIX project and distribute/install the generated vsix
This GitHub repo was helpful for piecing everything together. Some quirks I found when migrating to the vsix:
By default, vsix installations are now per-user. If you operate VS under multiple users on the same machine you will need to install it for each. There is an option in the vsixmanifest to have the extension installed for all users, but this requires elevation.
Our checkin policy used an app.config file, which is not supported in a vsix. I had to migrate our settings to a .settings file.
It worked to me adding this key to HKCU:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\15.0\TeamFoundation\SourceControl\Checkin Policies
Hope it helps.
Thanks,
Wilsade
Well, I've been trying to make a C++ DLL in Visual Studio 2015, which took a while since I'm not very good with Visual Studio.
I need to access the .NET libraries, specifically System::Management. (Writing the code was a little harder than it needed to be due to a poor C++ implementation, but at least it has one.)
I fixed obvious errors and finally figured out I had to enable CLR in the project properties and then select the related libraries with References->Add Reference. But after all that, now it's just giving this weird error:
LNK1104: cannot open file 'MSCOREE.lib'
The compiler doesn't show red wavy lines below anything, and the error claims the line is "1" and the file is "LINK", so no help there.
I thought I probably messed up the project configuration somewhere, so I created a new project and moved the code over. The error still happened. If I turned off CLR and commented out the .NET-dependent code, the build succeeded without errors.
So I tried creating a new project from template (Visual C++ -> Win32 Console Application) and then enabling CLR before doing anything else. Then I tried again, selecting different versions of .NET framework.
Finally, I tried creating a project with template (Visual C++ -> CLR -> CLR Console Application) and building it immediately. I mean literally without doing ANYTHING ELSE. It still gave the same error!
LNK1104: cannot open file 'MSCOREE.lib'
What on earth is going on? Am I doing something wrong here, or is VS2015 just broken?
I had the same problem. Installing ".NET Framework 4.6.1 SDK" solved the problem. Pay attention to the version number, take it from your project configuration files
Check in Visual Studio installer 'C++/CLI support' for build tools of your needed version.
Try this,
Right click the project that shows 'LNK1104: cannot open file 'MSCOREE.lib'', then select Properties --> Configuration Properties --> VC++ Directories --> Library Directories --> Add both entries from below separated by semi-colon
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64
This is where your 'mscoree.lib' should be, check if its there before doing this otherwise you might need to install/reinstall the Microsoft SDKs
In some situations the SDK may not install the required files in the LIB folder as described in MSCoree.lib missing from WinSDK. Their solution was to execute a repair of the install. That may not work.
I have successfully ran WinSDKInterop_amd64\WinSDKInterop_amd64.msi resulting in the creation of:
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\IA64\mscoree.lib
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\mscoree.lib
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64\mscoree.lib
I believe that I am dealing with some DLL hell.
I have a reference to Microsoft.TeamFoundations.VersionControl.Client in my application and 'copy local' is set to true. The application runs as expected on my development machine.
When I deploy this application I get an exception when trying to execute Microsoft.TeamFoundations.VersionControl.Client.DownloadFile()
Method not found: 'System.IO.Stream Microsoft.TeamFoundation.VersionControl.Client.Item.DownloadFile()'.
The version that gets deployed to my bin directory is version 9.0.3. The method exists. I noticed that a previous version of this dll does live in
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies
How come my application does not appear to be using the assembly that I referenced within my solution and ends up in bin? How can I force this to happen?
Thanks!
I'm not sure if this is it, when I was trying to use TFS 2008, I had to target the x86 processor instead of Any CPU in the project settings. Without doing that, I was finding wierdness when my app deployed to other peoples machines.
Also, I deploy a number of dll's with my app, maybe you've missed deploying something that VersionControl.Client.dll depends on, and it's trying to use another dll of which it's getting the wrong version. I distribute the following (not sure if they're all needed, but you could try distributing more to see if that solved it):
Microsoft.Build.Framework.dll
Microsoft.TeamFoundation.Build.Client.dll
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Collaboration.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Common.Library.dll
Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
Microsoft.TeamFoundation.VersionControl.Common.dll
Microsoft.TeamFoundation.VersionControl.Controls.dll
Microsoft.TeamFoundation.WorkItemTracking.Controls.dll
Microsoft.VisualStudio.TeamFoundation.Client.dll
Microsoft.VisualStudio.TeamFoundation.dll
Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.dll
It appears from this link Microsoft.TeamFoundation.VersionControl.Client.Item.DownloadFile() is missing that there are other (and presumably safer) way to do this with other methods.
The application insisted on referencing these dlls from the GAC. I ended up installing VS 2010 on the development environment and referencing the Microsoft.TeamFoundation dlls from the GAC. VS 2010 installed version 10 of the Team Foundation dlls into the development GAC.