tags:

views:

231

answers:

2

I am getting the following error message when compiling or attempting to run my application on Windows 7 64 bit. I've scoured the internet and many people have the same error message however none of the solutions address my problem or situation.

Using VS 2010.

Error 38 Could not load file or assembly 'file:///D:/Projects/Windows Projects/Weld/Components/FileAttachments/FileAttachments/FileAttachments/bin/x86/Debug/FileAttaching.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format. Line 1212, position 5. D:\Projects\Windows Projects\Weld\Weld\Weld.UI\frmMain.resx 1212 5 Weld.UI

Ok, so I have 2 projects a UI project and a FileAttachment project. UI project has a reference to FileAttachment project. When I compile UI project in "Any CPU" mode everything works fine and it runs. I assume 'Any CPU' will run in 64bit mode when I compile as that is the platform I am using.

I want to run/compile as x86 so I try to do that, so I change configuration for all projects to x86 and verify that these configurations are compiling to x86. I compile and get the error as stated above.

I find it odd that it compiles and works fine in 64bit but not 32bit. However when compiled and deployed to users as 'Any CPU', if these users have x86 it still works for them no problem. I just can't compile or run as x86 on my PC. Again, I can compile as Any CPU and deploy to a 32bit PC no problem.

Neither project are referencing any 64bit only dlls. Both projects are verified to be targeting 32bit dll's and .NET Framework assemblies.

I need to compile and run this locally under 32bit mode. I need JIT edit/continue among other things.

Here is the line of code in the resx file that is causing the problem:

 <data name="ImageList1.ImageStream" mimetype="application/x-microsoft.net.object.binary.base64">
....{mime data}....
 </data>

The resx file is verified to be generated for .NET 2.0 amnd is only referencing .NET 2.0 assemblies and not .NET 4.0 versions.

Any ideas here? I've searched the net and have found hundreds of people with the same error message but a different problem.

A: 

I have run into the same problem with one of my programs. The issue is that for some reason the Visual Studio appears to be generating 64 bit data blocks for some of the GUI control properties, which it is then unable to load when compiling to x86.

In my case, I am able to work around the problem by deleting the problamatic data blocks from the resx file along with the line code lines in the cs.designer file that reference those blocks. I am able to do this as the corresponding source code lines that are assigning the referenced property are redundant and not needed. The only annoying thing is that I have to redo those fixes each time I modify anything in the designer, as Visual Studio then adds back in the bad code.

Eric Johnson
Thanks for the response. I've since found other postings where people have been having a similar problem. Definately a bug in VS2010 that's cost me hours of my time :(
Dan
I just upgraded my project in Visual Studio 2010 from .NET 2.0 to .NET 4.0 and I no longer get that error and am able to run the project in x86 mode and get full debugging. Must be an issue with .NET 2.0 only. The problem is, our client PCs are not yet up to .NET 4.0 :(
Dan
A: 

This appears to be a VS 2010 bug with image lists. See https://connect.microsoft.com/VisualStudio/feedback/details/532584/error-when-compiling-resx-file-seems-related-to-beta2-bug-5252020?wa=wsignin1.0

I was able to utilize the workaround listed to get it to work for me.


Posted by Luis Mack on 5/12/2010 at 8:50 AM I've found the same problem, only for a specific project when compiling on a 64-bit machine. A fix that SEEMS to work is to manually alter one character in the image stream EVERY TIME the usercontrol or form is edited in the designer

          AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w

Change to      AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w That is 00LjAuMC4w back to 0yLjAuMC4w at the end of the line (00 back to 0y)


Jim

J. Clay
Thanks for the tip. So when you alter one character the designer corrects it however so you don't end up with a corrupt MIME image stream?
Dan
It worked for me just fine with no corruption.
J. Clay