Bring forward Tesla.Interop.Generator

[GoogleCodeExporter]

Port the code for this project from Tesla Engine (v2) so it can be compiled 
alongside AssimpNet. Have gotten a bug report when compiling AssimpNet for a 
platform that doesn't supported .NET 4.5

Original issue reported on code.google.com by nicholas.woodfield on 11 Jun 2013 at 9:00

[GoogleCodeExporter]

Note (since this is being reported several times)

The error is when trying to compile under WinXP, this error is reported:

"Build fails with message Tesla.Interop.Generator.exe is not a valid Win32 
application"

Original comment by nicholas.woodfield on 21 Jun 2013 at 8:50

[GoogleCodeExporter]

Can we get this telsa thingie 'asap'? :)
Because I don't want to rollback all the changes I've done (arrays to lists and 
uint to int) and I kind of cannot continue because it is not working...

Also as a side topic: would it be feasible to make the whole solution target 
framework 2.0?
Because I do it anyway - you just need to manually copy containers to arrays in 
a couple of places.
Would be mono-compatible then... Sorry if I should have written that somewhere 
else, let me know if I should.

Is this Tesla engine your code as well? Why are you going into trouble using it 
rather than filling the stubs yourself?

Original comment by spershin...@gmail.com on 23 Jun 2013 at 11:44

[GoogleCodeExporter]

No it was only a lack of a time to sit down and put this in. Should be good to 
go in r92.

Also made some some other changes, so should compile without (code) 
modification when the target is .NET 2.0. At some point will have a more 
comprehensive build solution using msbuild...

Original comment by nicholas.woodfield on 27 Jun 2013 at 3:33

• Changed state: Fixed

[GoogleCodeExporter]

Looks like the solution is made in VS 2012, I cannot open it with my Microsoft 
Visual C# 2010 Express. But that's fixable by just editing the file and 
changing the version.
Now I cannot build it for framework 2.0.
Well, to be honest I can, BUT, I cannot use it from another assembly which 
targets 2.0 because I get this error:

Warning 10  The primary reference 
"C:\ProjectsMore\assimp-net\AssimpNet\bin\Debug\AssimpNet.dll" could not be 
resolved because it has an indirect dependency on the .NET Framework assembly 
"mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" 
which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current 
target framework.   AssimpNet.Sample

This is essentially because the new dependency mono.cecil is built for 4.0

Just a quick question - does all this 'automation' worth the trouble?
And another question - any chance we can get a neat compile-able and use-able 
solution for 2.0 which opens in MS VS 2010? Sorry for sounding a bit irritated, 
but I think I am a bit irritated. When a good previous version of the project 
was so easy to use - this one with the new flashy useless stuff (from the point 
of view of end user) is not...

Original comment by spershin...@gmail.com on 28 Jun 2013 at 1:00

[GoogleCodeExporter]

All right, made it all work.
1. Went and downloaded the cecil.master.
2. Loaded cecil solution, set it to "release 2.0 Any CPU"
3. Compiled and copied the dlls over the AssimpNet cecil dlls.
4. Set all projects in the solution to target 2.0
5. Compiled.
And it works! :)

To Nicholas:
Can we have it all built-in in the solution (VS 2010)?
Or even have multiple targets just like cecil project has?
That would be awesome and out of the box.
If you want I might find time to do that shit.

Original comment by spershin...@gmail.com on 28 Jun 2013 at 1:26

[GoogleCodeExporter]

Thats why I said there's no target yet, shesh. The Mono.Cecil lib is the same 
DLL as before, it hasn't changed. I aim to have multiple targets in the 
solution, just like Mono.Cecil. Its an oversight that I'm glad you brought to 
my attention, but I do not appreciate the manner in how you brought it.

Its comments like yours that probably make people not want to do open source 
development...I do this on my free time and lately its very limited. Rather 
than diving head first into a (somewhat) unstable trunk in the middle of 
development, and then complaining about it when you couldn't build it an 
untested configuration is weak. This is why the repository has tags for all the 
previous major releases, if you wanted to compile the source for another build 
config.

VS2012 is part of my toolchain, so no there will not be a VS2010 solution 
moving forward. 

And yes this "automation" is worth the trouble. Its the same type of code 
injection that SharpDX uses to speed up blitting values types to/from unmanaged 
memory. The type of code that is injected is not accessible in C# (e.g. memcpy 
IL instruction).

It makes the export functionality a lot easier to develop because we can now 
easily marshal managed data structures to the unmanaged Assimp data structures. 
The AssimpExporter is not yet implemented, so it may seem to be useless to 
*you*, but its not moving forward.

Original comment by nicholas.woodfield on 28 Jun 2013 at 1:32

[GoogleCodeExporter]

I don't see you saying anywhere that there is no target yet, sorry. And man, 
you are so touchy, don't be - I haven't written anything bad, just facts + 
honestly admitting that I was irritating. Please, don't think you are the only 
one there writing stuff for other people for free.

If you want me to say I appreciate your effort, I will say, yes, I do 
appreciate your effort, but people always want something out of the box and if 
it requires some effort to use something sometimes it might just be better to 
do it yourself and having it your way and avoid all the issues, waiting, 
frustration, etc.

I don't bother with tags in relatively small projects, honestly - too much 
bureaucracy. All I've seen is: "Should be good to go in r92" and "so should 
compile without (code) modification when the target is .NET 2.0". I thought it 
is good to go, but ended up quite a nightmare. I have screwed up somewhat in 
that, if you want to hear that, but I mean how difficult to do what I did in my 
comment 5 for the author of the tool in the first place?!

Pity that you cut others from using VS2010...

I'm not a guru in this but I think you could write those memcpy instructions 
directly in C# using some assembly-kind of code (like asm blocks in C). I've 
seen it somewhere, don't remember the link out of the head. But it is up to 
you, of course, my comment was produced by irritation.

What is AssimpExporter?

And should I get offended by you using *you*? :)

Original comment by spershin...@gmail.com on 1 Jul 2013 at 7:05