ClickOnceの落とし穴/落とし穴/.NETでのスマートクライアントの展開[終了]
-
02-07-2019 - |
質問
複数の.NET Windowsフォームアプリケーションを使用して、 ClickOnce / smart-client展開シナリオ。これはすばらしいチュートリアルではありませんが、落とし穴や「落とし穴」はありますか?知っておくべきことは?
オフとオンで使用されるいくつかのマイナーアプリケーションがありますが、メインアプリケーションはC#で、24時間年中無休で実行され、非常に大きく、数週間ごとにのみ変更されます。また、ローカルでログファイルに書き込み、ローカルハードウェアデバイスと通信します。
解決
ここで私が知っているものをいくつか紹介します。
-
デスクトップにアイコンを配置できません。今すぐできます。 -
すべてのユーザーにインストールすることはできません。
-
展開を別のサーバーに移動するには、フープをジャンプする必要があります。内部で開発している場合、ユーザーは公開先のサーバーを確認したり、パブリックWebに展開している場合は問題になりませんが、複数の顧客サイトに個別に展開する必要がある場合はあまり意味がありません。
-
.NET 3.5 SP1以降、デプロイメントに署名する必要はありません。マニフェストにより、デプロイメントを新しいサーバーに簡単に移動できます。
-
GAC にアセンブリをインストールできません。これを回避するには、ClickOnceアプリケーションの前提条件である通常のインストールパッケージを作成します。
他のヒント
- 更新がデプロイされると、組み込みのダイアログにより、アプリケーション全体が再ダウンロードされているかのように表示されます。実際、変更されたDLLのみがダウンロードされており、表示される進行状況バーは誤解を招く/間違っています。すべてのアセンブリが再デプロイされている理由を理解しようとして時間を無駄にしないでください。私がそれをやったわけではありません。
- 元の展開マニフェストに署名するために使用した証明書の有効期限が切れ、新しい証明書が発行されると、あなたは痛い目に遭います(クライアントはすべてアンインストールして再インストールする必要があります)。詳細は馬の口にある。
ほとんどの問題は解決されましたが、デスクトップショートカットを作成できないと述べた人もいました。実際、 < Visual&nbsp; Studio&nbsp; 2008 SP1でデスクトップショートカットを作成できます。
また、Visual Studioの最新バージョンを使用していない場合は、いつでもインストールされたスタートメニューショートカットへのショートカットを作成するコードを記述。
ClickOnceアプリとして展開するアプリがありました。ユーザーがインストールの一部の設定を変更できる必要がありました(展開パスなど-ITはビルド時に不明なネットワーク共有からファイルを提供したい)。展開内のファイルのいずれかを変更する場合、すべてのハッシュを再計算し、すべてに再署名する必要があります。したがって、このソリューションが内部にある場合、署名証明書の受け渡しに問題はないかもしれませんが、これがクライアント向けである場合、この問題を回避するために派手なソリューションを設計する必要があります。
ClickOnceの将来のバージョンでこの頭痛の種のいくつかが取り除かれるというインターネットのどこかで不平を言っています。
ClickOnceでデプロイされたアプリケーションをサイレントアンインストールすることはできません。また、スタートアップショートカットにパラメータを追加することは不可能だと思います。
ClickOnceの落とし穴の1つは、 GAC 。 DLLファイルを共有する複数のアプリケーションをインストールする場合、これは問題です。各アプリケーションには、DLLファイルのローカルコピーが必要です。また、複数のユーザーのインストールも行われています。 Window InstallerとClickOnceを比較したリストを参照してください。
誰かが検索でこれを参照した場合、多くの顧客がアプリケーションの「配布」のセキュリティの欠如に懸念を持っていることがわかりました。アプリケーションは、更新を確認できるようにするために、認証なしで公共の場所で利用できる必要があります。唯一の例外は、Windows NT認証がある場合です。 ClickOnceアプリケーションの保護 で何が説明されていると思いますつまり。
デスクトップアイコンはコードを介して行うのは非常に簡単で、前述のとおり、 3.5 SP1 、焼き付け-これで問題はなくなりました。
xmlSerializerにはまだ修正されていないバグがあります-場合によっては適切にデプロイされません。簡単な回避策は、このファイルを手動で展開に追加することです。 PITA、しかしそれは十分に簡単です...しかし、デプロイメントが突然失敗するとき、それは衝撃的です...
ClickOnceアプリケーションで実行できないことは、ユーザーのデスクトップへのショートカットのインストールや、アプリケーションがインストールされる場所へのsayoの作成など、たくさんあります。一部の人々にとっては、これらは取引ブレイカーです。
また、使用してからしばらく経ちましたが、アプリケーションのバージョン/ビルド番号とは別のClickOnceバージョン/ビルド番号を把握して表示するための特別な方法があります。 try / catchを実行する必要があり、ClickOnceバージョン/ビルド番号が例外をスローする場合、アプリケーションはClickOnceでデプロイされたアプリケーションとして実行されていません(つまり、定期的にコンパイルされたアプリケーションとして、またはVisual Studioから実行されています)。
単純なアプリケーション(つまり、 Microsoft Word ではなく、 Click-Onceは優れた機能です。しかし、あなたはかなり速く「これは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
}
クライアントが認証を必要とするプロキシの背後にある場合、インストールできません。