version method now needed for C# wrapper + some idiomatic fixups
dmedine opened this issue · comments
Moving the discussion from here: #10
I read through the discussion and I still don't see why another version is needed.
I looked at the wrapper and all the LSL classes are subclasses of LSL.liblsl, i.e. LSL.liblsl.StreamInfoetc.
They should be in the root namespace, but this will break the examples and existing client code.
I looked at the wrapper and all the LSL classes are subclasses of LSL.liblsl, i.e. LSL.liblsl.StreamInfoetc.
Right, they should be in the root namespace.
They should be in the root namespace, but this will break the examples and existing client code.
Yes, and so would have your suggestion of changing the class name liblsl to lsl---which is precisely why the wrapper needs versioning. Also, the IDisposable implementation warrants this. Also, pylsl has versioning as does every NuGet package I have ever used.
I am sorry to say that I am getting exhausted with discussing this. I am going to craft a PR and you can reject it if you don't like it.
Also, the
IDisposableimplementation warrants this.
Client code doesn't use using: no change needed, LSL objects get disposed of when the GC calls the finalizer, no matter the wrapper version.
Client code uses using: the LSL wrapper needs to be new enough, i.e. implement IDisposable or compilation fails. Ergo, a function that returns the wrapper version can't be called.
Yes, and so would have your suggestion of changing the class name liblsl to lsl---which is precisely why the wrapper needs versioning.
That's true. But the place for the wrapper version is in the package metadata / LSL.csproj, not in the code.
That's true. But the place for the wrapper version is in the package metadata / LSL.csproj, not in the code.
I have never done a NuGet package before. Can clients access the version info if they build from source? I also fear distributing the underlying C/C++ libs for every os on earth in a NuGet package. It seems like this requires visual studio tools that I don't have a subscription for.
I have never done a NuGet package before. Can clients access the version info if they build from source?
Probably something like Assembly.GetMumboJumboInfoFromClass(LSL.LSL).Version, because the version in the csproj file is baked in the assembly / dll.
I also fear distributing the underlying C/C++ libs for every os on earth in a NuGet package.
It's on my todo list in the more or less distant future and probably easier than I expect.
It seems like this requires visual studio tools that I don't have a subscription for.
From what I've read it's a matter of putting the binaries and an xml formatted header in a zip file and rename it to something.nuget. CPack can also generate Nuget packages, but that might be overkill and requires nuget to be installed.