* Remove COM reference for .NET Core
Removing only COM reference to get closer to having Jackett to run on .NET Core for Windows
* Handle resources
https://github.com/microsoft/msbuild/issues/4704
* Remove GenerateResourceUsePreserializedResources
* Remove System.Resources.Extensions
https://natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/
This change brings the remaining two projects (Tray and Service) onto the new csproj format. Along with making them simpler and cleaner, its a needed step to get Windows users onto .NET Core
Again, been a careful as possible, so hopefully nothing breaks. Would recommend merging this after .NET Core 3.1 commit gets released and a beta release for this as well
* Update to .NET Core 3.0
Updated Jackett so that it runs on .NET Core 3.0 now
.NET Core 3.0 brings the following benefits https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0/
One of the benefits is the ability to create single file executables. I haven't enabled this yet, but its only a one line change to turn it on (would likely also require some changes to the updater).
This means that builds for LinuxAMDx64, LinuxARM32, LinuxARM64 and macOS will now run on .NET Core 3.0 instead of 2.2. Windows and Mono remain on full framework. Once .NET Core 3.1 is released (November) I'll look to moving Windows over to .NET Core as well
Tested on
-Windows 10 x64
-Debian running Jackett with Mono
-Debian running Jackett standalone (.NET Core)
Really hope I don't break anything with this
Went to have a go at .NET core and it just became too confusing for me with 'Jackett' namespace referring to both Jackett.Common and Jackett
* Remove static configuration class that required prior knowledge of when it was initialised to dependency injected method that ensures all configuration has already occured.
* Specify a different log name for the updater, require a path when running the Jackett updater
* Update to all .NET Standard packages
* Explicitly specify the restore project style
* Move automapper out of the DI framework and put crude detection to prevent it from initializing more than once.
* Move service config service back into shared .NET Framework Library
* Move Content files into shared folder. Make autoface load different assembilies depending on what framework is using it.
* Change my mind on what the shared module should be called. Common Module is too bland.
* DotNet4.SocksProxy is not yet publically .NET Standard. Revert to previous SocksWebProxy package.
* Check in unstaged change to test dependency injection setup.
* Use platform detection that works on mono 4.6+
* Move to use package reference for restoring nuget packages.
* DateTimeRoutines does not have Nuget packages that support .NET Standard (and therefore .NET Core). We will have to include them for now until we can get rid of this dependency.
* Start spliting some interfaces into their own files - this will help by allowing us to split them out in the future into a seperate project so the actual implementations can stay within their respective architectures when required
* Move out common libraries
* Few more tidy up tasks to get things working with .NET Standard
* Restructure the solution layout
* Encoding work to reduce rework later on platforms without Windows codepages (or require compliance with RFC1345)
* Move folder structure around to have more natural layout of the solutions
* DI server configuration to get rid of "temporary" hack and dependency circle for serverservice
* Make all encoding consistent to match the expected encoding casing for earlier versions of mono.
* Move to use package reference for restoring nuget packages.
* Return a task result for this async method.
* Update to a supported version of the .NET Framework. This also has the side effect of allowing us to automatically generate our binding redirects on build.
* Set the solution to target VS2017
* Update test solution csproj file to support being built through MSBuild 15
* Move to use package reference for restoring nuget packages.
* Return a task result for this async method.
* Update to a supported version of the .NET Framework. This also has the side effect of allowing us to automatically generate our binding redirects on build.
* Set the solution to target VS2017
* Update test solution csproj file to support being built through MSBuild 15
junglebus