diff options
author | Gergely Nagy <ngg@ngg.hu> | 2021-06-09 10:28:55 +0200 |
---|---|---|
committer | Gergely Nagy <ngg@ngg.hu> | 2021-06-09 10:28:55 +0200 |
commit | 159c5b85878caba692cab5728b568478330c87e0 (patch) | |
tree | 434bbc3db8575ecdc0cca77f32130af1ee6e0317 /Documentation | |
parent | app-editors/visual-studio-code: removed in favor of upstream app-editors/vscode (diff) | |
download | dotnet-159c5b85878caba692cab5728b568478330c87e0.tar.gz dotnet-159c5b85878caba692cab5728b568478330c87e0.tar.bz2 dotnet-159c5b85878caba692cab5728b568478330c87e0.zip |
remove .NET Core <2.1 remnants
Signed-off-by: Gergely Nagy <ngg@ngg.hu>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/DotnetCore-Bin.md | 43 | ||||
-rw-r--r-- | Documentation/DotnetCore-Src.md | 120 |
2 files changed, 0 insertions, 163 deletions
diff --git a/Documentation/DotnetCore-Bin.md b/Documentation/DotnetCore-Bin.md deleted file mode 100644 index 30040e7..0000000 --- a/Documentation/DotnetCore-Bin.md +++ /dev/null @@ -1,43 +0,0 @@ -# DotNet Core Binary Builds - - -## Binary Packages - -The quickest and easiet way to install dotnet core for gentoo is to use one of the binary packages. - -Runtime: - - * =dev-dotnet/dotnetcore-runtime-bin-2.0.4 - * =dev-dotnet/dotnetcore-aspnet-bin-2.0.3 - -SDK: - - * =dev-dotnet/dotnetcore-sdk-bin-2.1.3 - -The SDK package (2.1.3) already includes the runtime packages (2.0.4) for dotnet core. -The reason for including both is that the SDK is available under x64 platforms but not currently arm32 platforms (such as the Rpi) -So for the Rpi or other arm32 platforms you'll need to use just the runtime packages unless the application your running already has the runtime build in. - - -## ASP .Net Core - -Note currently the required ASP .Net core prebuilt runtimes seem to be unavailable for arm32 / rpi - - * https://github.com/aspnet/Universe/issues/554 - * https://www.devtrends.co.uk/blog/installing-the-asp.net-core-2.0-runtime-store-on-linux - - -## SDK vs Runtime - -The SDK packages allow you to use the dotnet cli tool to compile / build C# Code into Managed Applications. -The runtime packages allow you to use the dotnet cli tool to run pre-compiled applications. - -Normally when you compile a dotnet core application, you have one of two options. - - * Compile it as a platform independent .dll file which doesn't include the runtime - * Compile it as a platform specific executable file which does include the runtime - using a runtime identifier - -For platform independent .dll files these require the runtime packages on the host to use the dotnet cli tool to run / call the dll to start them as an application. - - * https://stackoverflow.com/questions/43931827/how-to-run-asp-net-core-on-arm-based-custom-linux - diff --git a/Documentation/DotnetCore-Src.md b/Documentation/DotnetCore-Src.md deleted file mode 100644 index 096fb60..0000000 --- a/Documentation/DotnetCore-Src.md +++ /dev/null @@ -1,120 +0,0 @@ -# DotNet Core Source Builds - -I've experimented with building .net core from source and put some notes together below for trying to build under gentoo. -Hopefully these might be useful for a future source based ebuild. - -make sure to use llvm/clang 4.0.1 not 5.0.1 which causes issues with the latest stable 2.0 release. -Although I think this has been fixed within master - -## Dotnet core sandbox issues - -One of the issues currently with dotnet core is that applications seem to fail when run from within the sandbox. -This includes dotnet restore or build - - * https://github.com/dotnet/cli/issues/8305 - * https://wiki.gentoo.org/wiki/Knowledge_Base:Overriding_environment_variables_per_package - -To exclude a particular package from the sandbox we can use the following - -First we use this to create a setting called nosandbox -``` -mkdir -p /etc/portage/env -echo 'FEATURES="-sandbox -usersandbox"' >> /etc/portage/env/nosandbox -``` - -Next we apply this to any ebuilds that need it -``` -echo 'dev-dotnet/dotnetcore-runtime nosandbox' >> /etc/portage/package.env -``` - -I should probably mention that as of writing the current source build of dotnetcore-runtime -doesn't use the dotnet restore command so it currently doesn't need this. But future versions may. - - -## CoreSetup - -Coresetup seems to be a set of scripts used to generate the runtime tar.gz -However I don't think these can be used currently to generate the sdk. - -I'm not sure core-setup actually builds source or just partially builds source and partially copies pre-compiled libraries in - -To clone the source -``` -git clone https://github.com/dotnet/core-setup.git -cd core-setup/ -git checkout v2.0.4 -``` - -To trigger the build -``` -./init-tools.sh -./build.sh -ConfigurationGroup=Release -SkipTests -``` - -The place to look for .tar.gz files is - - * Bin/gentoo-x64.Release/packages - * Bin/linux-x64.Release/packages - -From the looks of things the tarball gz is generated by the below target -``` -./Tools/msbuild.sh src/pkg/packaging/dir.proj /p:UsePrebuiltPortableBinariesForInstallers=true /flp:v=diag /p:TargetArchitecture=x64 /p:PortableBuild=false /p:ConfigurationGroup=Release /p:OSGroup=Linux /p:SharedFrameworkPublishDir=/root/test1/core-setup/Bin/obj/linux-x64.Release/sharedFrameworkPublish/ /target:GenerateTarBall -``` - -It's also worth checking out the commands under **buildpipeline/Core-Setup-Linux-BT.json** to see what's being run inside there - - -## Source Build - -Source build seems to be a set of scripts that sits on top of everything else including CoreSetup -But I've not managed to get it to work fully yet. - -``` -git clone https://github.com/dotnet/source-build.git -cd source-build -git checkout dev/release/2.0 -git submodule update --init --recursive -``` - -I've found you may need to edit **tools-local/tasks/Microsoft.DotNet.SourceBuild.Tasks/GetHostInformation.cs** -So that it always returns true and sets the OS to Linux - -To experiment building some stuff -``` -./build.sh /p:RootRepo=coreclr -./build.sh /p:RootRepo=sdk -``` - - -## Building CoreCLR / CoreFX directly - -If you want to try compiling the CoreCLR / CoreFX repo's directly - -In order to build the libraries a version of the dotnet cli / sdk is needed as part of a boostrap process -These typically end up un Tools/ -usually build.sh will call these scripts at the beginning -``` -./init_tools -./sync.sh -``` - -I've found that RuntimeOS needs to be specified for corefx to work right - -coreclr: -``` -./clean.sh -all -./build.sh -release -buildArch=x64 -SkipTests -``` - -corefx: -``` -./clean.sh -all -./build.sh -release -buildArch=x64 -SkipTests -RuntimeOS=rhel.7 -``` - -I've found that for some reason the build defaults to strict mode which treats warnings as errors -If this happens then one way around it is to add the following to the .csproj file -``` -<NoWarn>CS8073</NoWarn> -``` - |