HawkXP71 122 Posted yesterday at 04:18 PM Posted yesterday at 04:18 PM Blame this question as a remnant of my C++ work. Does it matter what version of C# a plugin uses? Ie, can I use the latest and greatest release? or must I use a range of versions?
Solution Luke 43086 Posted yesterday at 05:59 PM Solution Posted yesterday at 05:59 PM Hi, it doesn't matter.
HawkXP71 122 Posted yesterday at 06:01 PM Author Posted yesterday at 06:01 PM Thanks! 1 minute ago, Luke said: Hi, it doesn't matter.
pünktchen 1422 Posted yesterday at 06:51 PM Posted yesterday at 06:51 PM 49 minutes ago, Luke said: Hi, it doesn't matter. But plugins should target .Net Standard 2.0 and that is only C# 7.3. 1
yocker 1902 Posted yesterday at 07:17 PM Posted yesterday at 07:17 PM 25 minutes ago, pünktchen said: But plugins should target .Net Standard 2.0 and that is only C# 7.3. *SHOULD!*
Luke 43086 Posted yesterday at 07:33 PM Posted yesterday at 07:33 PM 15 minutes ago, yocker said: *SHOULD!* You don't have any in the catalog targeting higher than that, do you?
yocker 1902 Posted yesterday at 08:22 PM Posted yesterday at 08:22 PM (edited) 49 minutes ago, Luke said: You don't have any in the catalog targeting higher than that, do you? .net 6 If that's a problem i guess i have my work cut out for me converting them. Edited yesterday at 08:22 PM by yocker
Luke 43086 Posted yesterday at 08:22 PM Posted yesterday at 08:22 PM Just now, yocker said: .net 6 in the catalog?
yocker 1902 Posted yesterday at 08:23 PM Posted yesterday at 08:23 PM Just now, Luke said: in the catalog? Yes. Never knew that would be a problem, sorry if it is.
Luke 43086 Posted yesterday at 08:26 PM Posted yesterday at 08:26 PM Yea which ones? We will have to remove those because it will cause server crashes on platforms that still use the mono runtime and not dotnet. Alternatively, if you can get them down to netstandard 2.0 then that would be best.
yocker 1902 Posted yesterday at 08:32 PM Posted yesterday at 08:32 PM 3 minutes ago, Luke said: Yea which ones? We will have to remove those because it will cause server crashes on platforms that still use the mono runtime and not dotnet. Alternatively, if you can get them down to netstandard 2.0 then that would be best. All 3, EmbyCredits, EmbyIcons and TimeMarkEdit. Damn.. I have a lot of work in front of me. I do have a version of EmbyCredit on netstandard 2.0 i have maintained along side the main one but it isn't tested properly. Anyway, good to know so it can be fixed and i won't cause problems. 1
Luke 43086 Posted yesterday at 08:36 PM Posted yesterday at 08:36 PM if cover art can do it then I'm sure those can too.
yocker 1902 Posted yesterday at 08:38 PM Posted yesterday at 08:38 PM 1 minute ago, Luke said: if cover art can do it then I'm sure those can too. Just hard work, though TimeMarkEdit should be rather easy as it isn't the biggest plugin out there. 1
softworkz 5378 Posted yesterday at 10:32 PM Posted yesterday at 10:32 PM C# Version The C# version is largely irrelevant and (mostly) independent of the target framework. The C# compiler version determines the language features which the source code can use - but it still needs to compile code in a way that is compatible with the targeted framework. There exist a few very specific exceptions but but this doesn't change the big picture: You can compile a class library targeting netstandard2.0 with the latest C# compiler version just fine.
softworkz 5378 Posted yesterday at 10:38 PM Posted yesterday at 10:38 PM netstandard2.0 TargetFramework This is a hard requirement for EmbyServer plugins as documented. Since yesterday, the plugin portal rejects plugin dlls which are not targeting netstandard2.0. It is not a change of policy - it's just an added check which should have been there ever since. @yocker - We are in the same boat in this regard. But it doesn't meant that all code needs to be rewritten. We have solutions for most of the typical issues (like via extension methods etc.) If you can assemble a list of code changes that are biting you, we can share the solutions we have, so that you don't need to rewrite all your code. 1
yocker 1902 Posted 23 hours ago Posted 23 hours ago 18 minutes ago, softworkz said: @yocker - We are in the same boat in this regard. But it doesn't meant that all code needs to be rewritten. We have solutions for most of the typical issues (like via extension methods etc.) If you can assemble a list of code changes that are biting you, we can share the solutions we have, so that you don't need to rewrite all your code. Many, many thanks for the offer! It's only EmbyIcons really and It shouldn't be too difficult, just hard work. An AI should be able to make a summery of the problems i will face and need to fix to lessen the work. It's kinda funny, i actually started the plugin as netstandard. Speaking of the portal, it seems to have problems deleting old versions. In case you are not aware.
softworkz 5378 Posted 35 minutes ago Posted 35 minutes ago 23 hours ago, yocker said: Many, many thanks for the offer! It's only EmbyIcons really and It shouldn't be too difficult, just hard work What I mean is that we have many extension methods available which are doing the same things as the newer .ent APIs are doing, which means in turn that no code changes are needed at all (except some usings.
softworkz 5378 Posted 34 minutes ago Posted 34 minutes ago 23 hours ago, yocker said: Speaking of the portal, it seems to have problems deleting old versions. In case you are not aware. @ebr
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now