Page 1 of 1

WinRT Managed DLL?

Posted: Mon May 14, 2012 1:56 pm
by qbcm
Has anyone attempted yet to get the existing BEPUphsyics library running in Windows8?

I'm attemptying to utilise the existing dependency-free fork of BEPUphysics to be used as a managed DLL from a Visual C++ project. Any tips would be greatly appreciated.

Re: WinRT Managed DLL?

Posted: Mon May 14, 2012 3:05 pm
by Norbo
Sorry, I've never tried it. Are you encountering any specific problem?

It sounds like it would mostly work, but it may require pulling the source in and modifying a few pieces to make it compliant.

Re: WinRT Managed DLL?

Posted: Mon May 14, 2012 4:00 pm
by qbcm
I've run into quite a mixture of problems actually.

The first I hit was with regard to generic types. According to Microsoft, WinRT component libraries cannot include generic types other than those provided by System. Specifically, the error was around the Space class, where it has a generic class (ReadOnlyList<Entity> I think).

I then had the idea of creating a wrapper class in C# that would communicate directly with my Visual C++ code and wrap any calls made into something that I knew could communicate via the interop stuff. I could get my C# wrapper talking with my VC++, but as soon as I started including communication in the other direction to BEPU, I was getting further issues.

The first of note, was that BEPU was making reference to System.Threading.Thread which it seems is no longer in the same namespace hierachy in win8. In the interest of trying to see how far I could push the bug collecting I modified the BEPU code to remove references to Thread. This presented a different problem where the compiler reported it encountered errors implicitly converting BEPU classes to an equivalent it could work with. I'm no great expert on any of this at this stage, but I do recall reading somewhere that the WinRT interop would try and convert class types to an equivalent in the host language.

My next experiment was to modify the C# wrapper project so that it was stand-alone and would reference the BEPU DLL, while my VC++ communicated with the Wrapper. This fell down when adding the BEPU DLL reference to the wrapper as it said that it could not add a reference to something that uses ".NetFramework" rather than ".NetCore". This implies to me that I'll need to port the BEPU code into a new C# WinRT Component Library.

Hopefully it shouldn't take a great deal of time to do, but as I got to this point I thought it would be a good idea to ask the question just in case someone had already de-mistified the process.

Re: WinRT Managed DLL?

Posted: Mon May 14, 2012 4:38 pm
by Norbo
Oof, that's a bit more annoying than I hoped it would be- especially the generics issue. Good luck with the port; if you need some information about some BEPUphysics detail, just let me know :)

Re: WinRT Managed DLL?

Posted: Mon Sep 03, 2012 7:31 pm
by holophone3d
Any idea of if any further progress has been made in the BEPU WinRT space? I'd be interested in contributing, but I'd like to avoid re-doing everything if progress has been made here.Given some of the stuff that's happening with c# Metro XNA development with MonoGame and SunBurn, I think WinRT BEPU definitely makes sense.

Re: WinRT Managed DLL?

Posted: Mon Sep 03, 2012 7:57 pm
by ecosky
I saw this quote here: http://msdn.microsoft.com/en-us/library ... s/br230301.
Note
If you are creating a component for use only in Metro style apps with Visual Basic or C#, and the component does not contain Windows Metro style controls, consider using the Class Library (Windows Store apps) template instead of the Windows Runtime Component template. There are fewer restrictions on a simple class library.
Is there any chance that the class library template does not have this generic issue and could be used instead?

Re: WinRT Managed DLL?

Posted: Mon Sep 03, 2012 8:22 pm
by Norbo
Any idea of if any further progress has been made in the BEPU WinRT space? I'd be interested in contributing, but I'd like to avoid re-doing everything if progress has been made here.Given some of the stuff that's happening with c# Metro XNA development with MonoGame and SunBurn, I think WinRT BEPU definitely makes sense.
I'm not personally aware of any additional work on it, though that doesn't mean much.

A community effort to get it set up would be nice since it doesn't quite fit into my workload budget at the moment :) As always, I'll be here to answer and help with what I can.
Is there any chance that the class library template does not have this generic issue and could be used instead?
That does appear to be a much better fitting approach, at least for users sticking to VB or C#. I haven't played with it or read into it much, but I'd hope it would be much more direct than the thick wrapper or partial rewrite seemingly required by a component library approach.

It would be nice to support the non-VB/C# developers, though. The path to supporting those platforms with the least possible effort may be more clear once a VB/C# winrt class library fork is available.