1726503457
2024-09-16 08:17:11
で パート1 そして パート2 このシリーズの第 1 部では、素晴らしいアイデア、ソリューション構造、メニューの拡張、エディター インターフェイスへのガジェットの追加などのトピックについて説明しました。このパートでは、アドオンを NuGet パッケージとして作成し、Optimizely NuGet フィードに送信する際の課題について説明します。このシリーズ全体の例は、この Optimizely アドオンテンプレート 私が創り上げてきたもの。
ソリューション内の各プロジェクトは、プライマリ プロジェクトまたはプライマリ プロジェクトの依存関係であると見なされる場合は、NuGet パッケージとして作成する必要があります。例として次のソリューションを検討してください。
- マイソリューション.sln
- MyAddOn.Admin.csproj
- MyAddOn.Core.csproj
- MyAddOn.Test.csproj
このシナリオでは、アドオンの管理者インターフェイスは、コアの共有機能から分離されています。この設計により、コンシューマー サイトは MyAddOn.Admin を Optimizely Web サイト プロジェクトに組み込み、ソリューション構造内の任意のプロジェクト内で MyAddOn.Core を参照できます。その結果、MyAddOn.Admin は MyAddOn.Core に直接依存します。MyAddOn.Admin を NuGet パッケージとして公開するには、MyAddOn.Core も NuGet パッケージとして公開する必要があります。MyAddOn.Admin は開発中にプロジェクト依存関係としてのみ MyAddOn.Core を必要とすることに注意してください。この依存関係は、パッケージ化プロセス中にパッケージ依存関係に変換されます。
Visual Studio を使用している場合は、パッケージ化するプロジェクトを右クリックし、プロパティを選択してプロジェクト プロパティ画面を表示します。パッケージ セクションでは、NuGet パッケージのすべてのプロパティを定義できます。
以下の項目を完了することをお勧めします。
- パッケージID: これはnuget.orgとnuget.optimizely.com内でグローバルに一意の名前である必要があります。
$(AssemblyName)変数の場合、これはプロジェクトの名前と一致します。 - タイトル : Visual Studio では、これをパッケージ マネージャーなどの UI 表示で使用されるパッケージの名前として説明しますが、これはほとんど使用されません。
- パッケージバージョン: これは、3 つまたは 4 つの部分とオプションのアルファまたはベータ タグを含むセマンティック バージョン番号である必要があります。例:
- 1.0.0
- 1.0.0.0
- 0.1.1-アルファ
- 0.2.2.0-ベータ
- 著者: これには、アドオン/リポジトリを所有する主な人物の名前が含まれている必要があります。
- 会社 : これには、アドオンを作成した企業の名前を含める必要があります。個人所有の場合は、これを
$(Authors)Authors プロパティの値が反映されます。 - 説明 : これはアドオンについての短い説明です。これは NuGet パッケージ フィード内と Optimizely CMS 内のプラグイン マネージャー画面内に表示されます。
- 著作権: これには所有者の名前と年が含まれている必要があります。ソフトウェアを作成すると自動的に著作権保護が受けられるため、申請したり料金を支払ったりする必要はありません。英国には著作権作品の登録簿はありません。ただし、著作権を検証するための料金を支払うことで追加の保護を提供する組織があります。著作権の詳細については、こちらをご覧ください。 著作権があなたの作品を保護する仕組みただし、あなたが住んでいる国の中でこの問題について独自に調査を行うことは価値があります。
- プロジェクトURL: これは、アドオンのリポジトリまたは適切なプロジェクト ページを指す必要があります。開発者はこれを使用して、アドオンの詳細を調べたり、解決が必要な問題を報告したりします。
- お読みください: これをリポジトリの readme.md に設定しました。これは NuGet プラットフォーム内の開発者に表示されます。
- この Readme はリポジトリのコンテキスト外で表示され、相対パスでは画像が見つからないため、画像などのアセットには絶対パスがあることを確認してください。
- リポジトリ URL: アドオンがオープンソースであると仮定すると、これはアドオンのリポジトリを指す必要があります。
- タグ : これは、NuGet フィード内でパッケージを見つけやすくするための、区切られたタグのセットです。
- ライセンスファイル: これはリポジトリ内のライセンスを参照する必要があります。アドオンのライセンスの種類については慎重に検討する必要があります。ライセンスによっては、パッケージを利用するためにユーザーがコードをオープン ソースにすることが求められる場合があります。そのため、ライセンスの許容度や制限度について慎重に検討してください。非常に人気のあるアドオンの中には、MIT ライセンスや Apache ライセンスを採用しているものがあることは注目に値します。
- 私は、その寛容性と保証のなさから、MIT ライセンスを利用しています。ユーザーと交流し、提起された問題に対処していますが、私のアドオンは無料で、私の自由時間にメンテナンスしています。
- ライセンスの同意が必要: これにチェックを入れると、消費者はパッケージをインストールするときにライセンスに同意する必要があります。MIT ライセンスを使用している場合は、消費者にアドオンの保証なしの性質を受け入れるよう促すために、これにチェックを入れるとよいでしょう。
Visual Studio ではなく Visual Studio Code を使用している場合は、.csproj を直接編集し、csproj ファイルの先頭にパッケージ プロパティを XML 値として直接追加できます。また、代わりにこれらのプロパティを .nuspec に追加することもできます。プロジェクトをパッケージ化するときに、.csproj と .nuspec の値が、コンパイルされた .nupkg ファイルのルートに含まれる新しい .nuspec にマージされます。個人的には、NuGet プロパティを .csproj に直接配置することを好みます。
net6.0;net8.0
true
1.1.0.0
https://example.com/
https://example.com/
LICENSE.txt
Your Name
Your Package Summary
Your Name 2024
TagOne TagTwo
true
git
README.md
1.1.0.0
True
A short release summary.
enable
Package Name
NuGet パッケージは、構造化された一連のファイルを含む zip ファイルです。.nupkg の名前を .zip に変更すると、それを抽出して構造を調べることができます。次のような構造になります。
- パッケージ
- 建てる
- コンテンツファイル
- ライブラリ
- ネット6.0
- ネット8.0
- 私のプロジェクト
- _rels
- [Content_Types].xml
- 読み物
- ライセンス.txt
build、contentFiles などのフォルダーや、lib の下のターゲット フォルダーは、コードやデプロイ可能なファイルによって異なります。.csproj または .nuspec で参照される readme.md ファイルと license.txt ファイルは、NuGet パッケージのルートにコピーされます。
.NET Core は下位互換性があるため、.NET 6 用にパッケージをビルドすると、.NET 6、7、8 にインストールできます。ほとんどのアドオンでは、.NET 6 用に直接コンパイルすると最大限の互換性が確保されます。
ただし、複数のフレームワーク バージョンでアプリケーションをコンパイルする必要がある場合もあります。たとえば、Entity Framework と Migrations を使用している場合、.NET 6 と .NET 8 の間には重大な変更があります。幸い、コードの変更は必要ありませんが、.NET 6 と .NET 8 の依存関係を個別に設定する必要があります。これを実現するには、2 つの変更を行う必要があります。
- 変更する
TargetFramework.csproj内のノードをTargetFrameworksターゲットフレームワークをセミコロンで区切ります。例:net6.0;net8.0。 - 別途追加
ItemGroupフレームワークバージョンごとにフレームワーク固有の依存関係を含め、特定のフレームワークをターゲットとする条件をItemGroupに追加します。例:Condition="'$(TargetFramework)' == 'net6.0'"。
net6.0;net8.0
true
enable
これにより、各ターゲット フレームワークごとに個別のフォルダー (そのフレームワーク用にコンパイルされたコードを含む) が含まれるため、NuGet パッケージのサイズが 2 倍になります。
パッケージに IFrameComponent またはエディターインターフェースを拡張するために必要なその他のファイル。 module.config ファイルとそれらのファイルを modules/_protected/my_project 対象 Web サイト内のフォルダー。
まず、.csprojファイルにこれらのファイルをコピーすることを指示する必要があります。 contentFiles NuGetパッケージのフォルダー。これは、これらのファイルのビルド出力を設定するのと同じくらい簡単です。 None そして設定する PackagePath の中にいる contentFiles フォルダ。
true
contentFilesmodule.config
次に、NuGet パッケージ インストーラーにそれらのファイルの処理方法を指示する .targets ファイルを作成する必要があります。以下の例は、同じことを行っている私自身のアドオンから直接引用したものです。
の ItemGroup .targetsファイルに、NuGetパッケージ構造内の特定のファイルの場所を指定します。 $(MSBuildThisFileDirectory) この場合の変数は.targetsファイルが置かれているディレクトリへの参照です。これはビルドフォルダ内にあるため、 $(MSBuildThisFileDirectory) 変数を module.config ファイルへの相対パスと組み合わせて使用します。
の Target ノードは、実行するように設定されたアクションを実行します。 BeforeBuild. これにより、 Copy アクションは、私のmodule.configファイルをnugetパッケージのcontentFilesフォルダから modules_protectedmy_project フォルダーは、ターゲット Web サイト内に存在します。つまり、パッケージを初めてインストールするときには、module.config ファイルとフォルダーは保護されたモジュール フォルダー内に存在しません。ソリューションを初めてビルドするときに、この場所にコピーされます。
.targetsファイルが実行可能であることを確認するには、NuGetパッケージファイルにコピーされていることを確認する必要があります。これは、.csprojファイルを編集し、.targetsファイルのビルド出力を構成するだけで簡単です。 None そして設定する PackagePath の中にいる build フォルダ。
true
build$(MSBuildProjectName).targets
パッケージの提出
アドオンをOptimizely NuGetパッケージフィードに送信する前に、パッケージがローカル環境とCI/CDパイプラインの両方で正常にインストールされることを確認することが重要です。このプロセスを迅速化するには、パッケージをアルファビルドまたはベータビルドとして公開することを検討してください。 ナゲット まず、公開後、パッケージはインデックスに登録され、数分以内に取得できるようになります。
パッケージをアルファ版またはベータ版として指定するには、 version プロパティを`.csproj`ファイルに追加して、末尾に -alpha または -betaNuGet はこれをプレリリース バージョンとして自動的に認識し、通常はデフォルトでこれらのバージョンをフィルター処理します。開発者は、IDE の NuGet パッケージ ツール内でプレリリース バージョンを表示するオプションを選択することで、これらのプレリリース バージョンを表示できます。
2.0.0.2-beta
パッケージのアルファ版またはベータ版を nuget.org に公開し、ローカルと CI/CD パイプラインの両方でインストールが成功したことを確認すると、パッケージのライブ バージョンを Optimizely に送信する準備が整います。
必ず オプティマイズリーワールド アカウント。新しいアカウントを作成するには、 オプティマイズリーワールド 右上隅にある登録リンクをクリックしてください。このアカウントでは、Optimizely NuGet フィードへのアクセスも提供されます。Optimizely は 2 つの NuGet フィードを管理しています。
v2 NuGet フィードにアップロードされたパッケージは、v3 NuGet フィードに自動的に同期されます。したがって、パッケージを v2 NuGet フィードにアップロードすることをお勧めします。Optimizely がパッケージを受け取ると、Optimizely の QA チームによる承認プロセスが行われます。このプロセス中に、QA チームはアドオンが CMS で正しく機能することを確認します。リポジトリの Readme にテスト ガイダンスを含めると、QA チームにとって非常に役立ちます。このレビュー プロセスには 1 営業日以上かかる場合があり、現在、テストのステータスや結果を通知するフィードバック メカニズムはありません。パッケージが承認されたかどうかを確認するには、NuGet フィードを定期的にチェックしてください。Optimizely は NuGet フィードにアップロードされたすべてのパッケージを検証するため、アドオンの更新を Optimizely から直接ダウンロードし、この方法で独自のパッケージを配布することをお勧めします。修正プログラムをすぐにリリースする必要がある場合は、nuget.org にアップロードすることを検討してください。
Optimizely NuGet フィードに加えて、パッケージを nuget.org に少なくとも 1 回アップロードすることをお勧めします。これにより、パッケージ名が nuget.org で予約され、メイン フィード間でパッケージ名が競合して消費者に影響する可能性が回避されます。
執筆時点では、v3 NuGet フィードに直接アップロードされたパッケージが v2 NuGet フィードに同期されないという問題がありました。この問題が解決されるまで、v3 NuGet フィードのアップロード リンクはユーザーを v2 NuGet フィードにリダイレクトします。Optimizely はこの問題の解決に積極的に取り組んでいます。
- 最大限の互換性を実現するために.NET 6用のパッケージを構築する
- 両方のフレームワーク間に互換性の問題がある場合は、.NET 6 と 8 の両方に対してパッケージをビルドします。
- Razor クラス ライブラリを使用すると、UI と C# コードを一緒にパッケージ化できます。
- パッケージに使用するライセンスについては慎重に検討してください。
- ビルド ターゲット ファイルを使用して、使用アプリケーション内の特定のフォルダーにファイルを配置します。
- Optimizely NuGet フィードに送信する前に、nuget.org でパッケージのインストールとアルファ/ベータ版としての動作をテストします。
- パッケージをアップロードする nuget.optimizely.com 準備ができたら。
2024年9月16日
#Optimizely #アドオンの作成 #NuGet #用のパッケージ化