We Keep Coding

XNA reference error, changed workspace and can't run

Me and a couple of my friends were on an army network when we wrote the game (XNA 4.0 for VS10 32bit PCs),
and now we got it and it gives some error when we try to run the XNA part.
I try to run the server, whose main consists of Initialization of the server class and the start method.
The program throws a BadImageTypeException on the ctor of the server class instance initialization.
Since my windows is not in english I can't really give you the exception in gives but I do have a warning that says:
"Warning 1 There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "Microsoft.Xna.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=842cf8be1de50553, processorArchitecture=x86", "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. Game_Of_Throws_Server"
Kinda been waiting for a long time for the game to go WWW and we wanna keep working on it,
but this is a small but annoying problem that keeps us from continuing the development of the game.
Tried removing the assembly reference from the assemblies list and adding it again (The Microsot.XNA.Framework reference) but it didn't change a thing. Windows is Win7 64bit, VS is VS13Community version.
If anyone would like to skype or something of that sort to see the problem more clearely, send me a pm.

You'll get errors like that if the assembly you reference has a different target platform to the assembly referencing it e.g. You have an 'Any CPU' project referencing an 'x86' assembly. Are you certain that the 'Platform target' setting of the project producing this error really is set to x86?
If you're referencing the x86 version of Microsoft.Xna.Framework, you should change the project referencing it to also be x86. If an x64 version of Microsoft.Xna.Framework is also available, you can get creative with your csproj file to ensure the right one is pulled in based on the build you're doing (native Visual Studio support for switching references based on the target platform of the build is not good).

FileNotFoundException - Could not load file or assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

I'm starting to work with the Windows Phone 8.1 SDK. I want to use it in conjunction with an external C# library (mtgdb.info). I installed mtgdb.info to my solution using the package manager and added appropriate using statements when I called methods from the library.
The solution builds without errors or warnings, but when I try to debug the code I get the error listed in the title on the first line that calls a method in the external library. Installing the mtgdb.info nuget package is the first change I've made to the solution after creating it.
The mtgdb.info.dll is referenced in every project of my solution as well as its dependent dll (newtonsoft.json)
Any thoughts on why the solution wouldn't be able to find the assembly at runtime? Are there any good resources on how assemblies are located for Windows Phone applications?

most of the time, this problem appears on x64 machines.
Go to Properties in your project, then go on "Build".
I Guess "platform target' is set on "Any CPU"
try to put x86 and see if you still have the problem.
Reason is that, when you let "any CPU" on a x64 machine, Runtime will try to find the x64 release of the dll
But if the dll has been compiled for x86 only, Runtime don't find it.
EDIT : my bad, i didn't saw first that it was regarding System assembly. Did you install Framework 4.5 ? if not do it, or In :
project => properties => Application => Target Framework : change to a lower value. Anyway i'm surprise you get that error !
PS : With "System" assembly, you can keep "ANY CPU", Microsoft compiled it for 64 & 86 machines of course ;)

Visual Studio 2012 adds reference to wrong DLL

