2

プロダクト キーの検証を提供するためにインストールを行っていたときに、困難な状況が発生しました。キーを検証するには、C++ アンマネージ コードを使用する必要がありました。実際、メインの検証ロジックは C# で記述されていたため、混合プロジェクトを作成する必要がありました。これらだけでは問題が止まらず、続きました。私は VC++ コードを使用したので、少なくとも VC++ ランタイム再頒布可能パッケージがクライアント マシンにインストールされることを期待していました。このような問題があるため、インストールを Wix に移行する計画を取り下げることを考えました。

しかし、C# であらゆる種類のアクションを統合するためにDTFを Wix で使用できるという、非常に優れた優れた機能があることを知りました。私はそれを使用し、キーの検証を数時間で統合できました。今まで、6 か月前に実装したすべてのクライアント マシンで正常に動作しています。

DTF で面白い瞬間や良い経験はありますか?

4

3 に答える 3

2

私のブログ ( http://blog.deploymentengineering.com ) で DTF を検索すると、役立つコンテンツがたくさん見つかります。私は DTF が大好きですが、そもそも CA を可能な限り回避することが最善の解決策であると今でも信じています。C# は、それ以前の VBScript と同様に非常に魅力的であるため、命令的な考え方をする開発者は、不要なときに CA を作成するようになる傾向があります。これが、DTF が長い間リリースされなかった理由だと思います。

私の日常の仕事では、CA が必要だと考える人には、私の承認が必要です。基本的な MSI 哲学、DTF の使用方法、デバッガーのアタッチ方法について開発者に指示し、問題が発生した場合に備えて開発者が対応していることを明確にします。その結果、私たちの製品ラインには非常に少数ですが、よく書かれた CA が含まれています。

于 2010-02-28T01:58:59.980 に答える
1

まず第一に、C#/DTF カスタム アクションは依然としてカスタム アクションです (ここでは魔法ではありません :-))。そのため、この種類の操作についても、さまざまな CA ガイドラインに従う必要があります。高レベルの適切に設計されたクラスの背後にある低レベル API を抽象化することにより、ほとんどの MSI タスクを簡素化します。また、マネージド コード CA を使用できるのは、ターゲット マシンに .NET がインストールされている (または前提条件としてインストールされている) 場合のみであることに注意してください。最後に、WiX ツールセットと一緒に配布されている dtf.chm のドキュメントには、いくつかの単純ですがわかりやすい例があります。

お役に立てれば。

于 2010-02-26T07:17:36.020 に答える
1

WiX ベースのインストールをサポートするために、いくつかの .NET CA を作成しました。

  1. HTTPAPI.DLL のマネージド ラッパー - WCF サービスの展開に使用する IP/Port SSL バインディングと HTTP Url ACL の作成をサポートします。これを Wix 拡張機能に変える予定です。ロールバックなどを適切に処理する方法を学ぶことは非常に興味深いものでした.

  2. システム上のすべての SSL 証明書を表示し、いずれかを選択できる SSL ピッカー ダイアログ。

  3. SQL Server ブラウザ ダイアログ - ネットワークで SQL Server を参照し、次に SQL Server でデータベースを参照できます。オプションで偽装を使用します。これは、接続文字列を作成するためのものです。

  4. Microsoft.Web.Administration アセンブリを使用して IIS 7 に Web アプリケーションをネイティブ インストールする一連の CA を作成中です (IIS 6 メタベース互換機能をインストールする必要はありません)。

于 2010-02-26T19:03:13.203 に答える