diff options
author | Jan Tojnar <jtojnar@gmail.com> | 2021-06-05 21:22:45 +0200 |
---|---|---|
committer | Jan Tojnar <jtojnar@gmail.com> | 2021-06-07 06:34:59 +0200 |
commit | 6ecc641d087df8b8896ebd876bba592e981877c9 (patch) | |
tree | c3dc98e6b6a4a6474b21ad06e7bbc96d0e8abaf5 /doc/languages-frameworks/dotnet.section.md | |
parent | ce6b1a4f8f9cbbb7fd2d1c637bcc39fff1ef49df (diff) | |
download | nixpkgs-6ecc641d087df8b8896ebd876bba592e981877c9.tar nixpkgs-6ecc641d087df8b8896ebd876bba592e981877c9.tar.gz nixpkgs-6ecc641d087df8b8896ebd876bba592e981877c9.tar.bz2 nixpkgs-6ecc641d087df8b8896ebd876bba592e981877c9.tar.lz nixpkgs-6ecc641d087df8b8896ebd876bba592e981877c9.tar.xz nixpkgs-6ecc641d087df8b8896ebd876bba592e981877c9.tar.zst nixpkgs-6ecc641d087df8b8896ebd876bba592e981877c9.zip |
doc: prepare for commonmark
We are still using Pandoc’s Markdown parser, which differs from CommonMark spec slightly. Notably: - Line breaks in lists behave differently. - Admonitions do not support the simpler syntax https://github.com/jgm/commonmark-hs/issues/75 - The auto_identifiers uses a different algorithm – I made the previous ones explicit. - Languages (classes) of code blocks cannot contain whitespace so we have to use “pycon” alias instead of Python “console” as GitHub’s linguist While at it, I also fixed the following issues: - ShellSesssion was used - Removed some pointless docbook tags.
Diffstat (limited to 'doc/languages-frameworks/dotnet.section.md')
-rw-r--r-- | doc/languages-frameworks/dotnet.section.md | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/doc/languages-frameworks/dotnet.section.md b/doc/languages-frameworks/dotnet.section.md index 725ffd4becc..1bcb6e45210 100644 --- a/doc/languages-frameworks/dotnet.section.md +++ b/doc/languages-frameworks/dotnet.section.md @@ -1,6 +1,6 @@ -# Dotnet +# Dotnet {#dotnet} -## Local Development Workflow +## Local Development Workflow {#local-development-workflow} For local development, it's recommended to use nix-shell to create a dotnet environment: @@ -16,7 +16,7 @@ mkShell { } ``` -### Using many sdks in a workflow +### Using many sdks in a workflow {#using-many-sdks-in-a-workflow} It's very likely that more than one sdk will be needed on a given project. Dotnet provides several different frameworks (E.g dotnetcore, aspnetcore, etc.) as well as many versions for a given framework. Normally, dotnet is able to fetch a framework and install it relative to the executable. However, this would mean writing to the nix store in nixpkgs, which is read-only. To support the many-sdk use case, one can compose an environment using `dotnetCorePackages.combinePackages`: @@ -37,7 +37,7 @@ mkShell { This will produce a dotnet installation that has the dotnet 3.1, 3.0, and 2.1 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output: -```ShellSesssion +```ShellSession $ dotnet --info .NET Core SDK (reflecting any global.json): Version: 3.1.101 @@ -60,15 +60,15 @@ $ dotnet --info Microsoft.NETCore.App 3.1.1 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App] ``` -## dotnet-sdk vs dotnetCorePackages.sdk +## dotnet-sdk vs dotnetCorePackages.sdk {#dotnet-sdk-vs-dotnetcorepackages.sdk} The `dotnetCorePackages.sdk_X_Y` is preferred over the old dotnet-sdk as both major and minor version are very important for a dotnet environment. If a given minor version isn't present (or was changed), then this will likely break your ability to build a project. -## dotnetCorePackages.sdk vs dotnetCorePackages.net vs dotnetCorePackages.netcore vs dotnetCorePackages.aspnetcore +## dotnetCorePackages.sdk vs dotnetCorePackages.net vs dotnetCorePackages.netcore vs dotnetCorePackages.aspnetcore {#dotnetcorepackages.sdk-vs-dotnetcorepackages.net-vs-dotnetcorepackages.netcore-vs-dotnetcorepackages.aspnetcore} The `dotnetCorePackages.sdk` contains both a runtime and the full sdk of a given version. The `net`, `netcore` and `aspnetcore` packages are meant to serve as minimal runtimes to deploy alongside already built applications. For runtime versions >= .NET 5 `net` is used while `netcore` is used for older .NET Core runtime version. -## Packaging a Dotnet Application +## Packaging a Dotnet Application {#packaging-a-dotnet-application} Ideally, we would like to build against the sdk, then only have the dotnet runtime available in the runtime closure. |