.NETのライブラリをビルドする
リポジトリをクローン
最新の.NET SDKをインストール
先にVSを更新していればいらなかったかも？
Visual Studioを最新版に更新
.NETデスクトップ開発とC++デスクトップ開発のコンポーネントが必要
リポジトリのルートで下記のコマンドを実行
build.cmd -rc Release
ライブラリ単体をビルドする前に、実行環境をビルドする必要がある
このコマンドだとライブラリもすべてビルドされてしまうので、対象を絞った方がいいかも
build.cmd clr+libs -rc Release
これとか？
clrだけでビルドすると、ライブラリがビルドできなかった（フレームワークがビルドされていない旨のエラーが出る）
この構成だとテストが動かないので、テストプロジェクトはアンロードする
ビルド後の容量は13.4GBになった
ビルドした対象のライブラリのslnをVisualStudioで開いてソリューションのビルドを実行
VSで開いたslnが変更される
slnのフォーマットが違う？
たぶん.NET9はVS2022で開く想定ではない
とりあえずslnは除外してコミットする
ここでビルドされたdllのバージョンってリポジトリのバージョンで統一される？
.NETのライブラリのバージョンがどのように決定されるか把握していない…
依存関係について自己完結するならあんまり気にしなくていいか…
.NETのライブラリのバージョンは.、NET本体のバージョンと同じになる
Nugetのバージョンと同じタグをチェックアウトしてビルドすべき
ライブラリのバージョンの1桁目は.NETのバージョンと一致するが、2桁目以降は一致しない
*Asn.xmlが再生成され、ビルドに失敗することがある
gitで差分を確認すると、改行コードの変更のみ
再度ビルドを実行すると成功した
一時ファイルが残っているとビルドに失敗することがある
ローカルのファイルをすべて削除し、チェックアウトし直してからビルドするといい
例
ビルド実行後、ルートのフォルダ名を変更してからビルドすると失敗
一時ファイルに絶対パスが残っていた
git clean -xdfでクリーンできる
ファイルがロックされている場合はスキップされる
アセンブリ名を変更してビルドする手順
ビルドしたいライブラリのslnを開き、refとsrcのプロパティを下記のように編集する
アセンブリ名
任意の名前に変更
パッケージID
プロジェクト名と同じ名前に変更
元々の設定ではアセンブリ名を参照するようになっているが、そのままだとビルドの際にnugetパッケージを復元できず失敗する
なぜビルドの前に自身のnugetパッケージを復元しているかは不明
この状態でソリューションをビルドするとアセンブリ名が変更されている
ライブラリが.NETの他のライブラリを参照している場合、slnにそのライブラリのプロジェクト参照が含まれている
参照先のプロジェクトも同様にアセンブリ名を変更すると、変更後のアセンブリ名で参照先を探索するようになる
アセンブリ名にハイフンを含んでいるとビルドに失敗することがある
名前空間にアセンブリ名を含んだコードが生成されるため
MAはパッケージをハイフン、名前空間をアンダーバーにしている
識別子に使用できない文字をアセンブリ名に含むべきではない？
UPMパッケージの命名規則と.NETライブラリの命名規則のどちらに従うべきか？
asmdefはUPMの形式で、マネージドプラグインは.NETの形式？
"Newtonsoft.Json.dll" を "Unity.Plastic.Newtonsoft.Json.dll" にリネームしている
UnityがPlasticを買収して、Unity Version Controlとなった経緯がある
同梱目的とする場合、パッケージ間の使いまわしは考えない方がいいので、アセンブリ名に同梱先のパッケージを含むのがいいか
アセンブリ名を変更している場合、.NET9や.NET8のビルドが失敗することがある
ひとまず、今回は使用しないので、.NET9や.NET8を外す
Unsafeはsrc/libraries/shims以下にあり、他のライブラリと同様にビルドできない
The libraries build has two logical components, the native build which produces the "shims" (which provide a stable interface between the OS and managed code) and the managed build which produces the MSIL code and NuGet packages that make up Libraries. The commands above will build both.
低レイヤーのライブラリ
内部はILアセンブリ実装
ILファイルのアセンブリ名変更は少し特殊なので注意
アセンブリ名とモジュール名をILコードに直接記述
AssemblyTitleAttributeとAssemblyDescriptionAttributeにアセンブリ名をバイト列で記述
.NETのアップデートによりパッケージが廃止されているライブラリがあるため、対応するバージョンのタグをチェックアウトして作業すべき
ランタイムのビルドが面倒…
v5.0.0のタグは現在ビルドできないため注意
v5.0.18を使用する
その他のバージョンも最新のパッチを使った方が良さそう
ビルドできない不具合はこのあたりが関係していそう
下記のissueと重複しているためclose
v5.0.18を使うまでの試行錯誤（関係ないかも）
VS2022ではなくVS2019を使う
.NETデスクトップ開発とC++デスクトップ開発のコンポーネントをインストールする
VS2022がインストールされていると2019が自動的に選択されないため、VS2019のコマンドプロンプトから実行する
最新のWin10SDKが自動選択されるが、新しいバージョンだとうまくいかない
Win10SDKを変えてビルドすると、発生するエラーが変わった
.vsconfigをVisual Studio Installerに読み込ませて必要なコンポーネントをインストール
.vsconfigはリポジトリのルートにある
リポジトリ内のドキュメント
実行環境のビルド
ビルド環境
ライブラリのビルド
.NETのバージョン5未満のライブラリのソースコード
dotnet/corefxにある
NugetのページにコミットIDが書かれている
corefxリポジトリの場合
VS2019のコマンドプロンプトを開いてリポジトリのルートに移動
build.cmdを実行
各ライブラリをVS2019やVS2022でビルドできない？
.NET SDKの適切なバージョンを参照できない
System.Threading.Tasks.Extensions.dllは下記の場所に存在
C:\Program Files\Unity\Hub\Editor\2022.3.22f1\Editor\Data\Tools\netcorerun
6.0.0.0
C:\Program Files\Unity\Hub\Editor\2022.3.22f1\Editor\Data\UnityReferenceAssemblies\unity-4.8-api\Facades
4.2.0.0
C:\Program Files\Unity\Hub\Editor\2022.3.22f1\Editor\Data\Tools\ilpp\Unity.ILPP.Runner
6.0.0.0
System.ComponentModel.Annotations.dllも同じ場所にあった
TimeProviderを.Net Standard2.1でビルドすれば、System.Threading.Tasks.Extensionsへの依存を無くすことができる
AsyncInterfacesへの依存も無くなる
TimeProviderはAsyncInterfacesのIAsyncDisposableを使用しているが、.Net Standard2.1からはIAsyncDisposableが標準APIに追加されているため
AsyncInterfacesはTasks.Extensionsに依存しているため、nugetではTimeProviderの依存にTasks.Extensionsは含まれていないが、間接的に依存している
extensionsのビルド
build.cmd -vs <keywords>でソリューションを生成してVisualStudioで開く
TimeProvider.Testingの場合は下記
build.cmd -vs TimeProvider
先にbuild.cmdの実行が必要？
後で確認する