2018年8月10日

ReactでCSVファイルを読み込んでクライアント側で帳票を出力する

やりたかった事


あるWebサービスからCSV形式でデータをエクスポート出来るのですが、そのデータからちょっとした帳票を印刷したいという要望がありました。

そこでなるべく手っ取り早く、ブラウザだけで動くものが出来ないかと考えて作ってみたのが今回のプログラムです。

大まかな流れは、
  1. ローカルフォルダにあるCSVファイルを指定するとブラウザ上のJavaScriptでその内容を読み込む。
  2. 読み込んだ内容からHTMLで帳票を生成して表示する。
  3. ブラウザの印刷機能を使って手動で印刷またはPDFとして保存する。
という感じになります。


CSVファイルの例







作成したい帳票


実際に動いているもの

https://mikehibm.github.io/react-csv-example/




1. プロジェクトを作成する


プロジェクトは前回のエントリーと同様に Create React App + TypeScriptで作ることにします。
npm install -g create-react-app
create-react-app my-app --scripts-version=react-scripts-ts
cd my-app/
npm start

FileSelect.tsx と Report.tsx というファイルを新規作成して、App.tsx からこれらを呼び出して使うようにします。

最初は FileSelect コンポーネントを表示してCSVファイルの選択を行い、ボタンがクリックされたらファイルの内容を読み取って、Report コンポーネントに渡します。




Report コンポーネントが表示されている時は FileSelect コンポーネントは非表示になるようにします。




2. JavaScriptでCSVファイルの内容を読み込む


HTML5のFile APIを使います。FileReaderでの読み込みは非同期処理なので、処理をラップしてPromiseを返す関数を作りました。







3. ファイルの内容をパースしてオブジェクトの配列に変換する


上の readFileAsText() からファイル全体の内容が文字列として返ってくるので、それをパースしてオブジェクトの配列に変換します。

具体的には、まず改行文字で区切って行単位の配列に分け、さらにその各行について「,」で区切って列単位の配列に分けます。つまり最終的には string[][] (文字列の配列の配列)になります。




ここでは簡単に改行文字(\n)と「,」で区切っているだけですが、実際には改行文字が違う、値に「,」が含まれている、などさまざまなケースがあり得るのでCSVのパース処理はちゃんとやろうとすると実は結構大変です。

なので必要であれば下の記事で紹介されている csv-parser などを使った方が良いかもしれません。

ブラウザ上でCSVファイルをパースする
https://qiita.com/ledsun/items/e38ee0dff8f26bf8d930




その後、文字列の配列(の配列)から、今度は帳票を生成する時に扱いやすいように、WorkItemというクラスのインスタンスの配列に変換します。

この時に、文字列型から日付型への変換や、CSVファイルに無い項目の値(duration)の計算なども同時に行っています。





4. HTMLで帳票を生成する


WorkItemオブジェクトの配列を受け取って、tableタグで表形式のHTMLに変換します。

本当は帳票のタイトル、見出し、明細行などをそれぞれ別のコンポーネントに分けた方が良いのだと思いますが、今回はあまり時間がなかったので1コンポーネントで作ってしまいました。





あとは画面に表示された帳票をブラウザの印刷機能で印刷するだけです。デフォルトではおそらく余計なヘッダーやフッター(ページタイトルやURL)も印刷されてしまいますが、印刷時の設定画面でこれらをオフにしておけばきれいに出力されるはずです。


今回作ったアプリの全ソースコードは下記にあります。

https://github.com/mikehibm/react-csv-example







2018年8月8日

Create React App + TypeScript で最初につまずいたこと

ちょっとしたサンプルプログラム的なものを Create React App + TypeScript で作ろうと思ったのですが、思わぬところでいきなり詰まってしまいました。


Create React App(以下CRA)で TypeScript と言えば、

https://github.com/wmonk/create-react-app-typescript

が定番だと思います。


さて、下の通りにプロジェクトを作成して実行しました。

npm install -g create-react-app
create-react-app my-app --scripts-version=react-scripts-ts
cd my-app/
npm start


もちろんここまでは全く問題なし。早速VS Codeでプロジェクトのフォルダを開いて、アプリケーションを作り始めました。



ところが、あるタイミングでふと

console.log("hogehoge");

を入れて実行してみようと思ったところ、いきなりコンパイルエラーになってしまいました。


