RHEL 7 で .NET を使い始める
ガイド
概要
Red Hat ドキュメントへのフィードバック (英語のみ)
ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。
特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。
- ドキュメントの表示が Multi-page HTML 形式になっていていることを確認してください。ドキュメントの右上隅に Feedback ボタンがあることを確認してください。
- マウスカーソルで、コメントを追加する部分を強調表示します。
- そのテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される手順に従ってください。
より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。
- Bugzilla の Web サイトにアクセスします。
- Component で Documentation を選択します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
- Submit Bug をクリックします。
第1章 .NET Core の概要
.NET Core は、自動メモリー管理と最新のプログラミング言語を備えた汎用開発プラットフォームです。.NET を使用することで、ユーザーは高品質のアプリケーションを効率的に構築できます。.NET Core は、認定済みのコンテナーを介して Red Hat Enterprise Linux (RHEL) および OpenShift Container Platform で利用できます。
.NET Core には次の機能があります。
- マイクロサービスベースのアプローチに従う機能。一部のコンポーネントは .NET で構築され、他のコンポーネントは Java で構築されますが、すべてが RHEL および OpenShift Container Platform でサポートされている共通プラットフォームで実行できます。
- Microsoft Windows で新しい .NET Core ワークロードをより簡単に開発する能力。RHEL または Windows Server のいずれかにアプリケーションをデプロイして実行できます。
- 異機種環境のデータセンター。基盤となるインフラストラクチャーが Windows Server にのみ依存することなく .NET アプリケーションを実行できます。
.NET Core 2.1 は、RHEL 7、RHEL 8、および OpenShift Container Platform バージョン 3.3 以降でサポートされます。
第2章 Red Hat Enterprise Linux 7 での .NET Core 2.1 の使用
.NET Core 2.1 をインストールする方法と、.NET Core アプリケーションを作成および公開する方法を説明します。
2.1. .NET Core 2.1 のインストール
RHEL7 に .NET Core をインストールするには、最初に.NET Core ソフトウェアリポジトリーを有効にして、scl ツールをインストールする必要があります。
前提条件
割り当てられたサブスクリプションで RHEL 7 をインストールして登録します。
詳細は、「システム登録およびサブスクリプションの割り当て」を参照してください。
手順
.NET Core ソフトウェアリポジトリーを有効にします。
$ sudo subscription-manager repos --enable=rhel-7-variant-dotnet-rpms実行している RHEL システム (RHEL 7 Server、RHEL 7 Workstation、または HPC Compute Node) に応じて、
server、workstation、またはhpc-nodeに variant を置き換えます。システムに割り当てられているサブスクリプションの一覧を確認します。
$ sudo subscription-manager list --consumed
sclツールをインストールします。$ sudo yum install scl-utils -y
.NET Core 2.1 とそのすべての依存関係をインストールします。
$ sudo yum install rh-dotnet21 -y
rh-dotnet21Software Collection 環境を有効にします。$ scl enable rh-dotnet21 bash
この
bashシェルセッションでdotnetコマンドを実行できるようになりました。ログアウト、別のシェルを使用するか、または新しいターミナルを開くと、
dotnetコマンドが有効にならなくなります。警告Red Hat は、他のプログラムに影響を及ぼす可能性があるため、
rh-dotnet21を永続的に有効にすることは推奨していません。たとえば、rh-dotnet21には、ベースの RHEL バージョンとは異なるlibcurlのバージョンが含まれています。これにより、libcurlの別のバージョンのことが予想されないプログラムで問題が発生する可能性があります。rh-dotnetを永続的に有効にする場合は、source scl_source enable rh-dotnet21を~/.bashrcファイルに追加します。
検証手順
インストールを確認します。
$ dotnet --info
出力は、.NET Core インストールおよび環境に関する関連情報を返します。
2.2. .NET Core 2.1 を使用したアプリケーションの作成
C# hello-world アプリケーションを作成する方法を学びます。
手順
my-appという名前のディレクトリーに、新しい Console アプリケーションを作成します。$ dotnet new console --output my-app返される出力は以下のとおりです。
The template "Console Application" was created successfully. Processing post-creation actions... Running 'dotnet restore' on my-app/my-app.csproj... Restoring packages for /home/username/my-app/my-app.csproj... Generating MSBuild file /home/username/my-app/obj/my-app.csproj.nuget.g.props. Generating MSBuild file /home/username/my-app/obj/my-app.csproj.nuget.g.targets. Restore completed in 224.85 ms for /home/username/my-app/my-app.csproj. Restore succeeded.
単純な
Hello Worldコンソールアプリケーションが、テンプレートから作成されます。アプリケーションは指定のmy-appディレクトリーに保存されます。ディレクトリーには、以下のファイルが含まれます。
$ tree my-app my-app ├── my-app.csproj ├── obj │ ├── my-app.csproj.nuget.dgspec.json │ ├── my-app.csproj.nuget.g.props │ ├── my-app.csproj.nuget.g.targets │ ├── project.assets.json │ └── project.nuget.cache └── Program.cs 1 directory, 7 files
検証手順
プロジェクトを実行します。
$ dotnet run --project my-app返される出力は以下のとおりです。
Hello World!
2.3. .NET Core 2.1 を使用したアプリケーションの公開
.NET Core 2.1 アプリケーションを公開して、共有されたシステム全体の .NET Core バージョンを使用するか、.NET Core を追加できます。
.NET Core 2.1 アプリケーションを公開するには、以下のメソッドがあります。
-
フレームワーク依存デプロイメント (FDD): アプリケーションは、共有されたシステム全体の .NET バージョンを使用します。RHEL にアプリケーションを公開する場合、Red Hat は FDD を使用することを推奨しています。これは、アプリケーションが Red Hat が構築した最新バージョンの .NET Core を使用しているためです。これには、特定のネイティブ依存関係のセットが含まれます。これらのネイティブライブラリーは、
rh-dotnet21Software Collection に含まれます。 -
SCD (自己完結型デプロイメント): アプリケーションには .NET が含まれます。この方法では、Microsoft が構築したランタイムを使用します。ネイティブライブラリーが利用できないため、
rh-dotnet21Software Collection 外でアプリケーションを実行すると問題が発生する可能性があります。
前提条件
既存の .NET Core アプリケーション。
.NET Core アプリケーションの作成方法は、「.NET Core 2.1 を使用したアプリケーションの作成」 を参照してください。
2.3.1. .NET Core アプリケーションの公開
手順
フレームワーク依存アプリケーションを公開します。
$ dotnet publish my-app -f netcoreapp2.1 -c Releasemy-app を公開するアプリケーションの名前に置き換えます。
任意: アプリケーションが RHEL 専用の場合は、次のコマンドを使用してその他のプラットフォームに必要な依存関係を削除します。
$ dotnet restore my-app -r rhel.7-x64 $ dotnet publish my-app -f netcoreapp2.1 -c Release -r rhel.7-x64 --self-contained false
Software Collection を有効にし、アプリケーションアセンブリー名を dotnet に渡して、RHEL システムでアプリケーションを実行します。
$ scl enable rh-dotnet21 -- dotnet <app>.dll
アプリケーションと共に公開されるスクリプトに
scl enable rh-dotnet21 PROVISIONING-gitopsdotnet <app>.dllコマンドを追加できます。以下のスクリプトをプロジェクトに追加し、
ASSEMBLY変数を更新します。#!/bin/bash APP=<app> SCL=rh-dotnet21 DIR="$(dirname "$(readlink -f "$0")")" scl enable $SCL -- "$DIR/$APP" "$@"
パブリッシュ時にスクリプトを含めるには、この ItemGroup を
csprojファイルに追加します。<ItemGroup> <None Update="<scriptname>" Condition="'$(RuntimeIdentifier)' == 'rhel.7-x64' and '$(SelfContained)' == 'false'" CopyToPublishDirectory="PreserveNewest" /> </ItemGroup>
2.3.2. ASP.NET アプリケーションの公開
Microsoft SDK を使用する場合、ASP.NET Core 2.1 Web アプリケーションは ASP.NET Core 共有フレームワークの依存関係で公開されます。これは、ランタイムシステムで利用可能であることが予想されるパッケージセットです。
RHEL で公開する場合、これらのパッケージはアプリケーションに含まれます。Microsoft SDK を使用してパッケージを含めるには、以下のようにプロジェクトファイルで MicrosoftNETPlatformLibrary プロパティーを Microsoft.NETCore.App に設定する必要があります。
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<MicrosoftNETPlatformLibrary>Microsoft.NETCore.App</MicrosoftNETPlatformLibrary>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1" />
</ItemGroup>
</Project>このプロパティーは、アプリケーションをパブリッシュするときに設定できます。
$ dotnet publish -f netcoreapp2.1 -c Release -r rhel.7-x64 --self-contained false /p:MicrosoftNETPlatformLibrary=Microsoft.NETCore.App
2.4. コンテナーでの .NET Core 2.1 アプリケーションの実行
dotnet/dotnet-21-runtime-rhel7 イメージを使用して、Linux コンテナー内でプリコンパイルされたアプリケーションを実行します。
前提条件
事前設定されたコンテナー。
以下の例では podman を使用しています。
手順
mvc_runtime_exampleという名前のディレクトリーに新しい MVC プロジェクトを作成します。$ dotnet new mvc --output mvc_runtime_example --no-restoreプロジェクトを復元し、公開します。
$ dotnet restore mvc_runtime_example -r rhel.7-x64 $ dotnet publish mvc_runtime_example -f netcoreapp2.1 -c Release -r rhel.7-x64 --self-contained false /p:MicrosoftNETPlatformLibrary=Microsoft.NETCore.App
Dockerfileを作成します。$ cat > Dockerfile <<EOF FROM registry.redhat.io/dotnet/dotnet-21-runtime-rhel7 ADD bin/Release/netcoreapp2.1/publish/ . CMD ["dotnet", "mvc_runtime_example.dll"] EOF
イメージを構築します。
$ podman build -t dotnet-21-runtime-example .
注記unable to retrieve auth token: invalid username/passwordメッセージを含むエラーが発生した場合は、registry.redhat.ioサーバーの認証情報を提供する必要があります。podman login registry.redhat.ioコマンドを使用してログインします。認証情報は通常、Red Hat カスタマーポータルで使用されるものと同じです。イメージを実行します。
$ podman run -d -p8080:8080 dotnet-21-runtime-example
検証手順
コンテナーで実行されているアプリケーションを表示します。
$ xdg-open http://127.0.0.1:8080
第3章 OpenShift Container Platform での .NET Core 2.1 の使用
.NET Core イメージストリームは、Linux、Mac または Windows オペレーティングシステムにインストールできます。
3.1. .NET Core 2.1 イメージストリームのインストール
.NET Core イメージストリームの定義は、openshift 名前空間でグローバルに定義することも、特定のプロジェクトでローカルに定義することもできます。
手順
システム管理者であるか、または十分なパーミッションがある場合は、
openshiftプロジェクトに切り替えます。openshiftプロジェクトを使用すると、イメージストリームの定義をグローバルに更新できます。$ oc project openshift
openshiftプロジェクトを使用するパーミッションがない場合は、手順 2 で始まるプロジェクト定義を更新できます。利用可能な .NET Core イメージバージョンの一覧を表示します。
$ oc describe is dotnet -n openshift $ oc describe is dotnet
出力には、インストールされているイメージが表示されます。イメージがインストールされていない場合は、
Error from server (NotFound)メッセージが表示されます。イメージをプルするには、OpenShift では
registry.redhat.io サーバーで認証するための認証情報が必要です。これらの認証情報はシークレットに保存されます。注記OpenShift 3.11 以降では、
openshiftnamespace 用にシークレットが事前設定されています。以下のコマンドを入力してシークレットを一覧表示します。最初の列には、シークレット名が表示されます。
$ oc get secret | grep kubernetes.io/dockerc
シークレットの内容を確認するには、
.dockercfgまたは.dockerconfigjsonデータを Base64 形式からデコードできます。これにより、registry.redhat.io サーバーの認証情報がすでにあるかどうかを確認できます。以下のコマンドを入力してシークレットの.dockercfgセクションを表示します。$ oc get secret <secret-name> -o yaml | grep .dockercfg .dockercfg: eyJyZWdpc3RyeS5yZWRoYXQuaW8iOnsidXNlcm5hbWUiOiIqKioqKioqKiIsInBhc3N3b3JkIjoiKioqKioqKioiLCJlbWFpbCI6InVudXNlZCIsImF1dGgiOiJLaW9xS2lvcUtpbzZLaW9xS2lvcUtpbz0ifX0=
以下のコマンドに出力をコピーして貼り付けて、Base64 形式から変換します。以下の例は、
registry.redhat.ioサーバーの認証情報を示しています。$ echo eyJyZWdpc3RyeS5yZWRoYXQuaW8iOnsidXNlcm5hbWUiOiIqKioqKioqKiIsInBhc3N3b3JkIjoiKioqKioqKioiLCJlbWFpbCI6InVudXNlZCIsImF1dGgiOiJLaW9xS2lvcUtpbzZLaW9xS2lvcUtpbz0ifX0= | base64 -d {"registry.redhat.io":{"username":"","password":"","email":"unused","auth":"KioqKioqKio6KioqKioqKio="}}registry.redhat.ioサーバーの認証情報と共にシークレットが一覧にない場合は、これを追加する必要があります。Red Hat アカウント認証情報は
registry.redhat.io アクセスに使用されます。Red Hat 製品のエンタイトルメントをお持ちのお客様は、使用するアカウントの認証情報をお持ちです。通常、これらは Red Hat カスタマーポータルへのログインに使用されるものと同じ認証情報です。Red Hat の認証情報を確認するには、以下のコマンドを実行してログインを試行します。$ podman login registry.redhat.io
ログインできない場合は、まず Red Hat のアカウントを取得する必要があります。詳細は、「 Red Hat コンテナーレジストリーの認証 」を参照してください。ログインできる場合は、以下のコマンドを実行してシークレットを作成します。
$ oc create secret docker-registry redhat-registry \ --docker-server=registry.redhat.io \ --docker-username=<user-name> \ --docker-password=<password> \ --docker-email=unused $ oc secrets link default redhat-registry --for=pull $ oc secrets link builder redhat-registry新規イメージストリームをインポートします。
$ oc create -f https://raw.githubusercontent.com/redhat-developer/s2i-dotnetcore/master/dotnet_imagestreams.json
イメージストリームがすでにインストールされている場合は、
replaceコマンドを使用してイメージストリームの定義を更新します。$ oc replace -f https://raw.githubusercontent.com/redhat-developer/s2i-dotnetcore/master/dotnet_imagestreams.json
3.2. oc を使用したソースからのアプリケーションのデプロイメント
アプリケーションのデプロイメントに OpenShift クライアント (oc) を使用できます。
以下の例は、oc を使用して example-app アプリケーションをデプロイする方法を示しています。これは、redhat-developer/s2i- ブランチの dotnetcore-ex GitHub リポジトリーの dotnetcore-2.1app フォルダーにあります。
手順
新しい OpenShift プロジェクトを作成します。
$ oc new-project sample-projectASP .NET Core アプリケーションを追加します。
$ oc new-app --name=example-app 'dotnet:2.1~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnetcore-2.1' --build-env DOTNET_STARTUP_PROJECT=appビルドの進捗を追跡します。
$ oc logs -f bc/example-appビルドが完了したら、デプロイされたアプリケーションを表示します。
$ oc logs -f dc/example-appこれで、プロジェクト内でアプリケーションにアクセスできます。
オプション: プロジェクトを外部からアクセス可能にします。
$ oc expose svc/example-app共有可能な URL を取得します。
$ oc get routes
3.3. oc を使用したバイナリーアーティファクトからアプリケーションのデプロイ
.NET Core Source-to-Image (S2I) ビルダーイメージを使用して、提供するバイナリーアーティファクトを使用してアプリケーションをビルドできます。
前提条件
公開済みアプリケーション。
詳細は 「.NET Core 2.1 を使用したアプリケーションの公開」 を参照してください。
手順
新しいバイナリービルドを作成します。
$ oc new-build --name=my-web-app dotnet:2.1 --binary=trueビルドを開始し、ローカルマシンのバイナリーアーティファクトへのパスを指定します。
$ oc start-build my-web-app --from-dir=bin/Release/netcoreapp2.1/publish
新規アプリケーションを作成します。
$ oc new-app my-web-app
3.4. Jenkins スレーブの使用
OpenShift Container Platform Jenkins イメージは、.NET Core 2.1 スレーブイメージの自動検出を提供します(dotnet-21)。
自動検出が機能するには、Jenkins スレーブ ConfigMap yaml ファイルをプロジェクトに追加する必要があります。
手順
Jenkins がデプロイされているプロジェクトに切り替えます。
$ oc project _project-name_
dotnet-jenkins-slave.yamlファイルを作成します。注記<serviceAccount> 要素に使用される値は、Jenkins スレーブによって使用されるアカウントです。値の指定がない場合は、
defaultサービスアカウントが使用されます。kind: ConfigMap apiVersion: v1 metadata: name: dotnet-jenkins-slave-21 labels: role: jenkins-slave data: dotnet21: |- <org.csanchez.jenkins.plugins.kubernetes.PodTemplate> <inheritFrom></inheritFrom> <name>dotnet-21</name> <instanceCap>2147483647</instanceCap> <idleMinutes>0</idleMinutes> <label>dotnet-21</label> <serviceAccount>jenkins</serviceAccount> <nodeSelector></nodeSelector> <volumes/> <containers> <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate> <name>jnlp</name> <image>registry.access.redhat.com/dotnet/dotnet-21-jenkins-slave-rhel7:latest</image> <privileged>false</privileged> <alwaysPullImage>true</alwaysPullImage> <workingDir>/tmp</workingDir> <command></command> <args>${computer.jnlpmac} ${computer.name}</args> <ttyEnabled>false</ttyEnabled> <resourceRequestCpu></resourceRequestCpu> <resourceRequestMemory></resourceRequestMemory> <resourceLimitCpu></resourceLimitCpu> <resourceLimitMemory></resourceLimitMemory> <envVars/> </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate> </containers> <envVars/> <annotations/> <imagePullSecrets/> <nodeProperties/> </org.csanchez.jenkins.plugins.kubernetes.PodTemplate>設定をプロジェクトにインポートします。
$ oc create -f dotnet-jenkins-slave.yaml
スレーブイメージが使用されるようになりました。
例
以下の例は、OpenShift Container Platform に Jenkins パイプラインを追加する方法を示しています。Jenkins パイプラインが追加され、Jenkins マスターが実行されていない場合、OpenShift はマスターを自動的にデプロイします。Jenkins サーバーインスタンスのデプロイおよび設定に関する詳細は、OpenShift Container Platform および Jenkins を参照してください。
この手順例では、BuildConfig yaml ファイルには、dotnet-21 Jenkins スレーブを使用して設定される単純な Jenkins パイプラインが含まれます。サンプル BuildConfig yaml ファイルには 3 つの段階があります。
- ソースがチェックアウトされます。
- アプリケーションが公開されます。
バイナリービルドを使用してイメージがアセンブルされます。
バイナリービルドの詳細については、「
ocを使用したバイナリーアーティファクトからアプリケーションのデプロイ」 を参照してください。
手順
Jenkins マスタースレーブパイプラインを構成するには、以下を行います。
buildconfig.yamlファイルを作成します:kind: BuildConfig apiVersion: v1 metadata: name: dotnetapp-build spec: strategy: type: JenkinsPipeline jenkinsPipelineStrategy: jenkinsfile: |- node("dotnet-21") { stage('clone sources') { sh "git clone https://github.com/redhat-developer/s2i-dotnetcore-ex --branch dotnetcore-2.1 ." } stage('publish') { dir('app') { sh "dotnet publish -c Release /p:MicrosoftNETPlatformLibrary=Microsoft.NETCore.App" } } stage('create image') { dir('app') { sh 'oc new-build --name=dotnetapp dotnet:2.1 --binary=true || true' sh 'oc start-build dotnetapp --from-dir=bin/Release/netcoreapp2.1/publish --follow' } } }BuildConfigファイルを OpenShift にインポートします。$ oc create -f buildconfig.yaml
- OpenShift コンソールを開きます。
Builds → Pipelines に移動します。
dotnetapp-buildパイプラインが利用可能です。Start Pipeline をクリックします。
Jenkins イメージを最初にダウンロードする必要があるため、ビルドを開始するまでに時間がかかる場合があります。
ビルド時に、OpenShift コンソールでさまざまなパイプラインステージが完了したかどうかを確認できます。View Log をクリックし、Jenkins で完了したパイプラインステージを確認することもできます。
Jenkins パイプラインのビルドが完了したら、Builds → Images に移動します。
dotnetappイメージがビルドされ、利用可能です。
3.5. .NET Core 2.1 の環境変数
.NET Core イメージは、.NET Core アプリケーションのビルド動作を制御するいくつかの環境変数に対応しています。これらの変数はビルド設定の一部として設定したり、アプリケーションのソースコードリポジトリーの .s2i/environment ファイルに追加できます。
| 変数名 | 説明 | デフォルト |
|---|---|---|
| DOTNET_STARTUP_PROJECT |
実行するプロジェクトを選択します。これは、プロジェクトファイル ( |
|
| DOTNET_ASSEMBLY_NAME |
実行するアセンブリーを選択します。これには |
|
| DOTNET_RESTORE_SOURCES |
復元操作中に使用される NuGet パッケージソースのスペース区切り一覧を指定します。これにより、 | |
| DOTNET_TOOLS |
アプリをビルドする前にインストールする .NET ツールの一覧を指定します。 | |
| DOTNET_NPM_TOOLS | アプリケーションをビルドする前にインストールする NPM パッケージの一覧を指定します。 | |
| DOTNET_TEST_PROJECTS |
テストするテストプロジェクトの一覧を指定します。これは、プロジェクトファイルまたは、単一のプロジェクトファイルを含むディレクトリーである必要があります。各項目に対して | |
| DOTNET_CONFIGURATION |
Debug モードまたは Release モードでアプリケーションを実行します。この値は、 |
|
| DOTNET_VERBOSITY |
| |
| HTTP_PROXY, HTTPS_PROXY | アプリケーションをビルドおよび実行するときにそれぞれ使用される HTTP または HTTPS プロキシーを構成します。 | |
| DOTNET_RM_SRC |
| |
| DOTNET_SSL_DIRS |
信頼する追加の SSL 証明書を含むディレクトリーまたはファイルの一覧を指定します。証明書は、ビルド中に実行する各プロセスと、ビルド後のイメージで実行するすべてのプロセス (ビルドされたアプリケーションを含む) により信頼されます。項目は、絶対パス ( | |
| NPM_MIRROR | ビルドプロセス中にカスタム NPM レジストリミラーを使用してパッケージをダウンロードします。 | |
| ASPNETCORE_URLS |
この変数は | |
| DOTNET_RESTORE_DISABLE_PARALLEL |
|
|
| DOTNET_INCREMENTAL |
| |
| DOTNET_PACK |
| |
| [OBSOLETE: April 2019] - DOTNET_SDK_VERSION |
ビルド時にデフォルトの sdk バージョンを選択します。ソースリポジトリーに | イメージで利用可能な最小 sdk バージョン |
3.6. .NET Core 2.1 のサンプルアプリケーションの作成
3 つのサンプルアプリケーションが利用できます。
- dotnet-example: これは、デフォルトの model-view-controller(MVC)アプリケーションです。
-
dotnet-runtime-example: これは、チェーンビルドを使用して MVC アプリケーションをビルドする方法を示しています。アプリケーションは
dotnet/dotnet-21-rhel7でビルドされます。結果はubi8/dotnet-21-runtime-rhel7にデプロイされます。チェーンされたビルドは OpenShift Online ではサポートされません。 - dotnet-pgsql-persistent: これは、PostgreSQL バックエンドを使用した Microsoft ASP.NET Core MusicStore サンプルアプリケーションです。
OpenShift Web コンソールを使用してサンプルを追加するには、プロジェクトを参照し、Add to project をクリックします。dotnet のフィルターを設定できます。サンプルが表示されない場合は、以下のコマンドを実行してインストールに追加できます。
$ oc create -f https://raw.githubusercontent.com/redhat-developer/s2i-dotnetcore/master/templates/dotnet-example.json $ oc create -f https://raw.githubusercontent.com/redhat-developer/s2i-dotnetcore/master/templates/dotnet-runtime-example.json $ oc create -f https://raw.githubusercontent.com/redhat-developer/s2i-dotnetcore/master/templates/dotnet-pgsql-persistent.json
第4章 .NET Core の以前のバージョンからの移行
マイクロソフトは、ほとんどの旧バージョンの .NET Core からの移行手順を提供しています。移行時には、以下の ASP.NET Core 2.0 プロパティーが指定されなくなります。.NET Core 2.1 のデフォルト値のままにする必要があります。指定されている場合は、プロジェクトファイルとコマンドラインから必ず削除してください。
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
サポートされなくなった .NET Core のバージョンを使用している場合、または新しいバージョンの .NET Core に移行して機能を拡張する場合は、以下の記事を参照してください。
- .NET Core 2.0 から 2.1 への移行
- ASP.NET Core 2.2 から 3.0 への移行
- ASP.NET Core 2.1 から 2.2 への移行
- への移行
project.json から .csproj 形式への移行
- 注記
- .NET Core 1.x から 2.0 に移行する場合は、「Migrate from ASP.NET Core 1.x to 2.0」の最初のいくつかのセクションを参照してください。これらのセクションでは、.NET Core 1.x から 2.0 への移行パスに適したガイダンスを提供しています。
第5章 .NET Framework から .NET Core 2.1 への移行
以下のセクションを参照して、.NET Framework から移行する方法を説明します。
5.1. 移行に関する考慮事項
.NET Framework に存在するいくつかの技術と API は、.NET Core では使用できません。アプリケーションまたはライブラリーにこれらの API が必要な場合は、代替を見つけることを検討するか、.NET Framework の使用を継続してください。.NET Core は、次の技術と API をサポートしていません。
- Windows Forms や WPF (Windows Presentation Foundation) などのデスクトップアプリケーション
- Windows Communication Foundation (WCF) サーバー (WCF クライアントがサポートされています)
- .NET リモート処理
さらに、多くの .NET API は、Microsoft Windows 環境でのみ使用できます。次の一覧では、この Windows 固有の API の例を示しています。
-
Microsoft.Win32.Registry -
System.AppDomains -
System.Drawing -
System.Security.Principal.Windows
.NET Portability Analyzer を使用して、API の相違点と交換の可能性を特定することを検討してください。たとえば、次のコマンドを入力して、.NET Framework 4.6 アプリケーションで使用される API が .NET Core 2.1 でどの程度サポートされているかを確認します。
$ dotnet /path/to/ApiPort.dll analyze -f . -r html --target '.NET Framework,Version=4.6' --target '.NET Core,Version=2.1'
.NET Core のデフォルトバージョンでサポートされないいくつかの API は、Microsoft.Windows.Compatibility NuGet パッケージで利用できます。この NuGet パッケージを使用するときは注意してください。提供されている API の一部 (Microsoft.Win32.Registry など) は Windows でのみ動作し、アプリケーションが Red Hat Enterprise Linux と互換性がないようにします。
5.2. .NET Framework の移行手順
.NET Framework から移行する場合は、次の Microsoft の記事を参照してください。
- 一般的なガイドラインは、「Porting to .NET Core from .NET Framework」を参照してください。
- ライブラリの移植は、「Porting to .NET Core - Libraries」を参照してください。
- ASP.NET Core への移行は、「Migrating to ASP.NET Core」を参照してください。
付録A 改訂履歴
| 日付 | バージョン | 作成者 | 変更 |
|---|---|---|---|
| 08/21/2017 | 2.0 | Les Williams | 一般公開 |
| 08/30/2017 | 2.0 | Les Williams | セクション 2.3 の DOTNET_STARTUP_PROJECT および DOTNET_TEST_PROJECTS エントリーを修正 |
| 09/13/2017 | 2.0 | Les Williams | セクション 1.2 を修正して rh-dotnet20 を永続的に有効にする方法についての注記を追加 |
| 02/14/2018 | 2.0 | Les Williams | セクション 2.2 から解決 BZ 1500230; zsh およびその他のシェルの引用を追加 |
| 02/28/2018 | 2.0.3 | Les Williams | SDK 2.0 および 2.1 が含まれるように改訂 |
| 06/14/2018 | 2.1 | Les Williams | 一般公開 |
| 08/01/2018 | 2.1 | Toby Drake | 移行手順を提供するために第 3 章を追加 |
| 08/24/2018 | 2.1 | Toby Drake | ユーザーが新規イメージストリームを取得できるようにする手順を追加 |
| 09/18/2018 | 2.1 | Toby Drake |
セクション 2.1 を修正。.NET Core イメージバージョンを一覧表示するコマンドに |
| 10/12/2018 | 2.1 | Toby Drake |
DOTNET_SSL_DIRS および DOTNET_RM_SRC を 「.NET Core 2.1 の環境変数」 に追加。「 |
| 11/08/2018 | 2.1 | Toby Drake |
docker から podman への参照を変更。レジストリーサーバーを |
| 11/27/2018 | 2.1 | Toby Drake | RHEL 8 に対応するための参照を追加 |
| 04/16/2019 | 2.2 | Les Williams | DOTNET_INCREMENTAL および DOTNET_PACK 変数の環境変数セクションを修正 |