17

ClickOnceを使用してデプロイされたプロジェクトに取り組んでおり、いくつかの問題が発生しています。

私のソフトウェアソリューションには2つのコンポーネントがあります。実行するために.NETFramework3.5を必要とするデスクトップクライアントと、利用可能なドキュメントを一覧表示し、ClickOnceを使用してデスクトップクライアントをインストールする方法を提供するサーバー（ASP.NETアプリケーション）です。

私の最初の問題は前提条件の問題です。クライアントをインストールする前に3.5フレームワークをインストールする方法が必要です。Visual Studioはsetup.exeそれを処理するを作成しますが、それを機能させるには、（.applicationファイルにリンクするのではなく）直接実行する必要があり、ClickOnceマニフェストを作成するときに展開URLを知っている必要があります。

したがって、さらに2つの問題があります。インストール後にクエリ文字列引数を使用してクライアントアプリケーションを実行する方法がないsetup.exeため、サーバーに「... / client.application？」のようなURLにリンクするドキュメントリストを表示させる代わりに、 document=doc1"へのリンクしか持てませんsetup.exe。

もう1つの問題は最悪です。サーバーは、単一のWebサーバーではなく、比較的小規模なプライベートネットワークで使用することを目的としています。問題は次のとおりです。ビルド時にClickOnceクライアントの展開URLがわからないため、setup.exe[Webサイトからインストール]オプションをオンにすると、が正しく実行できません。setup.exe今のところ、回避策は、大きなZIPファイルに前提条件とClickOnce配置ファイルを含むオフラインインストーラーを用意することです。

適切なフレームワークバージョンを使用しているユーザーは、.applicationクエリ文字列を含むドキュメントへのリンクを使用して、クライアントをインストール/更新し、ドキュメントを開くことができます。フレームワークを持たないユーザーはエラーメッセージ（「システムアップデートが必要ですblablabla 3.5.0.0 blabla GAC」）を受け取り、ZIPファイルをダウンロードしてローカルマシンに抽出し、setup.exeファイルを実行してフレームワークをインストールしてから、クライアントをインストールする必要があります。 。その後、彼はドキュメントリストに戻り、リンクを使用して適切な引数でクライアントを起動する必要があります。

言うまでもなく、私はこの戦略をあまり誇りに思っていません。この戦略は、ClickOnceの展開のすべての利点を台無しにします。

よりエレガントな方法で前提条件の問題を取り除くことは可能ですか？サーバーをネットワークに展開するときにClickOnceアプリケーションのインストールURLを変更する簡単な方法はありますか（構成ファイルなどにURLを書き込むなど）？

4

6 に答える 6

7

私も「ビルド時にclickonceクライアントのデプロイメントURLがわからない」という問題を解決しようとしています。

私が思いつくことができる最善のことは（私はそれを書き始めたばかりなので、これはまだ推測です）、デプロイメントURLを設定するエンドユーザーが実行するユーティリティを書くことです。これは.NETで可能であるように見えますが、次のことを行う必要があります。

  • ManifestReader.ReadManifestを使用してマニフェストを読み取ります
  • DeploymentUrlを設定します
  • ManifestWriter.WriteManifest

次に、SecurityUtilities.SignFileを使用してマニフェストに再度署名する必要があります

署名プロセスは私を悩ませます。使い捨ての証明書を使用する必要があるか（署名が無意味になる）、またはCAからの証明書を使用する必要があり、マニフェストを辞任するためにパスワードを配布する必要があります（証明書が安全でなくなるため愚かです） 。そのため、ユーザーに「不明な発行元」と黄色の感嘆符が表示されたままになっているようです...

于 2009-06-24T22:15:45.250 に答える
5

継続的ビルドシステムでClickOnceアプリケーションをビルドし、複数のテストサーバーにデプロイするために、Mageと記事「ウォークスルー：ClickOnceアプリケーションの手動デプロイ」を使用しました。

これで2番目の問題が解決するかどうかはわかりませんが、複数のサーバーにデプロイする場合は、ビルドプロセスから少なくとも多少の苦痛がかかる可能性があります。配布できるmage.exe場合（Microsoftが許可しているかどうかはわかりません）、インストール中にマニフェストをオンサイトで変更できます。

于 2009-06-22T22:10:51.140 に答える
1

多分解決策は次のようになります：

PublishUrl = http：// clickonce / is / kinda / coolを使用し、クライアントコンピューターで
％windir％\ system32 \ drivers \ etc \ hostsにあるWindowsホストファイルを変更し 、ホストclickonceがサーバーの固定IPアドレスを指すようにします。 。

たぶん、ClickOnceには、アプリケーションのダウンロード元のサーバーを検出するオプションが必要です。誰かが知っているなら、ここに投稿してください。

于 2010-08-04T22:48:24.830 に答える
0

2番目の質問：

次のように、プロジェクト、ソリューション、またはMSBuildファイルでMSBuild公開ターゲットを使用できます。

C:\WINDOWS\Microsoft.NET\Framework\v3.5\msbuild.exe "C:\path\foo.vbproj" /target:Publish /property:"PublishUrl=http://clickonce/is/kinda/cool/" /property:"PublishUrl=http://clickonce/is/kinda/cool/"

PublishUrlIDEでアプリケーションが公開される場所です。InstallUrlnorUpdateUrlプロパティが指定されていない場合は、ClickOnceアプリケーションマニフェストに挿入されます。

InstallUrl（表示されていません）は、ユーザーがアプリケーションをインストールする場所です。setup.exe指定した場合、IsWebBootstrapperプロパティが有効になっていると、この値がブートストラッパーに焼き付けられます。が指定されていない場合は、アプリケーションマニフェストにも挿入されUpdateUrlます。

最初の質問：

上記の答えがあなたのニーズに対応していない場合、あなたは典型的な問題に直面しているように思われます。Windows実行可能ファイル（この場合は.NET Framework 3.5）を複数のデスクトップにインストールするにはどうすればよいですか。グループポリシー（GP）スクリプトやWMIのような複数のソリューションがあります。

于 2009-06-25T02:10:21.893 に答える
0

おそらく、NAntを利用して、デプロイメントURLの変更を自動化することができます。これを使用して、ClickOnceビルドを自動化し、マニフェストのビルドバージョンを変更します。 ClickOnce with NAntは、私がどのようにそれを行ったかを説明しています。

于 2009-06-24T03:09:21.320 に答える
0

ユーザーがドメインにいる場合は、グループポリシー/ Windows Update、またはデスクトップの管理に使用されている他の戦略を使用して、sysadminに.NET3.5をプッシュさせます。

それは環境問題のように聞こえます。組織がシステム管理者を配置するのに十分な規模である場合、アプリケーションを実行するための環境を提供するのはその人の責任である必要があります。

組織にこの役割の人がいない場合は、手動ソリューションに戻っていると思います。また、手動で実行しても、必ずしも「ClickOnceのすべての利点」が損なわれるわけではありません... ClickOnceの利点は、クライアントを変更して再公開すると、クライアントマシンが自動的にアップグレードされることです...

もう1つのオプションは、.NET 3.5を取得してインストールし、アプリケーションをインストールするスクリプトを作成することだと思います。これまでにこれを行ったことはありません...それが機能すると合理的に確信しています...実際には、 .NET3.5も取得するグループポリシーを介した起動スクリプト。これは非常に簡単です。

于 2009-06-24T14:54:59.747 に答える