Open birbilis opened 8 years ago
Actually, this is work in progress. Kinect has a number of issues in WinRT, but a unified solution seems feasible. It's part of our upcoming update.
In terms of reusability, the solution you propose is, indeed, necessary.
btw, I could help on that (have become quite proficient in that Code Compare extension [https://visualstudiogallery.msdn.microsoft.com/dace3633-0b51-4629-85d4-c59cdce5bb3b] while merging WPF and Silverlight codebases of various libraries in ClipFlair project [http://clipflair.codeplex.com])
However, a thing I noticed is that if I have Kinect 1.8 SDK installed and I install Kinect 2.x SDK, the v2 projects from Vitruvius seem to find the Kinect.dll from the 1.8 SDK and not find the Kinect.Face one. How come? I'd expect them to use different DLL names there or have strong names etc. Do I have to browse and find the Kinect v2 DLLs. Or are they installed in the GAC only when I plug-in a Kinect v2 device which I don't have? (quite unfortunate design they have in that case).
Your feedback is valuable. We are not using the Shared Project Reference Manager because it only supports Visual Studio 2013.
Instead, we are working with conditional compilation symbols with preprocesor directives. We add the source code files "as a link" into multiple projects. This way, we only maintain one reusable file.
We are trying to support .NET 4.5, WinRT, and Unity3D.
To use a Kinect v2 dll, you have to navigate to C:\Program Files\Microsoft SDKs\Kinect\v2.0_1409\Assemblies
I think Visual Studio 2015 has support for it via a template: http://dailydotnettips.com/2015/07/28/using-shared-project-across-multiple-applications-in-visual-studio-2015/
and it's not only for Windows 8.1 Universal app projects as it once was
I also use the linked files approach in ClipFlair's code instead of the Shared Projects one (had done it more or less for the same reason you have mentioned, was using VS2012 when I started that project anyway), but compared to Shared Projects it has the fuss of adding links manually and an even greater fuss when you want to rename files (have to remove them from projects, rename the originals, close the projects and reopen [due to VS bug] and add the linked files again to the projects they were being used - or else edit project files by hand to rename)
In current version of Vitruvius at GitHub I didn't see any linked files, are you working offline or at other branch I didn't notice for the merged version?
btw, please consider merging this pull request: https://github.com/LightBuzz/Vitruvius/pull/6
it doesn't cause any backwards compatibility issues to Vitruvius for Kinect v1 users, just has a file structure more close to the Vitruvius for Kinect v2 version (plus some small code optimizations at one of the WPF extensions)
Thanks, I have added you as a contributor in the README file.
Regarding the shared code approach, we have been working internally to support .NET, WinRT and Unity. The reason we do not have a separate branch for this is that Unity is not part of the project (and, so far, it doesn't seem feasible to support it in a universal assembly). We'll commit and push our updates soon.
thanks, I'll keep an eye here for the updates
btw, just added a new pull request (cleanup / small optimization at the Kinect v1 solution) - https://github.com/LightBuzz/Vitruvius/pull/9
I believe it would be better to reuse code between WPF and WinRT versions of the Kinect v2 version of the library, using shared projects (and conditional compilation blocks) as shown near the end of this article: http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2014/11/17/shared-projects-common-libraries-on-kinect-for-windows-v2-sdk-bits.aspx
btw, a very nice free extension for Visual Studio to compare/merge code files is Code Compare (you get intellisense etc. while editing/merging stuff)