Running in debug

AndroidAdam

04-02-2010 22:55:36

Hi, I've been using Mogre for a while without a hitch, but I've gotten a new computer and now I can't run my Mogre apps in debug :(

Anyway, I'm using Windows 7, 64 bit along with Visual Studio 2008 Team System. I've already compiled in Release so I've got the 64 bit issues sorted out, just wondering if anyone knew how to fix debug.

Thanks

GantZ

05-02-2010 08:15:12

what kind of error do you get ? i'm also running my mogre apps on windows 7 64bit. My apps are compiled in debug, but i use the mogre release library. I will try to compile my app with the debug libs to see if i experiences some trouble.

AndroidAdam

05-02-2010 23:31:19

Thanks for the reply, here's the exception:

Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'Mogre, Version=1.6.5.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.

However If I have referenced another Assembly, MogreNewt for example, it says Could not load file or assembly <MogreNewt> rather than Mogre.

GantZ

06-02-2010 17:24:29

System.BadImageFormatException

It strange, usually you got this kind of error when you try to load an assembly compiled in x86 mode on the 64bit .net framework. I remember I sorted it out by using the /target:x86 flag on compilation.

Make sure that you use x86 as platform rather than AnyCPU (but if you are able to make you app run in release mode, it should be ok) . I'm not on my computer right now, so i will try to run my app with debug lib tomorrow.

EDIT
Just checked it. i got no problem running my apps with the debug libs.

dezhi

19-05-2010 19:12:50

hi GantZ, here i came to the similar exception.
at first, is the same exception as AndroidAdam list:
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'Mogre, Version=1.6.5.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format..
and when i change "AnyCPU" to "x86" as you said, the release is ok, but debug still got problem.
Unhandled Exception: System.IO.FileNotFoundException
and it said this exception occurd in mscorlib.dll, which realy confused me.
i noticed that in the "BuildSamples.txt",

"BuildSamplesX86.cmd
--> lets you build the samples explicitly for 32-bit processors,
so that WOW64 is activated on Windows 64-bit editions.
Try this if you get a FileNotFoundException or a similar one."

but the BuildSamplesX86.cmd is for release, not debug.
so, can you give me some advice to solve this problem?

Thanks a lot.

GantZ

19-05-2010 20:30:29

What are you trying to build ? samples or your own application ?