「Calls to 'console.log' are not allowed.」というエラーですが、これにはちょっと驚かされました。console.logを入れただけでアプリケーションが動かなくなるなんて。。。


これですが、デフォルトで設定されているTSLintのルールがめちゃくちゃ厳格なものになっているのが原因なようです。


厳格すぎてこれでは使いづらいという声も多く、GitHubのIssuesでも議論になっているようですね。


オリジナルのCRA作者のDan Abramov氏からも、「この厳しいルールはCRAを作った時の思想(初心者でもすぐに動くものを作り始められる。本当にクリティカルなもの以外はワーニングのみでエラーにはしない。)と合わないから、ゆるくした方が良いんじゃない?」 という趣旨のIssueをわざわざ上げられているぐらいです。


create-react-app-typescript リポジトリ作者のWill Monk氏によると、「最初は自分が職場で使っているルールをコピーして使っていたのだけれど、後で一般的に推奨されているプリセット("tslint:recommended", "tslint-react"など)を使うように変更した」との事。「それでもまだルールが厳しすぎるなら、誰かがオリジナルのCRAと同等のゆるいルールの設定を作ってPRしてくれたら喜んでそれをマージするよ。」とも言っているので、彼自身は特にどうしても厳しいルールを他の人に強制する気は無いようです。


その後このIssue上で議論は進んでいるようですが、このブログ執筆時点の最新版ではまだルールの変更には至っていないようです。


さて、なにはともあれとりあえず console.log を使えるようにする方法ですが、上のIssueでも言及されているのですが、Microsoftによる下記のページにわかりやすくはっきりと記載されていました。

https://github.com/Microsoft/TypeScript-React-Starter


プロジェクトのルートフォルダにある tslint.json ファイルを下のように書き換えればOKです。(赤字を削除、青字を追加。)

{
-  "extends": ["tslint:recommended", "tslint-react", "tslint-config-prettier"],
+  "extends": [],
+  "defaultSeverity": "warning",

"linterOptions": {
     "exclude": [
       "config/**/*.js",
       "node_modules/**/*.ts"
     ]
   }
 }

これで問題なく開発が続けられるようになりました!






 

2018年5月6日

Dockerコンテナ内でASP.NET Core 2.1 Webアプリをビルド・実行する

やりたかった事:


Macに.Net SDKを入れずにASP.NET Core 2.1のWebアプリを開発したい。


試した事:


Docker(Version 18.03.1-ce-mac64)でMS公式の.NET 2.1 SDKイメージを動かしてみました。

まずは、SDKの公式イメージからコンテナを起動します。
docker run --rm -it \
  -v `pwd`:/app/ \
  -w /app/aspnetapp \
  microsoft/dotnet:2.1-sdk
これを実行すると、Mac側のカレントディレクトリがコンテナの/app/ディレクトリにマウントされて、かつコンテナ内のカレントディレクトリが/app/aspnetapp になった状態でシェルが起動します。

ここから、
dotnet new webapi 
を実行すればWeb APIのひな形のコードが生成されます。


さらに、
dotnet run
を実行すればデフォルトの5000番ポートでWeb APIが実行されますが、このままだとポートマッピングの設定をしていないのでホスト側からはアクセス出来ません。



とりあえずこれはCtrl+Cで終了してコンテナを終了し、次にdocker runコマンドに -p オプションを付けた上で、シェルを開くのではなく「dotnet watch run」コマンドを実行してみます。

使ったコマンドはこちら。
PORT=8080
docker run --rm -it --name watcher \
  -p $PORT:$PORT \
  -v `pwd`:/app/ \
  -w /app/aspnetapp \
  microsoft/dotnet:2.1-sdk \
  dotnet watch run $PORT
任意のポート番号でアプリを動かせるように、事前にProgram.csファイルにちょっと細工をしておきました。

#########
#########

起動後、指定したポート番号でアプリが動いているのが分かります。




分かった事:


docker runでコンテナを起動する際に -v オプションでカレントディレクトリをコンテナ内のディレクトリにマウントしておけば、ソースコードはホスト(Mac本体)側で編集し、BuildやPublishはコンテナ内で行うという事が出来ました。

コンテナ内で動かすコマンドを「dotnet watch run」としておけばコードを変更したら自動でアプリを再起動してくれます。

これでMac本体に.Net SDKを入れずにASP.NET Core 2.1のWebアプリを開発するという目的が達成出来ました!




