2

これが私のシナリオです：

ClickOnceを介して配信しているWPFアプリケーションがあります。アプリケーションには、複数のクライアント用に複数の環境があります（現在は9つですが、近い将来、その2倍になると予想されます）。

私が現在使用しているプロセスは（基本的に）次のとおりです。

  • トークンはapp.configの一部を置き換えます
  • トークンは、MSIインストーラーの生成に使用されるWiXファイルの一部を置き換えます（署名証明書と指紋を含む）
  • ソリューションを構築する
  • クライアント/環境固有のインストーラーを作成する
  • クライアントと環境の組み合わせごとに繰り返します

これには、アプリケーションをインストールするために、必要なインストーラーを実行するという単純なケースであるという意味の利点があります。ただし、欠点は、新しい環境を作成する必要がある場合（いつ）、新しい構成パラメーターのセットを使用してビルドプロセス全体を再実行する必要があることです。

どうすればこれをすべて改善できますか？

私の最近の考えは、ビルドプロセスを分割してバイナリを作成することです。次に、適切なバイナリ、パッチが適用された構成、MAGEを使用した（再）署名されたマニフェストなどを取り込む個別のパッケージ化プロセスを用意します。

これには、「1回ビルド、複数回デプロイ」という継続的なメリットがありますが、新しい環境が必要な場合は、バイナリを再構築せずに再パッケージ化できます。

これは賢明なアプローチのように聞こえますか？誰かがそのようなシナリオのためのガイダンスを持っていますか？

ありがとう

4

2 に答える 2

1

同様のシナリオがあり、WPF ClickOnceアプリケーションが複数の環境で使用されており、app.configの唯一のものは接続文字列です。

クライアント/環境ごとに1つのパッケージをビルドするビルドプロセスがないと、clickonceパッケージ内の構成ファイルを変更できないという事実を回避するために、サーバー展開フォルダーにapp.configファイルを配置できるソリューションを考案しました。アプリケーションに実行時にアクセスさせます。

そのために、app.xaml.csOnStartupイベントで初期化する静的クラスを作成しました。

public static class DbConnectionString {public static string ConnectionString {get; プライベートセット; } public static string ActivationPath {get; プライベートセット; }

public static void Init()
{
    string dbContext = "myDbContext";
    string configFile = "App.config";
    ConnectionString = "";
    ActivationPath = "";

    ActivationArguments actArg = AppDomain.CurrentDomain.SetupInformation.ActivationArguments;
    if (actArg != null)
    {
        if (actArg.ActivationData != null)
        {
            try
            {
                var actData = actArg.ActivationData[0];
                var activationPath = Path.GetDirectoryName(new Uri(actData).LocalPath);
                var map = new System.Configuration.ExeConfigurationFileMap();
                map.ExeConfigFilename = Path.Combine(activationPath, configFile);
                var config = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
                var connectionStringSection = config.ConnectionStrings;
                ConnectionString = connectionStringSection.ConnectionStrings[dbContext].ConnectionString;
                ActivationPath = activationPath;
            }
            catch (Exception)
            {

                ConnectionString = "";
                ActivationPath = "";
            }
        }
    }
}

}

[公開]/[オプション]/[マニフェスト]の[プロジェクト設定]で、[URLパラメーターをアプリケーションに渡すことを許可する]にチェックマークを付けます

次に、接続文字列が必要な静的クラスのConnectionStringプロパティを使用します。アプリをオンラインのみとしてデプロイしない限り設定されないため、dev/testingのパッケージ内のapp.configがデフォルトになります。

少し複雑ですが、うまく機能します。アプリを1回公開し、ビルド間で変更されないインストールごとにapp.configを提供するだけで済みます。

また、clickonceサーバーのインストールディレクトリへのパスであるプロパティActivationPathを設定します。

于 2014-06-27T12:41:55.830 に答える
0

これは正しい方向への一歩のように聞こえます。これは、私がWPFアプリケーションに対して数年間行ってきたことと似ており、うまく機能しています。

Team Cityを使用してソリューションを構築し、ClickOnceパブリッシングを処理する複数のビルド後のステップを構成ごとに1つずつ実行します。各構成には、Mage.exeを使用するMSBuildファイルの開始が含まれます。ソリューションの出力ファイルを一時ディレクトリにコピーしてから、App.configなどのファイルに対して多数の置換を実行し、さまざまなカスタムMSBuildタスクを実行します。

MSBuildプロジェクトファイルには、ClickOnceダウンロードURLなどの基本設定と環境オーバーライドが含まれています。また、特定のファイルをデータとしてマークするかどうかなど、生成されたマニフェスト自体にハッキーな置換を行う必要があります（その後、再署名する必要があります）。

于 2012-07-23T07:23:23.687 に答える