Move Managed-OSVR into its own repo

[JeroMiya]

I'll be working on an OSVR-MonoGame when this goes fully open source. Please move the Managed-OSVR code into its own repo to facilitate this. Other community contributed ports/integration efforts would benefit as well.

I didn't see any at first glance, but if there is any unity-specific code in OSVR-MonoGame, please #ifdef it or preferably factor the code out into a partial class implementation or configurable helper class, per your choice. It would be helpful for me, not having any unity experience, to add some explanation into what the unity code is doing so I can determine whether it is even applicable to a MonoGame port.

I'll leave it up to you to determine the best way to get Managed-OSVR into OSVR-Unity, and I'll follow suit with OSVR-MonoGame. Perhaps checking in the binaries, or a git submodule, or a build/copy script, or symbolic links, or a pre-release NuGet package when this repo is fully public.

As an aside: I haven't had a lot of time to review the code, but from what I see so far there seems to be a fair amount of code in the Unity plugin that is not Unity specific. Perhaps some of that can be moved into the Managed-OSVR code instead?

[rpavlik]

Yeah, right now the Managed-OSVR code is basically a direct, thin wrapper around the C ClientKit API that presents an exact equivalent to the C++ ClientKit API. It was written as a means to getting a Unity plugin, but was designed to be separable from Unity, so this is a logical request. There is some (generated) code in the Unity plugin that makes the wrapping a little more C#-idiomatic, particularly regarding callbacks, that probably could get moved over. (I've created a new issue for this: #5 )

There is no Unity-specific code in Managed-OSVR - in the CI build, it is built as its own step with msbuild and copied over into the Unity source directory. It has its own test/example applications as well. That directory could more or less be extracted to its own repo.

I fully agree it would be easier to develop (or at least even discover the possibility of) other uses of the .NET binding putting Managed-OSVR in its own repo. I hadn't heard of MonoGame before, but I think that an integration with it would be a great contribution. (and a great separate repo 😄 )

I'm not super familiar with C#/.net packaging norms, but I get the impression that NuGet and MyGet feeds are popular. (I've started getting introduced to them through Chocolatey.) I imagine that NuGet would probably be useful at least to non-Unity users, and could probably be shoe-horned into working with the Unity build as well. (Created #4 to track this one.)

Forks and pull requests for any of the items you brought up (or any other contributions) would be greatly appreciated, at least once this goes fully open-source. I'm unsure of the contribution policy before that point, but I can get you in touch with the people who do know this if you would like to pitch in.

@OSVR/owners - can we get a GitHub account upgrade to add an additional private repo to split out Managed-OSVR from the Unity-specific code in here, or must this wait until public release?

[JeroMiya]

Until unity 5 fully supports IL2CPP and .net 4.5+, I may also need a separate project with a .net 4.5+ build of Managed-OSVR.

[rpavlik]

For someone without a lot of. Net experience, what do you mean there? The current framework is a .net 2.0 build for unity compatibility. If a 4.5 build is needed, can that be fine from roughly the same source tree, perhaps with some #if?

[JeroMiya]

Yes, the same source tree should be OK for now. Just create two vs projects that link the same files. Often when I do this I move the shared source up one level into a subdirectory of the solution, but it doesn't have to be:

/SolutionDir
    SolutionDir.sln
    /SharedCode
       SharedCode.cs
    /ProjectA
       ProjectA.csproj
    /ProjectB
       ProjectB.csproj

[JeroMiya]

Some questions from @rpavlik from #6

Q: Do people usually use a single nuget provider or should we be using myget for example?
A: Registration on NuGet.org is the preferred way. Registration on MyGet et. al. is typically for private nuget repo scenarios - internal development, etc... It's an option if you need some internal builds, but generally speaking open source projects are registered on NuGet.org to take advantage of the ecosystem.

Q: Is there a preferred way to handle providing bins for the two framework versions?
A: Yes. You can create a single NuGet package with bins for multiple framework versions. See here for documentation: https://docs.nuget.org/Create/Enforced-Package-Conventions

Q: How about distributing the native libraries?
A: This appears to be still something NuGet doesn't support natively (http://nuget.codeplex.com/workitem/679) but there seem to be a few workarounds (the powershell script solution doesn't work cross platform though):
https://npe.codeplex.com/discussions/462174
http://stackoverflow.com/questions/7769580/how-should-i-create-or-upload-a-32-bit-and-64-bit-nuget-package

[rpavlik]

OK, I split out the repo, though I haven't ported the Unity code in this repo to use it yet. https://github.com/OSVR/Managed-OSVR