Statically compiling Mogre with Ogre.

Lots of people (I mean *lots*) is having problems with the dreaded "Could not load file or assembly 'Mogre, Version=1.4.8.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies". And this is only by skimming the forum, think how many tried Mogre and just gave up without bothering to ask for help.

The majority of these cases are caused by the way Visual studio handles .NET references. The convention on .NET projects is to select a DLL, have VS copy it to Debug/Release bin folder and use it from there. Those who try that, need to copy all the necessary native DLLs too, modify .cfg files to tell Ogre where to find plugins, and make sure not to mix them with the wrong Debug/Release Mogre.dll (which BTW has the same name for both debug/release, as is the .NET convention). Failing to do all that properly causes "Could not load...".
I think this is way more complicated than it needs to be.

I suggest statically linking Ogre+plugins and Mogre+Ogre and creating one huge monolithic Mogre.dll that is self-contained.
The advantage of this is that there will be no more DLL-hell, you'll only have to reference one .NET dll and it will work as expected.

Advanced users that need to cut down plugins that are not used so that the DLL size is reduced, will have to recompile Mogre.

Does anyone have objections with this approach ? "Speak now or forever hold your peace!"

Another posibility is to add strong naming to Mogre and upon SDK installation install it into the GAC (Global Assembly Cache). This is for example done by the OpenAL.NET part of the TAO-framework. This however still requires the C++ libraries (Ogre+plugins) to be found. I think this could be solved by adding their location to the PATH environment variable. That is an approach which is also used by a lot of other projects.

I experimented around with strong naming a while a go and got it working. I also remember having some problems with statically liniing OgreMain.dll into Mogre.dll. However I am not sure what this was related to. Only thing I remember that a linker switch interfered with the /CLR switch of OgreMain.dll. But it could also been related to my experiments with statically linking the VC runtime.

Thoran

I agree with strong naming Mogre, but I'm not so sure about installing it to GAC. This is roughly the equivalent of installing native Ogre into windows\system32, what are the benefits ?

Even if Mogre.dll is installed in GAC this still doesn't fix the real issue which is if OgreMain.dll is not found, a vague "Could not load file or assembly Mogre..." is the result, which is rather ridiculous (if it specifically said "OgreMain not found" this wouldn't be so much of an issue).
Changing PATH may solve it but it's more of a "bandage" than a real "cure".

Now I'm leaning towards another approach, which is keep native Ogre DLLs, but statically add all Mogre stuff into OgreMain. OgreMain will be usable by both native plugins and .NET projects (you'll reference OgreMain.dll instead of Mogre.dll).
If a native DLL is not found, the message will be something like "cg.dll not found".

I still think that the best approach from the usability viewpoint is a single .NET DLL, but that way you won't be able to use a native plugin using the SDK.

