ClickOnce /smart-client 展開シナリオに変換する準備をしている.NET Windows Formsアプリケーションがいくつかあります。私はそれほど素晴らしいチュートリアルではありませんを読みましたが、注意すべき落とし穴や「落とし穴」はありますか?
頻繁に使用されるマイナーなアプリケーションがいくつかありますが、メイン アプリケーションは C# であり、24 時間年中無休で実行され、非常に大規模ですが、数週間ごとに変更されるだけです。また、ローカルでログ ファイルに書き込み、ローカル ハードウェア デバイスと通信します。
これが私が知っているいくつかです。
デスクトップにアイコンを配置できません。 いまなら可能です。
すべてのユーザーにインストールすることはできません。
展開を別のサーバーに移動するには、フープをジャンプする必要があります。内部で開発している場合は問題ありません。ユーザーは、公開先のサーバーやパブリックWebに展開しているサーバーを確認できますが、複数の顧客サイトに個別に展開する必要がある場合は問題ありません。
.NET 3.5 SP1以降、デプロイメントマニフェストに署名する必要がなくなり、デプロイメントを新しいサーバーに移動するのがはるかに簡単になりました。
GACにアセンブリをインストールできません。これを回避するには、ClickOnceアプリケーションの前提条件である通常のインストールパッケージを作成します。
ほとんどの問題は解決されましたが、デスクトップ ショートカットを作成できないという報告もありました。実際、Visual Studio 2008 SP1 でデスクトップ ショートカットを作成できます。
また、最新バージョンの Visual Studio を使用していない場合は、いつでもコードを記述して、インストールされているスタート メニューのショートカットへのショートカットを作成できます。
ClickOnceアプリとしてデプロイするアプリがありました。ユーザーがインストールの一部の設定を変更できるようにする必要がありました（展開パスなど-ITは、ビルド時に不明なネットワーク共有からファイルを提供したいと考えています）。デプロイメント内のファイルのいずれかを変更する場合は、すべてのハッシュを再計算し、すべてに再署名する必要があります。したがって、このソリューションが内部的なものである場合、署名証明書の受け渡しに問題はないかもしれませんが、これがクライアント向けである場合は、この問題を回避するための優れたソリューションを設計する必要があります。
インターネットの腸のどこかから、ClickOnceの将来のバージョンでこの頭痛の種の一部が取り除かれるとのうなり声を聞いたことがあります。
ClickOnceの落とし穴の1つは、 GACにインストールできないという事実です。これは、DLLファイルを共有する複数のアプリケーションをインストールする場合に問題になります。各アプリケーションには、DLLファイルのローカルコピーが必要です。また、複数のユーザーによるインストールが行われています。WindowInstallerとClickOnceを比較するリストを参照してください。
ClickOnceでデプロイされたアプリケーションをサイレントアンインストールすることはできません。また、スタートアップショートカットにパラメータを追加することは不可能だと思います。
ClickOnceアプリケーションでは実行できないことがたくさんあります。たとえば、ユーザーのデスクトップへのショートカットをインストールしたり、アプリケーションがインストールされる場所にsaysoを配置したりします。一部の人々にとって、これらは取引を破る者です。
また、使用してからしばらく経ちますが、アプリケーションのバージョン/ビルド番号とは別のClickOnceバージョン/ビルド番号を把握して表示するための特別な方法があります。try / catchを実行する必要があり、ClickOnceのバージョン/ビルド番号が例外をスローした場合、アプリケーションはClickOnceでデプロイされたアプリケーションとして実行されていません（つまり、定期的にコンパイルされたアプリケーションとして、またはVisual Studioから実行されています）。
単純なアプリケーション（つまり、Microsoft Wordではなく、何かを実行するための迅速で汚いアプリケーション）で、多くの定期的な展開が必要なアプリケーションの場合、ClickOnceは最適です。しかし、あなたはすぐに「ああ、これはClickOnceでは実行できません。MSIか何か他のものを選択してください」という壁にぶつかります。
通常の.NETアプリケーションよりもシステムアクセスが少なくなります。
これは、信頼レベルが低くなるためです。詳細については、.NET Framework開発者ガイド：ClickOnceの配置とセキュリティを参照してください。
それに関する私の最大の問題は、マシンキーにアクセスできないため、構成ファイルのセクションをマシンキーで暗号化できないことでした（考えてみると、そのキーを保護することは理にかなっています）。
SP1 でデスクトップ アイコンを作成できるとは知りませんでした。
これが私たちが行ってきた方法です（現在は「難しい方法」として知られています）：
try
{
string company = string.Empty;
string product = string.Empty;
if (Attribute.IsDefined(asm, typeof(AssemblyCompanyAttribute)))
{
AssemblyCompanyAttribute asCompany = (AssemblyCompanyAttribute)Attribute.GetCustomAttribute(asm, typeof(AssemblyCompanyAttribute));
company = asCompany.Company;
}
if (Attribute.IsDefined(asm, typeof(AssemblyProductAttribute)))
{
AssemblyProductAttribute asProduct = (AssemblyProductAttribute)Attribute.GetCustomAttribute(asm, typeof(AssemblyProductAttribute));
product = asProduct.Product;
}
if (!string.IsNullOrEmpty(company) && !string.IsNullOrEmpty(product))
{
string desktopPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Desktop),
product + ".appref-ms");
string shortcutPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Programs),
Path.Combine(company, product + ".appref-ms"));
File.Copy(shortcutPath, desktopPath, true);
}
}
catch
{
// Shortcut could not be created
}
誰かが検索でこれを参照した場合、多くの顧客がアプリケーションの「配布」のセキュリティの欠如に懸念を抱いていることがわかりました. アプリケーションは、更新を確認できるように、認証なしで公開されている場所で利用できる必要があります。唯一の例外は、Windows NT 認証を使用している場合です。ClickOnce アプリケーションを保護すると、私の言いたいことが説明できると思います。
デスクトップ アイコンは、コードを介して実行するのはかなり簡単であり、前述のように3.5 SP1で組み込まれているため、これはもはや問題ではありません。
xmlSerializer にはまだ修正されていないバグがあり、場合によっては適切にデプロイされません。簡単な回避策は、このファイルをデプロイメントに手動で追加することです。PITAですが、それは十分に簡単です...展開が突然失敗するとショックになる可能性があります...
クライアントが認証を必要とするプロキシの背後にある場合、インストールできません。