参考URL:
dotnet-docker/aspnet-docker-dev-in-container.md at master
https://github.com/dotnet/dotnet-docker/blob/master/samples/aspnetapp/aspnet-docker-dev-in-container.md
MS公式Dockerイメージを使って.NET Core開発を行う(Mac) - ryuichi111stdの技術日記
http://ryuichi111std.hatenablog.com/entry/2016/11/07/020326








.

2018年5月1日

JavaScriptで "B" + ["a", "a"].join("aaa" - 1) がBaNaNaになる理由

Ethereum開発者のVitalik氏がこんなツイートをしていたのを見ました。


試しにChromeのDeveloper Toolsを開いて実行して見ると、確かに「BaNaNa」と表示されました。
"B" + ["a", "a"].join("aaa" - 1)
"BaNaNa"

不思議に思ったので少しずつ変えながら何パターンか試してみます。

"B" + ["a", "a"].join("aaa") → "Baaaaa"
"B" + ["a", "a"].join()  → "Ba,a"
"B" + ["a", "a"].join("")  → "Baa"
"B" + ["a", "a"].join("" - 1)  → "Ba-1a"
"B" + ["a", "a"].join(1)  → "Ba1a"
"B" + ["a", "a"].join("x" - 1)  → "BaNaNa"

なるほど、分かってきました。

"aaa" - 1 の部分が「NaN」として出力されて、それがArray.join()の引数になるので
B + a + NaN + a
で 「BaNaNa」というわけですね。

なるほど!

 

2018年3月1日

TypeScriptを使うならstrictNullChecksオプションが便利

TypeScript の strictNullChecks オプションというものを知ったのでメモしておきます。

tsconfig.json の compilerOptions に

"strictNullChecks": true

を追加しておくと便利。

これをすることで、string や number などに null や undefined を代入することが出来なくなる。

let name: string;
name = null;                ← ここでコンパイルエラー

let count: number;
count = undefined;      ← ここでコンパイルエラー


null や undefined を代入したい場合は、型指定時に明示しておけばOK。

let name: string | null;
name = null;                ← これはOK

let count: number | null | undefined;
count = undefined;      ← これはOK


「ユニオン型」というらしいですね。
http://d.hatena.ne.jp/m-hiyama/20180117/1516157225

色々なシチュエーションで、「この変数の値は null/undefined になる可能性がある(もしくは無い)」という事を明示出来るのでnullチェック忘れや過剰なnullチェックを減らす事が出来ます。




 


2017年11月17日

高解像度のディスプレイでリモートデスクトップ接続をした時にアイコンや文字が小さすぎて見えない問題への対処

Microsoftから提供されている「Remote Desktop Connection Manager」を使うと良い感じになったのでメモしておきます。

ダウンロードページはこちら
https://www.microsoft.com/en-us/download/details.aspx?id=44989



バージョン2.7の日付が2014年11月と古いですが、これ以上新しいバージョンは検索しても見つかりませんでした。


Remote Desktop Connection Managerを起動したら、まず File - New で新しいグループを作ります。




そのグループの右クリックメニューからプロパティを開いて「Remote Desktop Settings」タブを開き、「Full Screen」をチェックします。





次に「Display Settings」タブを開いて、「Scale docked remote desktop to fit window」および「Scale undocked remote desktop to fit window」のチェックをONにしておきます。




あとは、そのグループの下に個々の接続先サーバーの設定を追加して行けばOKです。




これで接続先の解像度が低い場合に文字やアイコンが小さすぎて操作出来ないという問題がなくなります。










 

2017年9月16日

GitLab CIを使ってWebAPIのPDFドキュメント生成を自動化する

前回は Web APIに組み込んだSwaggerが生成する swagger.json ファイルからコマンドラインでPDF形式のドキュメントを生成するところまで出来ました。

今回はこの一連の処理をGitLab CIを使って自動化してみようと思います。

大まかな流れは次のようになります。


  1. GitLabにプロジェクトを作成する
  2. 「.gitlab-ci.yml」ファイルを作成する
  3. GitLabにプッシュしてCIが動作することを確認する
  4. Web APIをAzure App Servicesに自動デプロイする
  5. CIでPDFドキュメントを自動生成する
  6. 生成されたPDFドキュメントをダウンロードする



1. GitLabにプロジェクトを作成する


