0

I have some problem with AnyCPU vs x86 compiler setting, but if I understand it correctly my problem seems to be the other way around as it is normally.

Currently everything is residing on a Win 7 64 bit machine with Visual Studio 2010. The application in question is Dot.NET 3.5. Visual Studio is in English, but part of the error is in German which is the language of the OS.


Project E: the main project/solution which includes 3 sub-projects, 2 as DLLs and 1 as exe. VB.net 3.5, compiled as x86 as it needs OleDB to Access. Originally started on VS 2008 or even VS 2005 on a 32bit machine in WinXP.

Project ADB: vb.net exe, needs to be possible to start as standalone and I need to be able to access the forms from project E. This started as a separate project, which my have been Dot.Net 4.0 in VS 2010, but I think it was still on the 32 bit machine/WinXP if this is relevant.
Needs OledDB to MS Access, so the standalone exe needs to be x86.
But if I compile it as x86 (Project Properties > Compile > Advanced Compile Options) as part of the solution, I get a build error (see below). If I change to AnyCPU, it works as part of the solution including access to OleDB (which should mean that it's x86, right?), but the standalone can't use OleDB anymore (which means it isn't x86, right?).

Project Au: vb.net DLL, included in references of E, no need for OleDB. If compiled as x86 I get the same error as in project ADB. Works if compiled as AnyCPU. Was added into VS 2008 on the 32 bit machine.

Project S: C# DLL, no need for OleDB. Compiled as x86 and included in references of E, this works. Is a download from the web, was added into VS 2008 on the 32 bit machine.

The build error is the following:
Die Datei oder Assembly "file:///X:/Entw/E/VB.net/ADB/bin/Debug/ADB.exe" oder eine Abhängigkeit davon wurde nicht gefunden. Es wurde versucht, eine Datei mit einem falschen Format zu laden.
Translated:
Could not load file or assembly 'XYZ' or one of its dependencies. An attempt was made to load a program with an incorrect format.

The OleDb error I get when starting ADB as AnyCPU standalone is the following:
Der 'Microsoft.Jet.OLEDB.4.0'-Provider ist nicht auf dem lokalen Computer registriert.
This is the usual no-64bit JET error warning:
The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine.

Now, as I understand it, normally if the main project was AnyCPU and the sub project was specific I would get the build error since it would try to access x86 from AnyCPU which in this case would be x64. But here I try to access x86 from x86 which doesn't work, but accessing AnyCpu (which should be x64) from x86 works?

If necessary I can give more information and all the configuration files etc.

I'm sorry if I have written this confusingly, but I am extremely confused about this issue.

Mano
  • 1
  • 1
  • 1

2 Answers2

1

You should avoid using the AnyCPU setting.

But I guess your solution is not configured correctly. In Visual Studio 2010, right click the solution, and click "Properties" ("Eigenschaften"). Choose "Configuration Properties" ("Konfigurationseingenschaften") and ensure that all projects will build as x86.

If you are planning to supply a 64-Bit version of your application, I suggest creating different build profiles. You can do this by clicking "Configuration Manager" in the solution properties. Under "Active Platform Configuration" choose "<New...>", select "x64", copy the settings from "x86" and enable "Create new project platforms". Then go through the list and make sure all projects build as x64 within this configuration.

Carsten
  • 11,287
  • 7
  • 39
  • 62
  • You should avoid AnyCPU for EXEs, for assemblies you should use AnyCPU: `"AnyCPU is still incredibly valuable for DLLs (you may not always know what processes it will be loaded into)"` – Matt Wilko Jan 11 '13 at 13:27
  • You should avoid AnyCPU for all assemblies that are referencing 3rd party libraries, which is the case in this question. In this case OleDb get's bound into an AnyCPU DLL. Referencing it on an x86 machine should work, but referencing it on x64 systems wont! AnyCPU should only be considered for libraries that are referencing libraries that are compiled with AnyCPU, either. – Carsten Jan 11 '13 at 13:32
  • Solution properties > Configuration properties > everything is set to x86. (While actually the different sub-projects still are set to the respective values from above). The problem is that if I avoid AnyCpu (e.g. use x86), I get the compiler error (Could not load file or assembly 'XYZ' or one of its dependencies. An attempt was made to load a program with an incorrect format.). – Mano Jan 11 '13 at 15:49
  • @MattWilko I'm still having this problem. Everything from above seems to be configured correctly but I still need to set the ADB project to AnyCPU if I want to build the whole solution. – Mano Jan 16 '13 at 14:58
  • @mano - my *guess* then is that you have a dll referenced somewhere (third part assembly perhaps) in your solution that is set for x64 and you are trying to use x86? – Matt Wilko Jan 16 '13 at 15:04
  • @MattWilko Hmm, an interesting idea. But if I build ADB standalone, then I **have** to switch to X86 (for OleDB) and it compiles, so I don't believe this is the problem. Another possibility might be opening the project on a x86 only PC and see if this changes something. – Mano Jan 17 '13 at 10:58
  • If I open it on a x86 PC (VMWARE of old PC) ADB lost the AnyCPU setting which I changed to x86 after which it worked in the x86 environment. But returning to x64 I have the same problem again. I'm now removing as much as I can from ADB by excluding and commenting out the stuff pointing to the removed files. I'm down to 2 classes (which should be OK) and one form (main form, probably the problem) and some resource files (icons/bmps). Is there any easy way which I can copy a form without dragging the behind the scenes stuff with me but with copying location, size, text, etc properties? – Mano Jan 17 '13 at 16:26
0

Okay, I found it now. The problem is that the error message was not really helpful.

Digging in the output revealed that it was a problem with resgen.exe on a specific form.
MORE digging in Google and VS Command line revealed that it's somehow trying to get the wrong System.Forms.dll: http://connect.microsoft.com/VisualStudio/feedback/details/532584/error-when-compiling-resx-file-seems-related-to-beta2-bug-5252020 and realizing that yes, I was using an ImageList on that form.

Mano
  • 1
  • 1
  • 1