I was having trouble getting Visual Studio to build my project in release mode... it gives me errors about assemblies being the wrong format. Turns out some x86 assemblies were being referenced instead of x64 assemblies. Assemblies like PresentationCore, System.Data and so on.
Things I've tried:
Debug mode, any CPU builds fine.
Debug mode, x64 builds fine.
Release mode, any CPU fails
Release mode, x64 fails (this is the combination I'd LIKE to build my project in)
The issue comes when I try to remove the x86 reference and switch it to a x64 reference. Visual studio just adds the old x86 reference instead of the x64 reference. For example:
I remove the System.Data reference which is in C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
I browse to and add C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Data.dll, but when I click on that System.Data reference, the path is CLEARLY still to the old dll and causes the same error to occur. This is happening with several other DLLs as well.
Does anyone know of a solution to this issue?

Assemblies like PresentationCore, System.Data and so on.
I hate to answer a question without seeing the error message. But this secondary evidence is enough to answer the question. First off, this is not an error, it is a warning. It looks like this:
warning CS1607: Assembly generation -- Referenced assembly 'System.Data.dll' targets a different processor
You'll also see one for mscorlib.dll. And PresentationCore.dll in a WPF project. What goes on here is that these assemblies are special, they are mixed-mode assemblies. In other words, they contain both native code and managed code. The native code is the trouble-maker, such an assembly can only be used in a project that targets the right processor flavor. If you mix it up then you get a BadImageFormatException at runtime.
This is not a real problem with .NET assemblies, your machine actually has two versions of these DLLs stored in the GAC. One that will be used if your program runs in 32-bit mode and another that is used in 64-bit mode. The CLR automatically picks the right one.
However, there is only one version of the reference assembly, the one that's stored in c:\windows\microsoft.net and that you pass to the compiler to read the metadata from. It is always the x86 version, there's no other one so don't bother looking for it. Again, this is not a problem, only the metadata of a reference assembly is used by the compiler, it doesn't execute any of its code. And the metadata does not depend on the bit-ness of the assembly.
Nevertheless, this all might be a problem if you create your own mixed-mode assembly. You can easily overlook the need to provide two versions. So what the compiler is fretting about is that it sees that you asked for an AnyCPU or x64 build of your project. But detects that the reference assembly can only work when you target x86. So it squeaks at you a bit, just a gentle reminder that there's some evidence that you're getting it wrong and that your program might fall over on a BadImageFormatException when you run it. It doesn't otherwise treat a framework reference assembly any different from your own reference assembly.
So, feature, not a bug. Just a warning that doesn't otherwise prevents your program from building. You can safely ignore the warning since you know that .NET has the right assembly available in the GAC at runtime. Notable is that .NET 4.0 doesn't have this problem, it uses very different reference assemblies that don't have the ILONLY metadata flag turned off.

Odd behavior. Turning "Generate serialization assembly" off under Build in project properties makes the project build just fine in release mode. Looking at this link reveals that this setting has to do with XML Serialization, which we don't even use in our entire solution.
Very weird. Still looking for an explanation for this question and behavior here.

Check out what your build configuration looks like. Sometimes this error happens because certain project on a solution is configured to be built in one build configuration, and not in another.
To do this:
Go to "Compile > Configuration administration..."
On "Active solutions configuration" select "Release" which is the configuration that is giving you problems.
On "Platform of active solutions" check "Any CPU". If "x64" is defined, you might be able to choose it too.
Look at the list of build projects. All projects needed for the solution must be marked with the correct values in "Configuration", "Platform" and have a "Compile" check.
In my case I have a sandcastle project that I uncheck most of the times, at least in debug mode, because it takes ages to compile. Sometimes it happens that one project does not have a configuration for the "Release" configuration and thus, when the build process tries to get its results, these don't exists (there is no DLL) and it throws an exception. In other situations, it might be that a project is forced to compile for x86 (or x64) and the rest is not, and so an error is thrown when trying to link other referencing projects to the proper version of the referenced DLLs.

Which version of .NET are you compiling for? If you can change the project to a later version of the .NET framework, that might help.

My VS2010 web project was generating these warnings too, and IIS was throwing a BadImageException. The Build/Configuration/Platform settings looked ok, but the Output window was showing that the dll was built in x64 folder for Any CPU configuration. Deleted all folders under bin and rebuilt. The warnings were gone and the BadImageException was gone.

Error while trying to run project:The module was expected to contain an assembly manifest

When I try to run the project it says:
Error while trying to run project:could not load file or assembly 'Project.exe' or one of its dependencies.
The module was expected to contain an assembly manifest.
When I ran the exe from the debug folder I got this error:
application unable to start correctly (0xc000007b)
I also reinstalled Visual Studio but it doesn't seem to work!

The module was expected to contain an assembly manifest
It is a low-level assembly loading problem. The CLR has located a file with the right name but when it tries to load the assembly, it finds out that the file doesn't contain a proper manifest. A .NET assembly must contain a manifest, it contains metadata that describes the assembly, listing the types in the assembly, etc.
If you have no clue what EXE or DLL might be the troublemaker then you can use the Fuslogvw.exe utility:
Start it from the "Visual Studio Command Prompt".
Click the "Settings" button and click the "Log binding failures to disk" radio button.
Switch back to VS and start the program and wait for the exception to occur.
Back to Fuslogvw, click the "Refresh" button and double-click the added entry.
It shows you the file it found.
Several possibilities, a common one these days is to trying to load a .NET 4 assembly with an EXE that asked for CLR version 2. That requires an app.exe.config file that forces CLR 4 to be used.

In my case I just change Target Framework(.Net Framework 4) in Project Properties. It solves the problem.

I have the same problem when I use Vs2012 utimate to publish Asp.net Mvc4, then upload dll to server.
I fixed it by build code as Release mode then upload all dll in bin folder to server.

IN my case it get fixed by just going to project properties and set-->startup object projectname.program and build->platform target--> x86.

i just resolve this by problem by restarting System as well in project properties i set to multi users as well in combo box start option.hope this will help u.

0xc000007b is "STATUS_INVALID_IMAGE_FORMAT". From experience, this points me to the project properties.
A few things worth checking out:
Check to see if all the build options are set to either x86 or x64, depending on your system architecture, or AnyCPU.
If you're using dlls, consider whether they were compiled for your target architecture or not. If not, then recompile them accordingly or get them in the right version from wherever you got them.
Finally, check if your project assembly and loaded assemblies have different names. That seems to make things go boom as well.

Accessing an XML embeded resource file throws error in Release mode but not Debug mode

.NET 3.5
Visual Studio 2008 Team Edition
I have an XML file that I've added to an assembly via the Resources tab of the project's properties; and have marked the Access Modifier as public. While running in debug mode, there are no problems referencing the assembly and the embedded resource in another project, i.e.,
XElement errorMap = XElement.Parse( Properties.Resources.ErrorMapper );
However, when the projects are run in Release mode, I receive this error:
Could not load file or assembly
'XXX.XXX,
Version=1.1.0.25104, Culture=neutral,
PublicKeyToken=null' or one of its
dependencies. An attempt was made to
load a program with an incorrect
format.
Why would the projects run fine in Debug mode but not Release mode?

Hmmm....
I run a 64 bit dev machine and had targeted the build and release modes to the x86 platform. Apparently, when I added the resource file the platform build for release mode changed to Any CPU.
Since I reference some 3rd party DLL's that require 32 bit, the Any CPU build on Release mode puked out.
Problem solved.

Are you referencing a .dll file on your test box that is not in the same location on your production one? I guess that depends on whether you have your references set to copy local...
What about your .net frameworks and service packs, I would make sure those are the same/up to date...