Add a .csproj for the .NET wrapper

[aalmada]

It would be much easier to develop a RealSense .NET project if Intel.Realsense was available in NuGet. The one found there is not "official".

This PR adds a .csproj file that includes all the required information to create the package. It can be done by executing the CLI command dotnet pack.

The .csproj includes the following features:

• Targets netstandard2.0 so that the assembly can be used both on .NET Framework and .NET Core projects.
• Includes all the title, description, company and copyright that was on the AssemblyInfo.cs file. This file was deleted as it's not required anymore.
• Includes the license and the icon image that was already available in the repository.
• Generates and includes in the package the inline documentation. Generated in Release mode only.
• The packages.config file was deleted as it's been deprecated. Dependencies are added directly on the .csproj file.
• Adds SourceLink so that developers, when debugging, can step into the code from this repository. No dependencies are added to the package
• Adds StyleCop as a private asset so that no dependencies are added to the package.
• Adds the native realsense2.dll assembly to the package so that projects work out-of-the-box. It assumes that the native project outputs the .dll to <RepositoryPath>\build\Release\.

[aalmada]

I now noticed the build script still uses .NET 4.5. Is .NET Core 3.0 supported on the build machines?

I added the target net45 to the .csproj so that package can be used both on older and newer versions of .NET.

[aalmada]

@matkatz @dorodnic Analyzing the CI logs I noticed the .csproj is generated by CMAKE. It's also using the old VS2015 format. Since then the .csproj file format as changed considerably. To be able to support .NET Core and the new .NET CLI tools the format here has to be updated. Please consider the features in this PR.

It would be great if the package was made available on NuGet.

NOTE: Unity now supports netstandard2.0. There's no need to target net35.

[dorodnic]

Hi @aalmada Thank you for the contribution. You are raising several good points we have to consider (it's been a while since this model for the .NET wrapper was established). I also want to understand how having a NuGet package can co-exist with CMake since the entirety of the rest of librealsense is CMake based. Let me also tag @ogoshen who has significant experience with C# and Unity.

[aalmada]

@dorodnic @ogoshen IMHO I don't see how CMake can be useful in the .NET project. I understand that CMake is very useful to guarantee that the build environment is cross-compiler and cross-platform. The .NET Core build tools are cross-platform and there are only two compiler (Roslyn and Mono) and these support the same project syntax. One of the big changes in the .csproj syntax is that you don't need to specify what source files to include. Only the source files you want to exclude. This makes the project file have a very long life span without changes. I created a example of how to add support for RealSense on a .NET project. Notice that, if Intel.RealSense package is made available as a NuGet package, the project is only composed of two files: https://github.com/aalmada/RealSenseExample/tree/master I tested it with a local NuGet package and it works fine. These are just my two cents... 😉

[aalmada]

Thinking about it some more, I realized there's an issue, not with the build tools but, with the native DLL included in the package. The .csproj of this PR includes only one for one environment. It's possible to add multiple native DLLs for multiple environment, including non-Windows ones. I need to look into how it's done in https://github.com/xoofx/libclang

[dorodnic]

CMake is less critical in this case for cross-platform aspect, but it helps in keeping a single build process. Prior to CMake integration the steps for the .NET wrapper were build the native SDK somewhere (presumably under /build), open a different solution with the .NET wrapper and make sure it points to the correct place where you build realsense2.dll. Now it's always in sync.

We could add Nuget packaging at some later stage in our release process, when we already have both 32 and 64 bit versions of realsense2.dll, to achieve something like libclang.

[ogoshen]

I'm also generally in favor of upgrading the csproj, but there are a few other things to consider.

So first, as mentioned this would break VS2015, which would still be nice to support. This could still be done using shell scripts \ cmake flags to generate a VS2015 project. VS>=2017 & dotnet CLI can use the new project format, which would be the default. Just need to stress that having a proper VS solution with both librealsense2 and the .NET wrapper is important for native code debugging.

I think nuget packaging deserves its own issue on GH, it's mostly CI related though... Packaging would probably be easiest with the cli, but we'll need native x86\64 libraries for all supported OSes, I've tested this locally for Windows & Linux, targeting net45 & netstandard2.

[aalmada]

I understand that you want to be all inclusive but why not apply the 80/20 rule? I'd say most .NET developers don't know how to use CMAKE, very few still use VS2015 and most using RealSense are on Windows 64 bits. All the other few ones should keep using CMAKE for their custom builds.

[Nir-Az]

@ArthurRaizIntel this is an old PR, could be not relevant but can you take a look ?