CIサービスと言えば、Circle CIやTravis CI、Werkerなどたくさんありますが、今回は GitLab CI を使うことにしました。

まだ gitlab.com にアカウントが無い場合はユーザー登録しましょう。
ログイン後、「New Project」ボタンを押して新規プロジェクトを作成します。GitHubに既にプロジェクトがある場合はそちらからそっくりインポートする事も可能です。


2. 「.gitlab-ci.yml」ファイルを作成する

ソリューションの直下に .gitlab-ci.yml と言う名前のファイルを作成します。

Visual Studioを使っている場合はソリューションを右クリックして「追加」をすればSolution Itemsの下に表示されます。


ファイルの内容はとりあえずこんな感じにしておきます。




Dockerのベースイメージとして、Ubuntu 14.04 を使っています。

before_script の部分で apt-get コマンドを使ってJavaとRubyのインストールを行ない、script の部分で動作確認のためにJavaとRubyのバージョンを出力しています。

.gitlab-ci.ymlファイルの仕様は下のページに載っています。
https://docs.gitlab.com/ce/ci/yaml/README.html#gitlab-ci-yml




3. GitLabにプッシュしてCIが動作することを確認する


この状態でGitLabにプッシュして見ます。Pipelinesというメニューをクリックすると自動的にPipelineが作成されている事が分かります。


Jobsというサブメニューを開いて実行されたJobをクリックして詳細を表示すると、黒い画面でコンソール出力の結果を確認する事が出来ます。JavaとRubyのインストールが正常に行われて、最後にバージョン情報が表示されていれば成功です。



リポジトリへのPushを検知してGitLab側で自動的にDockerコンテナを起動して指定のコマンドを実行してくれているわけですね。

Circle CIなど他のサービスを使わずに、しかも無料でこれが出来るというのがGitLabの良い所だと思います。

ちなみに「CI Runner」というものを自前のサーバーにインストールしておけば、Dockerコンテナをそのサーバー上で起動させる様にする事も可能なようです。(むしろ元々は自前で用意するのが基本だったようです。)



4. Web APIをAzure App Servicesに自動デプロイする



Web APIのデプロイ先はAWSやGoogle Cloudなどどこでも構わないのですが、今回はAzure App Servicesを使います。

Azure App Servicesに自動デプロイするにはいくつかの方法がありますが、ここではTravis CIが作成している dpl コマンドを使ってみます。

GitLab CIのジョブでdplコマンドを実行するための設定は次のようになります。



Ubuntu 14.04を起動した後 Rubyをインストールし、さらに gem install dpl で dpl コマンドをインストールしています。

その後、dpl --provider=AzureWebApps で実行します。


ちなみに、
only:
    - /^release-.*$/
の部分は、「release-」で始まるタグ付きでプッシュされた時だけこのジョブが起動されるようにするための設定です。この2行を削除するとプッシュするたびに毎回起動されます。


さて、上の設定ファイルではデプロイ先のURLやデプロイ用の認証情報などを一切指定していません。それらはGitLab内のプロジェクト毎の設定画面に「Secret variables」として登録しておきます。





dplコマンドは

  • AZURE_WA_SITE
  • AZURE_WA_USERNAME
  • AZURE_WA_PASSWORD

の3つの設定を自動的に読み込んで処理してくれます。

この状態で実際にGitLabにプッシュして見るとAzure App ServicesにWeb APIが自動デプロイされます。下はデプロイ成功時のジョブのログを表示したところです。



念のためAzure側のURLを開いてみると確かにWebAPIとSwagger UIが動いています。







5. CIでPDFドキュメントを自動生成する


さて、次はいよいよWeb APIのPDFドキュメントを自動生成します。設定ファイルにpdfというジョブを追加しました。




stages:
  - deploy
  - pdf
となっているので、「deployというステージが終わってからpdfというステージを実行する」という意味になります。ひとつのステージには複数のジョブを含める事が出来ますが、その場合はステージ内の各ジョブが並列実行されます。今回の設定ではそれぞれのステージに同名のジョブを一つずつ含んでいるだけという形になっています。

それぞれのジョブは別個のDockerコンテナとして起動されるので、pdfジョブの方でも再度Rubyのインストールが必要になります。こちらのジョブではJavaのインストールも必要なのでdeployジョブよりも少し時間がかかります。

