Emby
Emby copied to clipboard
joshuaboniface
Replace Mono with .NET Core
Replace the Mono dependency with .NET Core which is more future-proof.
It looks like this is not a drop-in replacement unfortunately. While I can replace msbuild with dotnet msbuild, the Debian package configuration is very dependent on the Mono toolchain. It would need to be almost entirely rewritten.
@dcrdev Hoping to get some input from your side here (without clogging up the emby-unlocked issue!)
It looks like you made some major replacements within the code to get this to work. Was that automated, or a manual process? Your repo looks to be based off of 3.3.1 so some of the project files are missing or changed in 3.4.1.
@joshuaboniface
- The project definitions i.e. the csproj files aren't the same files used by the Emby guys to push out their releases, the false project files in their repo doesn't contain the necessary targets to build against .net core. There is no automated way of converting a .net framework style csproj to a .net core one. Merge upstream changes is very much a manual process because of it, for each project in the solution you have to make note of which package versions upstream are using and update your csproj.
- In made some minor changes to the c# source for a couple of projects because they referenced alternate versions of certain projects using different namespaces - again the releases on emby.media are not representative of the code in their repo.
- I also removed various components that were Windows / OS X specific and ofcourse the Mono server application because they were not needed.
- I implemented a custom implementation of the EmbyServer loader entry point application - again because upstream have chosen not to release this; I have not published this fore previously mentioned reasons. Again I must emphasise that what your doing in your repo - will not work without this component!
So no quite automated...
Today's commit and still a lot to do , to get the upstream merge working: https://github.com/dcrdev/Emby/commit/0053d119136fdd02a89de370dfb90b7f2d6a2199
@dcrdev Are you basing off the 3.5 branch, or 3.3? Maybe forking 3.4 wasn't the best call! 😆
I tried porting some of your changes to the dotnetcore branch but ended up running out of time due to the sheer amount of changes in the intervening versions. Would you be willing to try rebasing against the version I've got here to see how that works out?
@joshuaboniface It's currently based off 3.5 - it was previously based on 3.3, but have merged upstream and now am largely based on 3.5 with modifications. You can see that from the history: https://github.com/dcrdev/Emby/commits/master
There's no reason to stay on 3.4 - I believe your original motivation was to pull the last version that built under mono. Since your aim supposedly is to build under .net, it no longer makes sense to stay on 3.4. 3.5 uses higher package versions of certain nuget dependencies that previously would not build under .net standard - now they do. Overall it's easier to retrofit .net core support into 3.5 than it is <3.4.
What you want to do is actually make use of gits inbuilt functionality to merge to resolve conflicts - it's how I merge upstream, I don't manually replace files as you seem to be...
See: https://help.github.com/articles/merging-an-upstream-repository-into-your-fork/
I would merge upstream and then merge my fork into yours and resolve the conflicts.
I have a working 3.5.2 .NET Core 2.1 based build in my private git - I'll put it online later this week.
@h3ge Any update on your fork?
So many forks. It seems like it would be useful to get all of the people forking and working on individual forks to rally around one fork. More hands... and all that.
@brianjmurrell My fork is online and working, you can find it through my profile. But I wont provide any updates for it.
@h3ge:
But I wont provide any updates for it.
Why's that?
Just trying to get the whole lay-of-the-land among the many forks of Emby that have popped up.
I'm going to try to get a fork of @h3ge work plus @nvllsvm unlocking combined. Not going to try to pull from upstream, for now at least.
@JustAMan @h3ge That's awesome! I hope to help test it out.
To be completely honest I haven't had much of an opportunity (or, frankly, desire) to really work on Emby, aside from my rationale document - I just don't know enough about C# to get a handle on it, and I'm starting to lean towards the time-sink side of the argument - for now 3.4 just works well enough for me, as it has for a while. I was mostly hoping to get a lay of the hand and spur action by those who might be interested in a fork, which it seems I've done and I appreciate it. Hopefully we can get something going!
I know nothing of C#, but that's just another programming language, not a big deal :-)
Though I don't intend now to keep up with upstream, but rather utilize most up-to-date version published openly (kudos to @h3ge for that).
I have already built a .deb against netcore 2.1 with your patches applied (plus squashing of mb3admin phoning home), but not tested anything yet. Not even sure it would work :-)
пн, 22 окт. 2018 г., 4:10 Joshua M. Boniface [email protected]:
@JustAMan https://github.com/JustAMan @h3ge https://github.com/h3ge That's awesome! I hope to help test it out.
To be completely honest I haven't had much of an opportunity (or, frankly, desire) to really work on Emby, aside from my rationale document - I just don't know enough about C# to get a handle on it, and I'm starting to lean towards the time-sink side of the argument - for now 3.4 just works well enough for me, as it has for a while. I was mostly hoping to get a lay of the hand and spur action by those who might be interested in a fork, which it seems I've done and I appreciate it. Hopefully we can get something going!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/joshuaboniface/Emby/issues/4#issuecomment-431720726, or mute the thread https://github.com/notifications/unsubscribe-auth/AA9vRq6-paTWUfYMIIxDJrcGrlYzRQYWks5unRsLgaJpZM4V2F9V .
FYI, here's what I want to call a "RC1" :) https://github.com/JustAMan/Emby/releases/tag/3.5.2-unlocked-rc1
This works (or seems to), at least I was able to add a video in the media library and play it back on a few clients.
FYI, here's what I want to call a "RC1" :)
emby-server_3.5.2-unlocked_all.deb: is it really all arches or just a mislabelled arch for the .deb?
What are the requirements?
[x86_|amd]64 or will i[3|6]86 (i.e. 32-bit) work?
.net core?
@brianjmurrell well, I take the original debian scripts from Joshua (and I believe he adapted the even more original scripts from Carlos), so I do not know :) That is, I doubt there are any binary files - all files there seem to be .NET binaries which (usually) do not depend on target architecture. So it should work. Give it a try and tell us! :)
As for dependencies - yes, .net core 2.1 runtime is a dependency. And it is specified in the .deb file, so it would tell you this upon installation time if it cannot fulfill this requirement.
How is this coming on? Since the news today about Emby going completely closed source, I am going to be uninstalling it and am looking for alternatives.
My "rc1" hums along on my lxc-based server, that's good enough for me for now. I do not made a lot of changes there since rc1, though.