Slide 1

Slide 1 text

Kouji Matsui (https://www.kekyo.net/) nuget-server あなたが必要だった NuGet サーバー Kouji Matsui Center CLR No.11 2026/2/28

Slide 2

Slide 2 text

Kouji Matsui (https://www.kekyo.net/) Kouji Matsui ● kekyo, けきょ , kozy_kekyo というクレジットを使うことがあります。 ● 愛知県の付近のモグリで引き籠モラー。 ● 自転車乗りです(最近忙しすぎて乗れてない) ● Center CLR 主催しています。 ● Ubuntu/Debian 使い。バックエンドシステム・言語処理系とそのツール チェイン・ライブラリインターフェイス設計、などが主戦場 / 興味の中心。 ● 赤い色は、某 WP 1520 由来。 今ではマイカラー。燃える赤 🔥

Slide 3

Slide 3 text

Kouji Matsui (https://www.kekyo.net/) Agenda ● なんで作ったか ● 特徴 ● デモ ● 内部構造 ● 反響

Slide 4

Slide 4 text

Kouji Matsui (https://www.kekyo.net/) NuGet って ? ● .NET のライブラリパッケージの名称 ● .NET 以外のファイルの配布も一応可能(極めてマイナー。忘れていい) ● 拡張子 *.nupkg 及び *.snupkg (え?) ● ローカルディレクトリからインポートも不可能ではないけど、基本的には 「 NuGet サーバー」から参照して取得する ● .NET CLI, Rider, Visual Studio などから参照できる

Slide 5

Slide 5 text

Kouji Matsui (https://www.kekyo.net/) nuget.org ● NuGet 公式の公開サーバー。 ● .NET の標準パッケージリポジトリ。誰でも使用できる。 ● 基本的に OSS パッケージの公開を行うところ(実は他人に見えて良いなら OSS でなくても良い、はず) ● 取り扱いに神経使う(失敗したらとか)

Slide 6

Slide 6 text

Kouji Matsui (https://www.kekyo.net/) プライベート NuGet サーバー ● BaGet (https://loic-sharma.github.io/BaGet/) ● ぐぐるの中の人。 ● 割と歴史は古い。昔試したことがあるけどその時は運用までやらなかっ た。 ● 最近はあまりメンテナンスされてなくて、 亜種が出たりしている。

Slide 7

Slide 7 text

Kouji Matsui (https://www.kekyo.net/) プライベート NuGet サーバー ● NuGet.Server (https://www.nuget.org/packages/NuGet.Server) ● 公式の実装らしいけど、全くメンテナンスされていない。 ● NuGet.Server を nuget.org から取得しろって、意味がわからなかったけ ど、どうやらこれを使って、自分でサーバー を実装しろ(略 ● .NET Framework なのでお察し ● これを改良した実装も、もしかしたら あるのかもしれないけど、探索する気が。

Slide 8

Slide 8 text

Kouji Matsui (https://www.kekyo.net/) プライベート NuGet サーバー ● Nexus3 (https://www.sonatype.com/products/sonatype-nexus-repository) ● 売り物だけど、フリー利用モードもあり。 ● 大変高機能で、 NuGet 以外のパッケージリポジトリも同時にサポートでき る。特に maven (Java) は数少ない認められたサーバーらしく、あまり選択 肢がないことから、非常に良く使用されている(らしい) ● これをまあまあ長い期間運用していた (現在も NuGet 以外で使用中)

Slide 9

Slide 9 text

Kouji Matsui (https://www.kekyo.net/) クラウドベース NuGet サーバー ● MyGet (https://www.myget.org/) ● これも歴史が古く、 GitHub と Azure がやり始めるまでは、クラウドベー スでほぼ独占していた。 ● OSS プロジェクトで無償利用できていたが、 Azure が提供し始めた頃か ら ... ● それから殆ど見てなかったので 現在はどうなのかは不明だけど、 トップページは垢抜けた感じになってた。

Slide 10

Slide 10 text

Kouji Matsui (https://www.kekyo.net/) クラウドベース NuGet サーバー ● GitHub package registry (https://docs.github.com/en/packages/working-with-a-github-packages-registry ) ● よく知られたパッケージレジストリ。無償枠もある(容量制限あり)。 ● 管理画面は一切存在しない。大事なことなのでもう一度 : 管理画面は一切存在しない。 CLI でどうぞ。 ● ちな GitLab はパッケージ一覧は 見れます。

Slide 11

Slide 11 text

Kouji Matsui (https://www.kekyo.net/) クラウドベース NuGet サーバー ● ほか、 ProGet, TeamCity, Gitea などあるようです。 ● どれもこれもめんどくさそう ... (失礼)

Slide 12

Slide 12 text

Kouji Matsui (https://www.kekyo.net/) 困ったこと ● OSS 開発とお仕事で非公開のパッケージの取り扱いを行う必要が あって、どうやってホストするかが問題だった。 – OSS 開発 : 実験的プロジェクトのパッケージを nuget.org に登録 するのは流石に気が引ける。 – お仕事のパッケージは当然公開できないので、見えないところで パッケージを配布できなければならない。

Slide 13

Slide 13 text

Kouji Matsui (https://www.kekyo.net/) 困ったこと ● クラウドベースだとカネがかかる。 – 当初は MyGet を使いたかったが、予算の折り合いがつかなかっ た(この時点で結構な量あった) ● クラウドベースではない場合、 NuGet サーバーを立ち上げること自 体に割と負担がある。 – ローカルサーバー費用(まあこれはなんとかできる) – 運用保守作業(普段からやってないと、いざという時にすっかり 忘れてる問題)

Slide 14

Slide 14 text

Kouji Matsui (https://www.kekyo.net/) 困ったこと ● 再び BaGet を試したがうまく動かなかったので、 Nexus3 を使用し た。問題なく起動したが、管理コストがキツイ ... – オーバースペック(細かいユーザー管理・権限設定・パッケージ プロキシ・煩雑な UI ) – データベース管理(バックアップ・更新マイグレーション作業)

Slide 15

Slide 15 text

Kouji Matsui (https://www.kekyo.net/) 困ったこと ● 軽く調査すると、現在( 2025 年)において、特に定番の NuGet サーバー実装が存在しなさそうだと言うことがわかった ... ● これは ...

Slide 16

Slide 16 text

Kouji Matsui (https://www.kekyo.net/) 作るチャンスでは? ● つまり、こういうやつだ : – ローカルでサクッと起動できる – データベースを一切使わない。ファイル管理だけで実現する – パッケージの一覧ぐらいは見れる – ユーザーの管理が(出来れば)ベター ● 下手に高機能にしないで、細かいこと言わず、ゴールを絞り込めば、 十分射程にある気がする。 UI がめんどくさそう?

Slide 17

Slide 17 text

Kouji Matsui (https://www.kekyo.net/) 作るチャンスでは? ● 特に、お仕事方面で、マジでライブラリ管理がヤヴァイ方向に流れそ うだったので、今のうちに何とかしないと、後で火の粉が降り掛かっ てきそうだった、と言う闇があって ?「 DLL (アセンブリ)ファイルを手でコピーしてだな ... 」 ぼく「(今 2020 年台っすよ ... )」 ● Nexus3 のあるバージョンでデータベースマイグレーションに失敗し て、壊れなかったけどそこからバージョンを上げられなくなってし まって詰んだ ...

Slide 18

Slide 18 text

Kouji Matsui (https://www.kekyo.net/) Agenda ● なんで作ったか ● 特徴 ● デモ ● 内部構造 ● 反響

Slide 19

Slide 19 text

Kouji Matsui (https://www.kekyo.net/) 特徴 ● ベタな名前で “ nuget-server” (まだパッケージが無いぞ。しめしめ ... ) ● TypeScript (Node.js) で作る ● NuGet V3 API にのみ準拠( V2 API はサポートしない) ● 管理画面は React+React MUI で実装。イケてる感じにしたい。 ● パッケージは単純なディレクトリ構造で管理。データベースは絶対に 使わない( SQLite も不可)。だからスケールアウトとか不要。 ● ユーザー管理によるアクセス制限は実装。 Basic 認証・ API キー ● Docker イメージを作ってコンテナ運用も可能にする

Slide 20

Slide 20 text

Kouji Matsui (https://www.kekyo.net/) 特徴 ● TypeScript (Node.js) で作ること – 技術面 :NuGet サーバーは、 .NET アセンブリの読み取りを行う 必要はない。 nuspec ファイル (XML) を読めれば良いの で、 .NET で作る必要性はない。 – しかし、最大の理由は 2013 年ごろの経験まで遡る ...

Slide 21

Slide 21 text

Kouji Matsui (https://www.kekyo.net/) 特徴 ● その頃、 ASP.NET (net4.0) の有償セミナー講師をやってた。 ● すでに ASP.NET では、 WebForms と MVC と Razor が JavaScript エコシステムと整合出来なくて酷いことが静かに進 行していた。どうやってこれをスムーズに学習して貰うかに腐 心していた ... ● 覚えているだろうか。この頃ウェブサーバーを起動すると言え ば、 IIS か IIS Express を構成するという、非常にしんどい作業 が待っていた。

Slide 22

Slide 22 text

Kouji Matsui (https://www.kekyo.net/) 特徴 ● この時、初めて NPM を触ったわけだが ... ● スクショが現在のターミナルで 申し訳ないが、 おわかりいただけたであろうか $ npm i -g http-server $ http-server -p 1234

Slide 23

Slide 23 text

Kouji Matsui (https://www.kekyo.net/) 特徴 ● この時の私の気持ちを 40 字以内で述べよ。 ● 正確なことを言えば、 Windows+.NET Framework の話なの で、今は多少改善されているけど、現代でもこの「ポータビリ ティ」は覆せていない。 ● 目的を達成できるなら、手段はシンプルな方が良い。 この時、逆らい難いこの現実が、私のマインドの奥深くに刻み 込まれた。 何なら、 npx 使えば 1 ライナーですよ ...

Slide 24

Slide 24 text

Kouji Matsui (https://www.kekyo.net/) 特徴 ● 有言実行 $ npm i -g nuget-server $ nuget-server -p 1234 本当にこれだけです。 Node.js がインストールされていれば、 ゼロコンフィグで起動します! あなたの端末でも動くはず!

Slide 25

Slide 25 text

Kouji Matsui (https://www.kekyo.net/) 特徴 念の為、素の Win11 に Node.js インストールして試しました :

Slide 26

Slide 26 text

Kouji Matsui (https://www.kekyo.net/) 特徴 ● `nuget-server` だけで起動可能。 – 最小構成で良ければゼロコンフィグ – 匿名アクセス – デフォルトポート番号 (5963) – もちろんパッケージファイルは そのままディレクトリに格納 – データベースファイルなし – 事前要求は Node.js のみ ( バージョン 20.18.0 以上)

Slide 27

Slide 27 text

Kouji Matsui (https://www.kekyo.net/) Agenda ● なんで作ったか ● 特徴 ● デモ ● 内部構造

Slide 28

Slide 28 text

Kouji Matsui (https://www.kekyo.net/) デモ ● ようこそ nuget-server へ!デモやります。 ● GitHub: https://github.com/kekyo/nuget-server/

Slide 29

Slide 29 text

Kouji Matsui (https://www.kekyo.net/) デモ ● NuGet ソースの登録、毎回ムカつかないですか? 私はムカつきます。 だから一発コピーを付けました。 常に表示されてます。 環境行ったり来たり勢も安心。

Slide 30

Slide 30 text

Kouji Matsui (https://www.kekyo.net/) デモ ● 手動バルクアップロード可能 ● ドラッグアンドドロップ出来る ディレクトリにパッ ケージが保存される これをバックアップす るだけ!

Slide 31

Slide 31 text

Kouji Matsui (https://www.kekyo.net/) デモ ● パッケージ一覧 – 最低限必要な情報は網羅 – パッケージ毎に 全てのバージョンを 手動ダウンロード可能 ● フィルタ出来る

Slide 32

Slide 32 text

Kouji Matsui (https://www.kekyo.net/) デモ ● 認証機能(これで十分) モード パッケージ読み取り パッケージ登録 備考 `none` 匿名可能 匿名可能 完全匿名モード。個人運用向け。 殆ど管理の手間いらず。 `publish` 匿名可能 認証必要 標準的なプライベート運用、ある いは限定された組織運用(公開あ り)。 `full` 認証必要 認証必要 必ずログインが必要。

Slide 33

Slide 33 text

Kouji Matsui (https://www.kekyo.net/) デモ ● 認証の初期化(一回のみ) $ nuget-server --auth-init 管理者のユーザー名とパス ワードだけ入力する。 ● 追加ユーザーの管理は UI で 行える。

Slide 34

Slide 34 text

Kouji Matsui (https://www.kekyo.net/) デモ ● 認証モードを変更するため、 config.json に `authMode` を定義する。 ● nuget-server を再起動する。 全体的な配置。 何度も言うけどデータ ベースは無い。 ファイルとしてこれだけ

Slide 35

Slide 35 text

Kouji Matsui (https://www.kekyo.net/) デモ ● publish の場合は、右上アイコンクリックで、ログインメニューが表示される。 ● full の場合は、最初からログイン画面が表示される

Slide 36

Slide 36 text

Kouji Matsui (https://www.kekyo.net/) その他の機能 ● API パスワード発行・管理機能 ● ユーザー登録・管理機能 ● 別の NuGet サーバーからのパッケージインポート機能 ( 既存のサーバーの移行 ) ● リバースプロキシサポート ( エンドポイントの公開 ) ● Docker イメージで実行 詳しくはリポジトリのドキュメントを参照

Slide 37

Slide 37 text

Kouji Matsui (https://www.kekyo.net/) Agenda ● なんで作ったか ● 特徴 ● デモ ● 内部構造 ● 反響

Slide 38

Slide 38 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● TypeScript – prettier-max, screw-up, dayjs, adm-zip, xml2js ● ブラウザサイド – React (UI フレームワーク ) – React MUI, react-infinite-scroll, notistack, typed-message ● サーバーランタイム : Node.js 20.18.0+ – Fastify (Node.js ウェブサーバーライブラリ ) – Passport (Fastify 向け認証処理ライブラリ ) – commander, zxcvbn

Slide 39

Slide 39 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 パッケージ 内容 prettier-max Prettier を自動適用可能にする Vite プラグイン screw-up ビルドやパッケージに Git タグのバージョンを自動適用する Vite プラグイン dayjs 有名な日時操作ライブラリ adm-zip zip ファイル操作ライブラリ( NuGet が zip 形式なので) xml2js XML 読み取り (nuspec)

Slide 40

Slide 40 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 パッケージ 内容 React React React MUI React で Modern UI を簡単に実装できる ( ナビバー・メニュー・アコーディオン・サイドパネル・プログレ スバー・ボタンなど ) react-infinite-scroll React で無限スクロールを実装できる notistack React で通知表示 ( 操作完了結果など ) typed-message メッセージ多国語化 ( 型付きシンボル )

Slide 41

Slide 41 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 パッケージ 内容 Fastify Node.js ウェブサーバー ( 軽量・高速・拡張性 ) 内部構造は割とすっぴんの ASP.NET Core に似てる Passport Fastify で認証ハンドリングを行うことが出来る (Basic 認証・ OAuth2 ・ OpenID など。 Node.js 20.18.0+ が必要 ) zxcvbn パスワード強度チェックライブラリ commander Node.js コマンドラインパーサー

Slide 42

Slide 42 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● TypeScript(JavaScript) でウェブサーバーと言えば、 http-server でも使われている express が有名。 ● 当初はこれを使おうとしていたけど、 TS 全般の事情にまだ疎かった 事もあり(今でも)、認証周りの問題を解決出来なかったの で、 Fastify に移行した。 ● Fastify で Passport を使う場合に、 Node.js のバージョンが 20.18.0 以上を要求されるので、これが下限となった。

Slide 43

Slide 43 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● Fastify は、ルーティング処理とハンドラでリクエストをさばける点 で ASP.NET Core の生の操作と似ている。 ● ミドルウェアとしてパイプラインを挟むのと同じような、プラグイン アーキテクチャ構成を取ることが出来る(構造は異なる)。但し今回 は使っていない(そこまで規模が大きくない)。 ● JSON Schema でのバリデーションが売りらしいけど、今回は使って いない(対象が NuGet V3 プロトコルの一部だけなので)。

Slide 44

Slide 44 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● UI セッションと NuGet V3 API で、認証周りのハンドリングは異な る : – UI セッションは、セッション維持による認証検査( @fastify/ secure-session, @fastify/passport )。ログイン画面を必要とす る。 – NuGet V3 API は純粋な API アクセスなので、 API パスワードによ る「 Basic 認証」(えっ?と思った人は沼に浸かった人)

Slide 45

Slide 45 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● NuGet V3 API の闇 (1): – パッケージアップロード時に、 Content-Type: multipart/form-data を 必要とする。 – 仕様自体は問題ないが、 MFD を正しく通せないゲートウェイがある ( Cloudflare tunnel で発生。非常に悩んだ ... ) – どうやら、 *.nupkg と *.snupkg (シンボルパッケージ)を同時にアッ プロードできることを趣旨にしようとしていたようだが、仕様自体未完 だし、もはや ... – V2 API は application/octet-stream だったらしい。

Slide 46

Slide 46 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● NuGet V3 API の闇 (1): – 雰囲気的に MFD は鬼門と思えたので、 nuget-server でパッケージ をアップロードする場合は素直に application/octet-stream で送信 させることにした( V3 未準拠・ V2 を踏襲したわけではない) – 表面的には、 dotnet nuget push コマンドが使えない。 代わりに curl 使ってね(簡単に送信出来て、むしろ便利)

Slide 47

Slide 47 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● NuGet V3 API の闇 (1): – NuGet V3 API で dotnet nuget push を実現する場合、 API キーは独自 の HTTP リクエストヘッダ `X-NuGet-ApiKey` を使用する必要がある (何でだよ) – しかし、もはや application/octet-stream で送信すると決めたので、普 通に Basic 認証でやればいい :

Slide 48

Slide 48 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● NuGet V3 API の闇 (1): – 個人開発者や小規模チームは nuget-server を UI で使用するだろ う : パッケージのアップロードも基本的に UI から行うだろうか ら、ここは手厚くモダン UI で便利にする。 – 一方で、 CI からパッケージを自動登録する場合も、 donet nuget push が使用できないことの制約は無い。 CI スクリプトで curl 使うだけだし、パスワードは CI 変数として注入されるのだか ら、条件はイーブンのはずだ。 熟考したこと

Slide 49

Slide 49 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● NuGet V3 API の闇 (1): – .NET 使用者にとっては、小さいが学習コストとなる。が、私でも dotnet nuget コマンド使用するときはいちいち調べてる(殆ど使 わないし面倒に感じてるし覚える気がない)ので、やはりイーブ ンだ。 熟考したこと

Slide 50

Slide 50 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● NuGet V3 API の闇 (2): – パッケージ ID のリストを取得する API で、仕様上は、存在しな いパッケージ ID を要求された場合に 404 を返すことになってい るが、これをやるとクライアントが正しくパッケージを取得でき ない事がある。 – クライアントがマルチパッケージソースを構成している場合(普 通 nuget.org+ プライベート n 箇所と思われる)に、どれかの サーバーが 404 を返すと、そこで取得を諦める(何でだよ)

Slide 51

Slide 51 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● NuGet V3 API の闇 (2): – ものすごい重箱の角を突くような条件の場合を考慮してこうなっ ているらしい(めちゃくちゃ悩んだ 2 回目なのでもうスルー) – nuget-server では、 404 の代わりに「空のリスト」を返すこと で、クライアントが取得を諦めないようにした。従って、厳密に は V3 API 準拠違反。嫌なら config.json で回避できるようにして おいた。 – なおこのハックは Nexus3 でも使われているらしい ... (仕様とは

Slide 52

Slide 52 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● NuGet V3 API の闇 (3): – これは V3 API というより Visual Studio が悪いのだが ... – NuGet V3 API は最初にサービスインデックスという、サポートして いる V3 API と URL エンドポイントのリストを返すのだが、 VS はこ の URL を見てない(えぇ)。もしかするとこのインデックスすら見 てない ... – それで、 VS は固定の URL パスを使用してブラインドアクセスして いる(らしい) – dotnet CLI や Rider は問題ない ...

Slide 53

Slide 53 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● NuGet V3 API の闇 (3): – もう VS 使ってないからよくわからんけど、 nuget.org が返すイ ンデックスの構造にわかる範囲で合わせておいた。 – 本来は、もっと柔軟にパスを決定できるはずだが、サービスイン デックスで全ての仕様を決定出来るわけではないので、これで本 当にあってるのか不明 ...

Slide 54

Slide 54 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● Docker イメージ (https://hub.docker.com/r/kekyo/nuget-server/tags) – amd64/arm64 それぞれでイメージを提供 (RPi とか ARM 系で動かせる ところを狙った ) – ビルドは podman で行う。ホストは amd64 で、 arm64 はクロスビル ドする。 Radxa ROCK 5B(arm64/aarch64):

Slide 55

Slide 55 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● クロスビルドの事前準備は、 binfmt_misc ドライバ , qemu コンテナ – sudo modprobe binfmt_misc – sudo podman run --rm --privileged docker.io/multiarch/qemu-user- static --reset -p yes ● コンテナのクロス環境は、上記の準備で内部で自動的に qemu を使用して ターゲット環境を用意するので、まるでそのアーキテクチャで実行している かのようにコンテナを実行できる(便利だ ... もちろん遅い)。

Slide 56

Slide 56 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● 準備出来れば、 --platform で指定するだけ。 ● ホスト実行 podman run --rm -it --platform linux/amd64 docker.io/library/alpine:latest ● クロス実行 podman run --rm -it --platform linux/arm64 docker.io/library/alpine:latest ● もちろん、ターゲットイメージがそのプラットフォームイメージを含ん でいる必要がある。

Slide 57

Slide 57 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● Docker alpine イメージはサイズが小さくて良いが、 C ランタイムライブラ リが glibc ではなく musl 。 – すると、 glibc 前提でコンパイルされているネイティブライブラリが ロードに失敗する場合がある。 – ネイティブライブラリなら Node.js と関係ないと思うかもしれないが ... @fastify/secure-session --> sodium-native(libsodium) --> glibc ● A modern, portable, easy to use crypto library: https://github.com/jedisct1/libsodium – .NET で言うところのネイティブ DLL 同梱パッケージみたいな。

Slide 58

Slide 58 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● なので、 Docker イメージビルド時に、 sodium-native を alpine 環 境でソースコードからビルドして生成している。 更に、 sodium-native 5.x 系は別の問題があるようなので、 4.3.3 (最終)に固定。 ● nuget-server ではこの経路以外の問題のある glibc 依存はなさそう。 他のプロジェクトで alpine 使う場合は注意が必要(保守が面倒くさ くなったら alpine やめて debian 化すると思う)

Slide 59

Slide 59 text

Kouji Matsui (https://www.kekyo.net/) 内部構造 ● マルチ対応イメージをデプロイするには、「マニフェスト」を作る必要が ある podman build --platform linux/amd64,linux/arm64 --manifest nuget- server:1.0.0 ... ● 確認 podman manifest inspect nuget-server:1.0.0 ● push podman manifest push --all nuget-server:1.0.0 docker.io/kekyo/nuget- server:1.0.0

Slide 60

Slide 60 text

Kouji Matsui (https://www.kekyo.net/) Agenda ● なんで作ったか ● 特徴 ● デモ ● 内部構造 ● 反響

Slide 61

Slide 61 text

Kouji Matsui (https://www.kekyo.net/) 反響 ● 某所に垂れ流したら、案の定「何で .NET で実装しないんだ」とかあれやこれ や ... – .NET で書いたら(つまり ASP.NET Core と Blazor って事ですか?)、 1 ヶ 月で実装出来ない自信があります。特に UI 周り。そもそも、想定していた ポータビリティが実現できない。 – このプロジェクト自体、最初に説明したように、きっかけは後向きだったの で、あまり手間を掛けたくなかったという背景があります。結果的には、細 かいところを拘ったので、かなりのボリュームにはなりましたが ... (このことをフォローしてくれている人も居たので、心的ダメージは少な かったけど、正直もういいやって思った)

Slide 62

Slide 62 text

Kouji Matsui (https://www.kekyo.net/) 反響 – 指摘の一つに、 .NET で実装しないとメタデータを拾えない、みたいなのが あったけど、それは .NET アセンブリのメタデータを取得できないという話。だ けど、 nuget-server にそれ必要? NuGet Package Explorer のようなものを実装したいなら、 .NET アセンブリを 読み取る能力が必要だけど、 nupkg は zip だし、 nuspec に XML で必要な情報 が書かれているので、パッケージを配信するだけなら .NET でやる必要性は全く 無いです(専門外だけど Go でも Py でも Ruby でも出来ると思う)。 – 全般的に、 .NET で書かなかったのは前向きな選択の結果で、そのことによる問 題は全く発生しませんでした。割とまとまった開発事例になったので、ご自身の プロジェクトでの選択の参考にしてもらえれば嬉しいです。

Slide 63

Slide 63 text

Kouji Matsui (https://www.kekyo.net/) 反響 ● ホラー(嬉しかった)

Slide 64

Slide 64 text

Kouji Matsui (https://www.kekyo.net/) 質疑応答 ● nuget-server 、真のポータビリティを実現できたと思ってます。便利 なので使ってくれたら嬉しいです。 ● 自分で NuGet サーバーを実装しよう、とは思わないほうがいいです (もしやるなら、もっとクールなやつを)

Slide 65

Slide 65 text

Kouji Matsui (https://www.kekyo.net/) ● 真の理由 ● んなわけねーだろ ... さすが量産型 AI ブログ