Issue #3 new

Port to .NET Core/HoloLens

ArmsOfSorrow
created an issue

Hello,

I'd be interested in using this library to import FBX models from arbitrary files on a HoloLens; however, it doesn't seem to support .NET Core, which I'd need to run it there. I have looked into porting instruction for .NET Core and found this tool: https://github.com/Microsoft/dotnet-apiport/blob/master/docs/VSExtension/README.md

Here's its output when run for .NET Core 1.0: https://1drv.ms/u/s!AnFjcKj3e3slhPcIIGZvJPGVIlCKog

Some of those APIs don't seem to have clear replacements, so I wanted to ask for advice about porting. Furthermore, the managed lib depends on the interop generator project, but that's a pure compile-time constraint; that wouldn't need to be ported, right?

Could you please look at the output and tell me whether it's possible? Of course, I'll be researching it further myself, but your knowledge as the lib author would be very helpful.

Comments (14)

  1. Nicholas Woodfield repo owner

    Is it possible to use .Net Core 1.1? It looked like it hits 100% compatibility, although its still in preview and not officially released just yet.

    I haven't taken a serious look at .Net Core yet, so I can't be much of a help for replacement APIs. The warnings about the OS-related ones is for determining which platform implementation (and which native assimp libraries) to load. So if you only have the one platform to worry about, you might just rework / hardcode the platform logic. Not sure about the nested types or string ctor (maybe just ignore that property). The binary reader warning looks like a hack to support .Net 2.0 since the "leave open" flag on BinaryReader wasn't in 2.0.

    If we get 100% compatibility with the impending 1.1 version, I don't think it's really worth it to substantially refactor for .Net Core's first release. That's actually one of the reasons why I haven't done much with .Net Core yet...but that will change with all the .Net Standard stuff bringing the APIs closer to parity.

    And yes, for runtime you only have to worry about AssimpNet.dll, the interop generator only runs at compile time and it shouldn't be deployed with your app.

  2. ArmsOfSorrow reporter

    Almost, it's 98.95 % for .NET Core 1.1. It seems not to like System.Security.Permissions.SecurityAction, but I don't see it used anywhere in the code...well, I'll just try to build it for 1.1 and report back to you.

    EDIT: I'm having a hard time migrating to the new project structure (which will become obsolete soon anyway, but still): https://docs.microsoft.com/en-us/dotnet/articles/core/porting/project-structure

    What do you think would be the best approach?

    I've just tried to build a sample .NET Core 1.1 console app that uses the Environment.OSVersion API. It's just not there, even though ApiPort says otherwise. This site says it's 1.2 and included in .NET Standard 2.0. There's some other APIs I didn't find in 1.1, e.g. ReliabilityContractAttribute even though the compatibility tool said otherwise.

    Am I missing something here or is ApiPort just wrong?

  3. Nicholas Woodfield repo owner

    Odd, for .Net 4 release it's 100%. I ran it for the debug and it reported the 98.95%...and then I updated (locally) to the latest Mono.Cecil version (I noticed in VS2015 the debug interop generator fails) and it went to 100%. The security permission attribute (appears) to be auto-generated for the assembly, as I can see it in .Net reflector.

    Maybe this link will be better if you're going to look at .net Core 1.1? https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/

  4. ArmsOfSorrow reporter

    Of course, it's already .NET 4 library, isn't it?

    Anyway, converting a project seems to be a huge pain; I'll look at those tools that you linked, but from a code perspective .NET Core 1.1 doesn't expose certain APIs that you use. I've read that libraries should target .NET Standard instead of netcoreapp, so there's even more stuff missing. .NET Standard 2.0 should fix all of those shortcomings, but is still far from release and I'd need that functionality now.

    I think from your perspective (if you want to port this library to .NET Core in the future) it would be best to wait for the 2.0 Standard. In the meantime, I'll use this library; it's a far cry from assimp and its number of supported formats, but I have been able to successfully compile it for the current .NET Standard 1.6 and the time frame for this project is very limited.

    Edit: Fuck it, we need fbx support...well, time to look for solutions.

    Anyway, thanks a lot for your time. It's always a pleasure to chat with a fellow open source developer.

  5. Nicholas Woodfield repo owner

    I was referring to AssimpNet's build configurations, there's a .net 2.0 debug/release and a .net 4.5 debug/release config. Anyways I'll look into the 1.1 preview a bit today.

  6. ArmsOfSorrow reporter

    Oh, now I get it...I've completely forgotten about those. The 4.5 config reporting 100% sounds promising, but is it for netcoreapp1.1 or netstandard1.x?

  7. ArmsOfSorrow reporter

    Any news from your side?

    I tried to run ApiPort with the 4.5 build (release), netcoreapp1.1. It reports 100% compatibility, but some APIs are still missing when I set up a 1.1 console project e.g. Environment.OSVersion. If libraries have to target the .NET Standard Library, then we'll have to wait until next year anyway...

  8. Eric Mellino

    Hey, I just found out about this repo (been working on GitHub mainly). I've made a version of AssimpNet built for .NET Standard 1.4 -- it required very few changes.: https://github.com/mellinoe/assimp-net

    The main commit adding support for .NET Standard 1.4 is here: https://github.com/mellinoe/assimp-net/commit/86a201f2e6e3688d1993da20cb44867c178542c4. The majority of the changes there are just configuration and build file changes. There are very few code changes needed.

    Probably also of note is that I removed the post-build rewriter step, and am using the new Unsafe library for similar functionality. That made the port a little bit easier, because that rewriter program would need to be modified as well.

    I'd love to get the changes back into the main repo here.

  9. Nicholas Woodfield repo owner

    Locally I've made a bunch of the changes I see in your netstandard 1.4 commit. The only part holding them back is the IL patcher (and my free time).

    I still want to keep a .net framework 2.0 build target for Unity users (the reason why it exists in the first place). It's my impression that Unity won't be targeting netstandard (or .net framework 4.x) for a while?

  10. Hixe

    Hello,

    Like ArmsOfSorrow I'm trying to load a FBX on HoloLens using Assimp and Unity.

    I managed to create, build & deploy (I'm not saying it's working, just building) a Unity project with AssimpNet loaded as a plugin, but I get an exception when trying to load the Assimp DLL on runtime (from AssimpLibraryUWPImplementation.NativeLoadLibrary() ) : It seems that the application is unable to locate the Assimp DLL ("The specified module could not be found. (Exception from HRESULT: 0x8007007E)").

    I have to admit I have absolutely no idea where to put the Assimp DLL (assimp-vc140-mt.dll, right ?) in the solution. I tried to put it in the different projects of the solution, and even in the same folder as the AssimpNet DLL ("Assets/Plugins/WSA/x86"), but nothing works. Do you know what I am missing ?

    I looked at stuff like the LoadPackagedLibrary documentation or this : https://social.msdn.microsoft.com/Forums/windowsapps/en-US/26013e5e-3ff1-44a0-8797-0474dabd12d0/uwpincluding-dlls-in-a-uwp-application-in-visual-studio, but I'm still stuck with this error.

  11. Log in to comment