Move Managed-OSVR into its own repo about osvr-unity

[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