cd ./MySampleWebApi.Doc && chmod +x *.sh && ./build.sh $SWAGGER_JSON_URL

MySampleWebApi.DocフォルダにあらかじめダウンロードしておいたJavaのコマンド(swagger2markup-cli-1.3.1.jar)やスクリプトを格納してあるので、そのフォルダに移動して build.sh を実行しています。

これで前回に実行したのと同じ一連の処理が動いて ./MySampleWebApi.Doc/pdf フォルダにPDFファイルが作成されます。

この時にSecret Variablesの設定から $SWAGGER_JSON_URL の値を読み込んでスクリプトに渡しています。

こうしておけばAzure側のデプロイ先が変わっても柔軟に対応出来るので便利ですね。



6. 生成されたPDFドキュメントをダウンロードする


最新の成果物へは下の形式のURLでアクセス可能になっています。

https://gitlab.com/(ユーザー名またはグループ名)/(プロジェクト名)/-/jobs/artifacts/master/browse?job=(ジョブ名)

このURLへはGitLabにログインした状態でかつ権限があるユーザーでないとアクセス出来ないので、実運用では .gitlab-ci.yml にさらにジョブを追加してAWSやAzureなどのストレージにアップロードするような処理を追加することになると思います。


あと、この設定のままだとジョブが起動される度に素のUbuntuに対してJavaやRubyのインストールから行っているので、終了するまでにかなり(数分程度)時間がかかってしまいます。

出来ればJava/Rubyが既に入った状態のイメージを探してくるか自分で作成するかして、それをベースイメージに指定した方が良いと思います。



今回作成したサンプルプロジェクトの全ソースコードは下記で参照可能になっています。

https://gitlab.com/mikehibm/AspNetCoreWebApiSwagger







2017年9月8日

SwaggerのAPI定義からPDFドキュメントを生成する

前回はASP.NET CoreのWeb APIプロジェクトにSwaggerを組み込んでAPIのドキュメントをブラウザ上に表示させるところまで実行しました。



これはこれで手軽にAPIの仕様を確認出来て便利なのですが、受託開発の際の納品物としてお客様に渡すには少し不便です。「納品は紙(PDF)で」と言われる事がまだありますよね?

ブラウザに表示されているものを印刷して渡してしまっても良いかもしれませんが、それだと今ひとつ見栄えが良くないので出来ればもう少しきれいなPDF文書を自動生成したいところです。

そこで調べたところ、次のような事が分かりました。

swagger2markup-cli を使えばSwaggerが生成するJSONファイルから静的なHTMLやMarkdown、AsciiDoc形式のドキュメントなどを生成する事が出来る。

asciidoctor-pdf を使えばAsciiDoc形式のドキュメントをPDFファイルに変換する事が出来る。

参考:
goa tips: swagger-ui がサービスできないときのドキュメントどうする問題 - 押してダメならふて寝しろ

asciidocをPDFに変換してみた(asciidoctor-pdf)


今回はこれらを使って
swagger.json → AsciiDoc → PDF
という流れでドキュメントを生成する事にします。


まず前提条件として、swagger2markup-cliを使うにはJavaのインストールが必要で、asciidoctor-pdfを使うにはRubyのインストールが必要になります。

Macで開発しているのあれば通常は両方とも既に入っていると思います。Windowsの場合はchocolateyを使えば簡単にインストール出来ると思います。



1. swagger2markup-cliでAsciiDocファイルを生成する

下のURLからjarファイルをダウンロードします。

https://jcenter.bintray.com/io/github/swagger2markup/swagger2markup-cli/


ダウンロード後、コマンドラインから下記を実行します。

java -jar ./swagger2markup-cli-1.3.1.jar convert -i [swagger.jsonへのパス] -d ./adoc

[swagger.jsonへのパス]の部分は 「http://localhost:49879/swagger/v1/swagger.json」のようにURLを指定しても良いし、「./swagger.json」のようにあらかじめダウンロードしておいたJSONファイルを指定しても構いません。

エラーが出ずに成功すれば、adocフォルダには overview.adoc, paths.adoc, definitions.adoc, security.adoc の4つのファイルが出来ているはずです。ファイルが分かれていると次のステップで困るので、1ファイル(out.adoc)に結合しておきます。

cat adoc/overview.adoc adoc/paths.adoc adoc/definitions.adoc > adoc/out.adoc