If it's samples, you have to change manually the reference to Mogre by Mogre_d. The error you get probably mean that the application try to load the ogremain.dll but couldn't find it in the debug directory (where it's ogremain_d.dll).

xerios

19-05-2010 22:59:59

Well I also started getting that error in debug mode when I updated my mogre dlls from 1.7.0 beta to 1.7.1 beta, release mode worked just fine for some reason. ( forgot to update the debug dlls maybe? )
Either way it doesn't really matter since I can just use the release dlls for debugging :)

mstoyke

19-05-2010 23:20:34

Make sure to use a different plugins.cfg file for debug, because Ogre DLLs are named *_d.dll instead of *.dll in debug versions. I missed this the first time and got the exact same error message.

Or, as somebody mentioned before, you can just use the release version of mogre/ogre even for the debug version of your project. It will only make it harder to debug into actual mogre code, but you can still fully debug your application without problems.

Also notice that, in the files I uploaded, Mogre.dll will have the same name (without the _d) in debug and release version, but reside in different folders. I did that because visual studio can only reference to one kind of assembly in the projects references (don't know if that changed in newer versions). So if I use the mogre.dll assembly in my projects references it's the same for debug and release. In my projects I just use a post build step to copy the right version of mogre.dll into the bin folder and make sure the reference in the project is marked to not be copied automatically into the bin folder.
I don't know if I explained that very well, if you don't know what I meant with that just ask me for a more detailed explanation or maybe a diagram.

dezhi

20-05-2010 06:13:47

first, thanks to all. i'm new here, and i do have lots questions.

well, it's the sample, and i changed the Mogre by Mogre_d, the problem gone.

but, as mstoyke said:

use the mogre.dll assembly in my projects references it's the same for debug and release

so, i want to konw, how to make it if i don't change the reference to Mogre by Mogre_d. mstoyke give a solution, but i didn't get it, would you please give me a more detailed explanation?

mstoyke

20-05-2010 18:06:18

Ok, let's try to explain that in some more detail.

First, it is necessary for this to work that both mogre assemblies (debug and release version) are named "mogre.dll", they just are in different folders, usually something like mogre/debug and mogre/release.

In VS you define references for your application or library by adding them to the references "folder" in the project. This could be anything from assemblies in the GAC, references to other projects in the solution to just .DLL files that contain compiled references. If your project references mogre.dll then this will be used no matter if you compile a debug version or a release version of your project.

When you compile a solution that contain a debug configuration and a release configuration, you usually end up with release binaries in the bin/release folder and debug binaries in the bin/debug folder. Normally VS will automatically copy the referenced assembly (mogre) into the bin/release or bin/debug folder. You can select a reference in the references "folder" in your project and look at the properties window to see if "Copy local" is true. Turn it to false and mogre.dll will not be copied automatically anymore.

Now you end up with compiled binaries in their folders, but without the mogre.dll. That's why I usually have a post-build step that uses a copy command to copy the missing file. something like "copy /b dependencies/$(ConfigurationName) bin/$(ConfigurationName)" should work, assuming that mogre lies in dependencies/debug (debug version of mogre.dll) and dependencies/release (release version of mogre.dll) folders.

I usually turn of "copy local" for all referenced assemblies and copy them myself, because I sometimes got mixed up versions in the past when I relied on VS handling this. This was especially true for batch build, sometimes I ended up with a release version that had debug versions of their references with them, or vice versa.

The post-build step could also copy the native DLLs of Ogre to the bin/release and bin/debug folders, because VS only does this for referenced assemblied automatically, not for native dependecies like ogremain.dll, rendersytem_*.dll, ...

dezhi

23-05-2010 13:39:22

ok... i think i get the point. thanks mstoyke, thank you.

dezhi

25-05-2010 06:44:58

i thought i understand what mstoyke said, same name for both debug version and release version mogre.dll, right?
but now, here is another problem.
in debug mode, if i use plugins.cfg for debug, the application comes error, while i use plugins.cfg for release, everything works just fine.
i tried many times.

the application's bin\x86\debug folder is my work dir, and i think i get everything i need here
such as DLLS,
cg, mogre_d, mogreframework, mois_d, ogremain_d, the rendersystem_*_d, the plugin_*_d
and cfgs,
media, plugins, resources.
and .exe file.

did i missed something ? or did something wrong?
i really need help. thanks.

the error log and picture
13:52:01: Creating resource group General
13:52:01: Creating resource group Internal
13:52:01: Creating resource group Autodetect
13:52:01: SceneManagerFactory for type 'DefaultSceneManager' registered.
13:52:01: Registering ResourceManager for type Material
13:52:01: Registering ResourceManager for type Mesh
13:52:01: Registering ResourceManager for type Skeleton
13:52:01: MovableObjectFactory for type 'ParticleSystem' registered.
13:52:01: OverlayElementFactory for type Panel registered.
13:52:01: OverlayElementFactory for type BorderPanel registered.
13:52:01: OverlayElementFactory for type TextArea registered.
13:52:01: Registering ResourceManager for type Font
13:52:01: ArchiveFactory for archive type FileSystem registered.
13:52:01: ArchiveFactory for archive type Zip registered.
13:52:01: DDS codec registering
13:52:01: FreeImage version: 3.13.1
13:52:01: This program uses FreeImage, a free, open source image library supporting all common bitmap formats. See http://freeimage.sourceforge.net for details
13:52:01: Supported formats: bmp,ico,jpg,jif,jpeg,jpe,jng,koa,iff,lbm,mng,pbm,pbm,pcd,pcx,pgm,pgm,png,ppm,ppm,ras,tga,targa,tif,tiff,wap,wbmp,wbm,psd,cut,xbm,xpm,gif,hdr,g3,sgi,exr,j2k,j2c,jp2,pfm,pct,pict,pic,bay,bmq,cr2,crw,cs1,dc2,dcr,dng,erf,fff,hdr,k25,kdc,mdc,mos,mrw,nef,orf,pef,pxn,raf,raw,rdc,sr2,srf,arw,3fr,cine,ia,kc2,mef,nrw,qtk,rw2,sti,drf,dsc,ptx,cap,iiq,rwz
13:52:01: PVRTC codec registering
13:52:01: Registering ResourceManager for type HighLevelGpuProgram
13:52:01: Registering ResourceManager for type Compositor
13:52:01: MovableObjectFactory for type 'Entity' registered.
13:52:01: MovableObjectFactory for type 'Light' registered.
13:52:01: MovableObjectFactory for type 'BillboardSet' registered.
13:52:01: MovableObjectFactory for type 'ManualObject' registered.
13:52:01: MovableObjectFactory for type 'BillboardChain' registered.
13:52:01: MovableObjectFactory for type 'RibbonTrail' registered.
13:52:01: Loading library .\RenderSystem_Direct3D9_d
13:53:49: *-*-* OGRE Shutdown

13:53:49: Unregistering ResourceManager for type Compositor
13:53:49: Unregistering ResourceManager for type Font
13:53:49: Unregistering ResourceManager for type Skeleton
13:53:49: Unregistering ResourceManager for type Mesh
13:53:49: Unregistering ResourceManager for type HighLevelGpuProgram