Port to .NET Core/HoloLens
Issue #3
resolved
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 (17)
-
repo owner
-
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?
-
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/
-
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.
-
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.
-
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?
-
repo owner
I ran it with just netcoreapp 1.1 ticked.
-
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...
-
Hey, any progress on this? Waiting for 2.0?
For Enviroment.OSVersion I guess RuntimeInformation would work.
-
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.
-
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?
-
reporter
Actually, the next Unity version (2017.1) which is in beta currently, will include Mono 4.8 as an experimental preview. After a while (end of the year/next year maybe?), when all the bugs are ironed out, the current Mono 2.x-based runtime will be phased out (finally!).
EDIT: here's a forum thread about it: https://forum.unity3d.com/threads/future-plans-for-the-mono-runtime-upgrade.464327/
-
repo owner
And I just saw it released.
Dropping .net 2.0 like a hot potato :D
-
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.
-
repo owner
FYI, I resolved the IL patching issue and created a netstandard msbuild nuget package that all of my projects will be using shortly. I briefly considered using the new Unsafe library from Microsoft, but I didn't want the dependency (and if I was going to use ILMerge...I may as well continue IL patching), plus that lib didn't cover all the functionality I have in my own patching scheme.
There have been a few updates to native Assimp since the last time I looked, I plan on getting AssimpNet to feature parity with the native lib and supplying new DLLs -- including mac/linux binaries, since the nuget package will be a netstandard lib.
Edit: Oh and upgrading to the new csproj format...and with the new ILPatcher that means you'll be able to compile the lib in the dotnet CLI environment :)
-
@Starnick Sounds great. I will definitely start using your package if it is targeting netstandard. Cheers!
-
repo owner
- changed status to resolved
Sorry it's taken this long. But the repository is updated to target .Net Standard 1.3 like TeximpNet and I've updated to be able to use the latest Assimp release (4.1.0)
Still need to do a few things before publishing a new nuget package.
@ericmellino FYI, I rewrote the sample to use your Veldrid library since it's a .net core app now. Works pretty nicely thumbs up
- Log in to comment
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.