ただ疑問に思います-アセンブリをGACにデプロイする必要がある場合、それを行う「公式の」方法は何ですか?
現在、c:\ windows \ assemblyフォルダーに手動でドラッグアンドドロップするか、gacutil.exeを使用しています。最初の方法は明らかに良い方法ではなく(結局のところ手動プロセスです)、gacutilはSDKの一部であり、本番サーバーではデフォルトで使用できません。
マイクロソフトの導入ガイドラインはありますか?
ただ疑問に思います-アセンブリをGACにデプロイする必要がある場合、それを行う「公式の」方法は何ですか?
現在、c:\ windows \ assemblyフォルダーに手動でドラッグアンドドロップするか、gacutil.exeを使用しています。最初の方法は明らかに良い方法ではなく(結局のところ手動プロセスです)、gacutilはSDKの一部であり、本番サーバーではデフォルトで使用できません。
マイクロソフトの導入ガイドラインはありますか?
最も簡単な方法は、Setup プロジェクトを使用することです。そこで、プロジェクト出力から特別な GAC フォルダーにアセンブリを追加するだけで、インストーラーがそれらを GAC に追加します。
これを試して :
マネージ GAC API ラッパーのサンプル http://blogs.msdn.com/junfeng/articles/229649.aspx
既存のインストーラー テクノロジを使用していない場合、"公式" の方法は IAssemblyCache::InstallAssembly ネイティブ API を使用することです。しかし、管理された代替手段は System.EnterpriseServices.Internal 名前空間にあります。名前にもかかわらず、実際には標準アセンブリのパブリック クラスです。
もう 1 つのオプションは、InnoSetupなどのツールを使用することです。
Install ShieldのWebサイトによると:
InstallShield 2011: Visual Studio 2010 アプリケーションに最適な Microsoft のインストール ソリューション
自動化できるインストーラーを構築するために私が使用したツールはWixです。試用版、完全版、および管理する必要のあるさまざまな製品用に、さまざまなインストーラーがありました。Wix のおかげで、すべてを管理しやすくすることができました。Wix の仕組みでは、すべてを Xml ファイルで記述します。利点の 1 つは、XML をソース管理下に置くことができることです。
Wix を使用して GAC とローカルの両方に dll を展開する方法に関するブログ投稿を次に示します。