(security.adocの内容は特に必要がなかったので除外しました。)




2. asciidoctor-pdfでPDFファイルを生成する

gemコマンドでasciidoctor-pdfをインストールします。

gem install --pre asciidoctor-pdf

あとは入力と出力を指定して実行するだけです。

asciidoctor-pdf -o pdf/out.pdf adoc/out.adoc

これでpdfフォルダにout.pdfファイルが生成されます。サンプルはこんな感じです。


デフォルトのスタイルが物足りなければ、テーマを自作して色々とカスタマイズ出来るようです。
asciidocをPDFに変換してみた(asciidoctor-pdf)


さて、ここまででWeb APIからPDFドキュメントを生成する事が出来ました。ただ、APIに変更が発生する度にコマンドを打ち込んでPDFを再生成するのはちょっと面倒です。

そこで次回は、今流行りの「Continuous Integration(CI)」なるものを使ってソースコードの変更をプッシュするだけで自動的にPDFドキュメントが更新される、という事にチャレンジしてみたいと思います。

次回: GitLab CIを使ってWebAPIのPDFドキュメント生成を自動化する





ASP.NET WebAPIにSwaggerを組み込む



1. ASP.NET Core Web APIを新規作成する


Visual Studio 2017でASP.NET CoreのWeb APIプロジェクトを新規作成します。


デフォルトでControllersフォルダの中にValuesControllerがあるので、この名前をProductsControllerに変更し、さらにUsersControllerを追加します。

新規にResourcesフォルダを作成してその中にProductクラスとUserクラスを作成しておきます。

その後ProductsControllerとUsersControllerを編集してダミーのデータをJSONで返す様にした状態のソースコードが下記になります。(コミットにbefore-swaggerタグが付いています。)

https://github.com/mikehibm/AspNetCoreWebApiSwagger/tree/before-swagger

Ctrl+F5キーで実行すると商品とユーザーの情報がJSONで返って来るのが分かります。


この状態でWeb APIとしては動いているので、次にSwaggerを組み込んでAPIのドキュメント(メタ情報)に外部からアクセス出来るようにしてみます。



2. Swaggerを組み込む


Visual Studio内でPackage Managerコンソールを開いて、次のコマンドを打ち込みます。

Install-Package Swashbuckle.AspNetCore

その後、下のサイトを参考にStartup.csファイルを編集します。と言っても数行を追加するだけなので簡単です。

ASP.NET Web API Help Pages using Swagger


編集後の Startup.cs は下の状態になります。




この状態でCtrl+F5キーを押して実行し、http://localhost:xxxxxxx/swagger/ のURLを開くと、Swagger UIの画面が開いてAPIのドキュメントを閲覧する事が出来るようになっています。



ただこの段階ではせっかくソースコードに書き込んだコメントが反映されていないので、次にそれらが反映されるようにします。



3. XMLコメントをSwaggerに反映させる


まず、プロジェクトの設定で「XMLドキュメントファイル」の自動生成を有効化しておく必要があります。



この状態で一旦プロジェクトをビルドすると、指定したファイル名でXMLファイルが出来るはずです。このファイルをVisual Studioのソリューションエクスプローラ上で右クリックして、「プロジェクトに含める」を選択しておきます。

さらに、XMLファイルを選択した状態でF4キーを押してプロパティウインドウを表示し、下のようにプロパティを変更しておきます。これは後でこのプロジェクトをPublishする際に必要になります。





次に、Startup.csファイルの中で services.AddSwaggerGen() メソッドを呼んでいる箇所があるので、そのブロック内に下の3行を追加します。

var basePath = PlatformServices.Default.Application.ApplicationBasePath;
var xmlPath = Path.Combine(basePath, "MySampleWebApi.xml");
c.IncludeXmlComments(xmlPath);

これで再度実行するとソースコード内でクラス単位やメソッド単位で「///」を使って書いたコメントがSwagger UIの画面にも反映されます。




4. まとめ


ASP.NET CoreのWeb APIプロジェクトにSwaggerを組み込んでAPIのドキュメントを表示させるようにする事は、上の通りかなり手軽に出来ます。

ASP.NET Coreでなく従来のASP.NET MVCのプロジェクトでもほぼ同じ手順でSwaggerの組み込みが可能です。

次回はSwaggerが生成した情報を使ってPDFドキュメントを生成する方法を書いてみたいと思います。