Ok, here's another idea.
Since in order to use a native plugin with Mogre you already have to recompile it (against modified Ogre's include files), how about going with the monolithic Mogre.dll idea, and have a Mogre SDK that provides all the static libraries so that you can "plug" the exact libraries that you want and produce a "custom" monolithic Mogre.dll instead of using the default one.

Native plugins will need to be recompiled and linked statically with the monolithic Mogre.dll, using the SDK libraries.

Any thoughts ?

mmm very good idea. We can then create a monolithic Mogre.dll with a default configuration or an All-in-one DLLl. And add the .lib of Mogre, Ogre, and plugins in the SDK to build customs Mogre.dll

Ok i suggest the next Mogre.dll monolithic bundle:

Mogre Default Bundle (Mogre.dll)

1. 
   OgreMain.dll
   RenderSystem_OpenGL.dll
   RenderSystem_Direct3D.dll
   Plugin_Particle.dll
   cg.dll
   OIS.dll
   MOIS.dll
   [/list:u]
   
   What you think, i am missing something??

I'm thinking static linking these:

Mogre.lib
OgreMain.lib
RenderSystem_Direct3D9.lib
Plugin_OctreeSceneManager.lib
Plugin_ParticleFX.lib
Plugin_CgProgramManager.lib

Having only D3D rendersystem by default seems a reasonable choice.
I'm not sure but I think cg.dll can't be statically linked so it will be present for CgProgramManager.

Very good discussion. The forum is filled with threads about that issue... it's almost the same problem every time.

Since in order to use a native plugin with Mogre you already have to recompile it (against modified Ogre's include files), how about going with the monolithic Mogre.dll idea, and have a Mogre SDK that provides all the static libraries so that you can "plug" the exact libraries that you want and produce a "custom" monolithic Mogre.dll instead of using the default one.

Native plugins will need to be recompiled and linked statically with the monolithic Mogre.dll, using the SDK libraries.
Would this approach make it possible to use any native C++ plugin just by recompiling it and statically linking it to the new Mogre.dll?
I'm sorry if I didn't understand that correctly, I'm not really used to "linking libs to a dll". The VB/C# world is so much easier.

By the way, what about those variables? I posted this in another thread:First: In my experience the PATH-variable isn't really needed. It may just make some things easier since you can access the dlls from every folder. I don't have the PATH-variable set to any Ogre folder and my project is working fine. To be honest I don't know exactly where setting the variable might help. Maybe it's only needed for the Mogre build process.

Second: The OGRE-HOME-variable which is being set from the Installer. Same thing here. You don't really need it to run Mogre. It's just getting the samples running easier since the compiled files are all copied to the same output directory.

Ok, I'm all in favour of this.
To make life even simpler would it be possible to incorporate into this huge dll
- The C++ runtime needed for Mogre?
- The DirectX dll needed. I'm currently bundling the complete MS DirectX redistributable (all 90MB odd) with my project.

@Bekas: I'm thinking static linking these: ...

Ok its looks good. I going this weekend to test with that and make a new huge static linked Mogre.dll

To make life even simpler would it be possible to incorporate into this huge dll
- The C++ runtime needed for Mogre?
- The DirectX dll needed. I'm currently bundling the complete MS DirectX redistributable (all 90MB odd) with my project.

I think we could add the C++ runtime dll into de SDK or we can let that SDK automatically install the runtime.

DirectX dll is better keep it in a separate installer. All games i played do that.

Would this approach make it possible to use any native C++ plugin just by recompiling it and statically linking it to the new Mogre.dll?
Yes, you understand it correctly.
By the way, what about those variables? I posted this in another thread:First: In my experience the PATH-variable isn't really needed. It may just make some things easier since you can access the dlls from every folder. I don't have the PATH-variable set to any Ogre folder and my project is working fine. To be honest I don't know exactly where setting the variable might help. Maybe it's only needed for the Mogre build process.

Second: The OGRE-HOME-variable which is being set from the Installer. Same thing here. You don't really need it to run Mogre. It's just getting the samples running easier since the compiled files are all copied to the same output directory.
If your executable is not in the same directory as the native Ogre binaries, the PATH can help it locate them.
OGRE-HOME is only used for compiling native C++ applications that use Ogre, it has no relevance for Mogre apps.

To make life even simpler would it be possible to incorporate into this huge dll
- The C++ runtime needed for Mogre?
- The DirectX dll needed. I'm currently bundling the complete MS DirectX redistributable (all 90MB odd) with my project.
DirectX should really be installed by the redistributable, and chances are that it's already installed anyway.
I'm not sure about the C++ runtime, it will bloat the size of produced DLL, I think using the C++ runtime redistributable is a better idea, like Marioko said.

I going this weekend to test with that and make a new huge static linked Mogre.dll
Actually I'm interested in looking into this in the weekend too (thanks for the offer!).
If I can't find the time, I'll let you know.


Another aspect that needs consideration is plugin wrappers, like Editable Terrain Manager Wrapper. Does anybody have experience with this? Would this require a separate Mogre.dll and Ogremain.dll so that it can link to both of them ? A monolithic DLL may be too inflexible to accommodate such useful wrappers.

I've PMed lilljohan, I hope he can offer some insight about this.

Actually I'm interested in looking into this in the weekend too (thanks for the offer!).
If I can't find the time, I'll let you know.

Ok no problem.. (less work for me hehee)

To make life even simpler would it be possible to incorporate into this huge dll
- The C++ runtime needed for Mogre?
- The DirectX dll needed. I'm currently bundling the complete MS DirectX redistributable (all 90MB odd) with my project.

I think we could add the C++ runtime dll into de SDK or we can let that SDK automatically install the runtime.


As far as my experience can tell, you can definately not include (statically link) the VC Runtime with a /CLR compiled library. However automatic installation of the VC runtime through the installer of Mogre might make sense. However I also encountered problems with the vc_redist_installers on some machines , especially where it was about vc2005_redist and vc2005sp1_redist.

Reference on MSDN:
http://msdn.microsoft.com/en-us/libraryabx4dbyh(VS.80).aspx

As with /clr, you cannot link with the statically linked library.



Thoran

Good Idea, its really simplify the deploy.

Go ahead

Thanks (I am still waiting to re-enter to Mogre related development)

Sounds like a good idéa =)


Another aspect that needs consideration is plugin wrappers, like Editable Terrain Manager Wrapper. Does anybody have experience with this? Would this require a separate Mogre.dll and Ogremain.dll so that it can link to both of them ? A monolithic DLL may be too inflexible to accommodate such useful wrappers.
I'm unsure, but i don't think that this would play well with MET. It may be possible to link MET staticly against Ogre and get it to work. Or link against Mogre.dll if the C++ interface is exposed. Linking against OgreMain.dll would probably require a special Mogre.dll

But i don't really know, haven't played around with C++ for quite a while. =)

Guys, a big thank to you for your effort in making Ogre & Mogre better!!!