AnyCpu built

[GoogleCodeExporter]

Hello again,

I have been working a little on assimp.net for the needs of my project and i 
made it for AnyCpu , because it's not convenient to have a project with 50 
AnyCpu dlls and one that it not..

It basically has the native assimp dll under a x86 and a x64 folder and chooses 
the appropriate file when loading is necessary.

The paths can also be modified by the user (at runtime but before using 
assimp.net ) , so the user can have his own x86,x64 folders and have the 
approriate native assimp dlls inside.

I attached a patch for this. ( its based on r63 , so no conflicts )

Thank you :)

Original issue reported on code.google.com by virusfre...@gmail.com on 12 Nov 2012 at 9:41

Attachments:

• anycpu_patch.patch

[GoogleCodeExporter]

I've given this some thought and I'll be going ahead with AnyCPU support. I 
intend on going a different route though, similar to how OpenTK does it via 
loading the library dynamically / collecting function pointers and marshalling 
managed delegates.

Original comment by nicholas.woodfield on 16 Nov 2012 at 6:02

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Sure , whatever you believe is best , but just to clarify something in case you 
didn't see the patch ... the native assimp library IS loaded dynamically using 
LoadLibrary() from kernel32.dll , just like in OpenTK. I tried not to change 
the rest of your code with the dll entrypoint functions.

Unless of course i am missing something and you are talking about a different 
method of loading.

Original comment by virusfre...@gmail.com on 16 Nov 2012 at 9:17

[GoogleCodeExporter]

I saw the dynamic loading, I was just stating that for completeness. The idea 
is rather than to bastardize the "AssimpMethods" static library to implement a 
factory based interop initialization that will load the correct native DLL 
(including upfront user-configrations), get the addresses of the C-API methods 
we use, marshal the delegates and manage it all. As well as properly 
disposing/freeing the library.

Original comment by nicholas.woodfield on 16 Nov 2012 at 9:27

[GoogleCodeExporter]

that sounds interesting.. looking forward to it :)

Original comment by virusfre...@gmail.com on 16 Nov 2012 at 9:36

[GoogleCodeExporter]

After a hiatus due to the holidays, I've finished this spot of work and its 
been committed. Still need to do testing, so any feedback would be appreciated.

You can also load the unmanaged library with a custom path:

AssimpLibrary.Instance.LoadLibrary(relative path to DLL)

Do this prior to calling any methods in AssimpImporter. Otherwise, things will 
behave as exactly as before. You can also unload the unmanaged library if 
necessary as well.

Original comment by nicholas.woodfield on 31 Dec 2012 at 5:09

• Changed state: Done

[GoogleCodeExporter]

I just checked the code and it seems to work great !
(I didn't check the freelibrary.)

just a quick note here .. i added an overload for LoadLibrary() to autodetect 
the platform... i think that will make it easier (especially for people who 
don't know the pointer size check trick) ...

https://github.com/VirusFree/AssimpNet/commit/043ca12ce0863460726c1beb838f903bce
a78771

I also noticed some code of this project being ported in SharpDX toolkit .. 
which makes the anycpu feature even more useful :)

Original comment by virusfre...@gmail.com on 31 Dec 2012 at 10:01

[GoogleCodeExporter]

Good suggestion, I'll add it

Original comment by nicholas.woodfield on 2 Jan 2013 at 2:43