2

現在、クライアントに送信して実行するためのサポート用のVBScript「アプリケーション」があり、クライアントは結果を含むHTMLファイルを返します。概観すると、出力はAbsolute Dynamicsの Syscomp.exe と本質的に似ていますが、私のファイルは単一の .vbs ファイルであり、「比較」機能はありません。

問題:このサポート ツールの要件は絶えず変化しており、その範囲/目的はますます大きくなっています。VBScript が適切なツールであるには大きすぎることがわかりました。理想的には、私の新しいツールには、カスタマイズするためのメカニズムが備わっているでしょう。たとえば、すべての要件/検索対象をハードコーディングする代わりに、App.config などの構成ファイル、またはさらに良いことに、独自のマークアップ スキーマを含む XML ファイルが存在する可能性があります。クライアントごとのニーズに基づいて、アプリケーションの一部として出荷されます。注: これは常に変化するため、「インストールなし」が必要です。これを送信するたびにクライアントにインストールを依頼するつもりはありません。

私の望む解決策:より汎用的なプラットフォームに移行する必要があります。.Net は理想的です。なぜなら、当社はすでに .Net ショップだからです。.Net を使用して、現在の VBScript (単一エンティティ) と同じ方法で配布するソリューションを考え出すことができない場合でも、他の汎用プログラミング フレームワークが言及されている場合は検討します。

私が試したこと:

  • DotNetZip、この SO の質問に関する Cheeso のヘルプに感謝します:圧縮された「zip」ファイルからの .Net アプリケーションの実行。これを使用して、DLL と App.config をサポートする .Net EXE を出荷することができました。これらはすべて、自己解凍型の ZIP にまとめられています。残念ながら、これは Windows XP では機能しません。編集:これは DotNetZip ではなく、Windows XP および Windows Vista の制限であることを確認しました。XP で動作するソリューションが必要です (多くのクライアントは XP または Windows 2003 Server のファームを使用しています)

  • 7Zip - ソリューションを「構築」した後に .config を .7z アーカイブに追加できないため、私のニーズを満たしていません。名前を「.zip」に変更し、新しい .config を追加してから、.zip 拡張子を削除するだけで、DotNetZip で作成された SFX にファイルを追加できました。

  • 構成ファイル (app.config など) のパッキングはビルド プロセスの一部である必要があるため、NBoxは機能しません。ビルド プロセスの後/外の任意の時点で簡単に「ドロップ イン」できる構成が必要であり、それを出荷される最終製品の一部にすることができます。

  • Coffee Cup の Zip Wizardには、ユーザーの介入なしにファイルを解凍する方法がありません。また、解凍後の EXE を実行することもできません。

  • NirSoft による Zip インストーラー。エンド ユーザーにファイルのインストール先を求めるプロンプトが引き続き表示されるため、私の要件を満たしていません。

  • ZIP 2セキュアEXE。残念ながら、これもうまくいきませんでしたが、何が欠点だったのか思い出せません

  • NAR。インストールを実行する必要があるため、これは機能しませんでした。それ以外は、おそらくうまくいくでしょう。

質問:

  • 私の要件を考えると、それは可能ですか?もしそうなら、例えば上記のようなサードパーティ、または私が見逃したサードパーティからどこから始めればよいでしょうか?
  • 私と同じような状況に遭遇した人はいますか?しかし、単一のファイル/エンティティ アプリケーション以外の別のルートを選択し、共有したいと考えていますか?

要件:

  • 単一のエンティティである必要があります (例: EXE、または ZIP)
  • DLL などをサポートする、少なくとも 1 つの構成ファイルをサポートできる必要があります。「堅牢な」アプリケーション。編集: たとえば、コードをビルドした後、自己解凍 ZIP として圧縮できます。誰でも XML 構成を介して「カスタマイズ」し、.exe の名前を .zip に変更し、構成をドロップして送信することができます。
  • XP以降で動作する必要があります。編集:.Netランタイムがインストールされていると仮定します(少なくともv3.5)
4

1 に答える 1

4

基本的に、外部の「もの」がなければ、.net アプリケーションで XP をサポートすることはできません。XP には、標準としてインストールされている .net のバージョンが付属していないため、アプリが動作する前に、ユーザーに .net ランタイムのインストールを要求する必要がある場合があります。 . プラス面として、.net 4.0 を使用すると、プログラムを実行すると、以前の .net アプリケーションのように単純にクラッシュするのではなく、.net 4 ランタイムが必要であることがユーザーに通知されます。

.net を 1 回プレインストールしても問題ないと仮定すると、多くのオプションがあります。

すべてのコードを 1 つのプロジェクトに配置して、1 つのスタンドアロン アセンブリ (.exe) をビルドできます。

または、多数の dll がある場合は、ILMerge などのツールを使用して、出荷前にそれらすべてを 1 つの .exe にマージするか、dll を .exe 内のデータ リソースとして埋め込み、アプリケーションの AssemblyResolve イベントを使用して、システムの必要に応じて、リソースから dll データをロードできます。または、dll をデータ ファイルとして埋め込み、プログラムがこの方法で出荷された dll を呼び出す前に最初に行うこととして、それらを「自動インストール」します (.exe の隣のディスクまたは GAC に保存します)。 .

その他の部分は、アプリケーションがスタンドアロンである必要があることです。必要な設定/設定/リソースは、アプリケーション自体でセットアップする必要があります。たとえば、レジ​​ストリから設定を読み取ることができ、それが存在しない場合、デフォルト値を使用します。XML 構成ファイルがある場合は、それをリソースとして埋め込み、リソースから直接読み取るか、起動時に自動インストールして、アプリケーションが「自己インストール」され、完全に自己完結するようにします。

于 2012-02-22T22:52:18.577 に答える