0

Web.Config ファイルに、接続文字列とジャンクの環境を示すエントリがあります。

<add key="AppEnv" value ="2" /> <!--(0 = Dev, 1 = test, 2 = prod)-->

公開時に開発者に警告して、「テスト」を「本番」サーバーに、またはその逆に公開しないように、このキー/値をチェックしたことを確認する方法を探しています。

ありがとう

4

8 に答える 8

1

私は、この問題に対する独自の (おそらく型にはまらない) 解決策を考え出しました。私たちはさまざまなクライアント向けにさまざまな Web プロジェクトを開発しており、複数の web.config ファイルで発生したすべての問題、または公開前に必要な編集のために、すべてをこの方法に移行しました。

基本的に、受信 URL に基づいて、アプリがどの環境で実行されているかを教えてくれます。最初のリクエストでこれを初期化し、アプリの存続期間中メモリに保存します。このようにして、環境固有の各構成値を同じ構成ファイルに保存し、それらを開発、ステージング、本番などで修飾することができます。また、環境間で異なる設定は修飾する必要はありません。

最初に web.config のサンプル:

<appSettings>
    <add key="DevelopmentHost" value="dev.trackmyhours.com" />
    <add key="StagingHost" value="staging.trackmyhours.com" />
    <add key="ProductionHost" value="www.trackmyhours.com" />
  </appSettings>

  <connectionStrings>
    <clear />
    <add name="DevelopmentConnectionString" connectionString="your dev conn string" providerName="System.Data.SqlClient" />
    <add name="StagingConnectionString" connectionString="your staging conn string (mine is typically same as staging)" providerName="System.Data.SqlClient" />
    <add name="ProductionConnectionString" connectionString="your production conn string" providerName="System.Data.SqlClient" />
  </connectionStrings>

次に、「Site」クラスへのアクセスを可能にする「App」クラスがありますが、適切と思われる方法でクラスを構築できます。

Public Class App

    Private Shared _Site As New Site
    Public Shared ReadOnly Property Site() As Site
        Get
            Return _Site
        End Get
    End Property

End Class

Imports System.Configuration
Imports System.Web

Public Class Site

    Public Enum EnvironmentType
        Development
        Staging
        Production
    End Enum

    Friend Sub New()

        If HttpContext.Current IsNot Nothing Then

            Dim URL = HttpContext.Current.Request.Url.DnsSafeHost

            Select Case URL
                Case ConfigurationManager.AppSettings("DevelopmentHost"), "localhost"
                    _Environment = EnvironmentType.Development
                Case ConfigurationManager.AppSettings("StagingHost")
                    _Environment = EnvironmentType.Staging
                Case ConfigurationManager.AppSettings("ProductionHost")
                    _Environment = EnvironmentType.Production
            End Select

        Else
            'probably getting called from a winforms/console app, or unit tests
            _Environment = EnvironmentType.Staging

        End If

        _ConnectionString = ConfigurationManager.ConnectionStrings(_Environment.ToString & "ConnectionString").ConnectionString

    End Sub


    Private _Environment As EnvironmentType
    Public Property Environment() As EnvironmentType
        Get
            Return _Environment
        End Get
        Set(ByVal value As EnvironmentType)
            _Environment = value

            _ConnectionString = ConfigurationManager.ConnectionStrings(_Environment.ToString & "ConnectionString").ConnectionString

        End Set
    End Property

    Private _ConnectionString As String
    Public ReadOnly Property ConnectionString() As String
        Get
            Return _ConnectionString
        End Get
    End Property

End Class

クラスを Biz Object クラス ライブラリに配置します。アプリの存続期間中は実際には変更できないため、リクエストごとに環境を決定する必要はないと判断しました。また、これにより、ライブラリ内のコードまたはコード ビハインド内のどこからでも App.Site.Environment を参照できます。これは、開発/ステージングで実行しているときに実際の人にメールを送信しないなど、コードに条件付きロジックを振りかける必要がある場合にも役立ちます。

最後にもう 1 つ - Linq2SQL または EF Data/ObjectContext の場合、接続文字列をファイルに格納せず、代わりにコンストラクターをオーバーロードして、次のように正しい環境接続文字列を指定できるようにします。

Partial Class SampleDataContext
    Sub New()
        MyBase.New(App.Site.ConnectionString)
    End Sub
End Class
于 2009-05-21T04:51:34.757 に答える
0

Web.Configを「読み取り専用」に設定すると、これらのサーバーに公開するときに上書きされません。

トレードオフは、各サーバーでweb.configsを手動で維持する必要があり、リモートサーバーでweb.configを上書きできなかったため、公開が失敗したと主張することです。しかし、私見では、アップロードを行うたびに構成を変更するよりも、これが望ましいです。

于 2009-05-29T00:30:44.577 に答える
0

接続文字列をweb.configに保存するのは悪い習慣だと思います。代わりに、Webサイトの外の一般的な既知の場所に別の構成ファイルを作成します。

C：\ xxxx \ config.xml

次に、マシンに依存するすべての設定をそこに保存します。そのため、ライブサーバーにはライブ設定があり、テストサーバーにはテストDBへの接続文字列があり、開発マシンにはローカル設定があります。これらの設定は、そのサーバー上のすべてのWebサイトと.netアプリに沿って再実行することもできます。DBが変更されたときに更新する場所は1つだけです。

完全！

于 2009-05-09T08:19:14.330 に答える
0

テストと本番環境で異なるキーを取得し、まったく新しい.configファイルに配置します。テスト設定をテストに、本番設定を本番に置き、このファイルをテストから本番にコピーすることはありません。次に、通常のweb.configで、次のようにこの新しい.configファイルを指定できます。

<appSettings file="ExternalWeb.config>
    .... common keys go here
</appSettings>

テストサーバーでは、「external.config」にはそのサーバーに固有の値が含まれ、本番環境ではprod値が含まれます。これにより、ファイルを手動で変更することなく、2つのサーバー間でweb.config全体をコピーできます。

于 2009-03-17T12:42:47.767 に答える
0

常に複数のステップを必要とするプロセスがある場合はいつでも、少なくとも半分の時間でそれを台無しにすることを知っています. このため、私は MSBuild が大好きです。

MSBuild には、 AspNetCompiler タスクなど、非常に多くの便利なタスクが含まれています。これは、ワンステップのコンパイル/公開アクションのように見えます。

さまざまな目的で多数の "カスタム" MSBuild タスクを集約するプロジェクトもいくつかあります。MSBuild コミュニティ タスク プロジェクトには、xml 形式のファイルにいくつかの変更を加えるのに役立つ XmlMassUpdate タスクがあります。つまり、web.config ファイルの更新に最適です。

XmlMassUpdate タスクを Web 配置プロジェクトと組み合わせて使用​​する例を見つけましたここ。

于 2009-03-16T19:49:48.200 に答える
0

解決策は次のとおりです。そのファイルを " Web.Config.in" としてソース管理下に保存します。

各サーバー (dev、test、staging、production) で、 にコピーWeb.Config.inして値を慎重にWeb.Config編集します。AppEnv

ある環境から次の環境への後続のプッシュごとに、Web.Configファイルを除外します。つまり、その特定のファイルを上書きしないでください。rsync --exclude WebConfigたとえば、実行する展開スクリプトを記述します。

于 2009-03-16T18:54:02.640 に答える
0

サイトが本番モードでない場合、ページの上部に赤い太字でサイトのモードが表示されます。

また、実行中のサーバーと接続先のデータベースを一覧表示する診断ページもあります。

各データベースにルックアップ テーブルを配置して、適切なフラグが接続されていることを確認することもできます。(テスト DB で 1 としてマークし、Application_Start で値が一致することを確認します)

于 2009-03-16T18:58:31.177 に答える
0

湧き上がる永遠の疑問！真面目な ASP.NET 開発者なら誰でも、何らかの形でこれに頭を悩ませていると思います。

ASP.NET 4.0 については、改善された Web 配置オプションにより、"web.config 変換" と呼ばれる機能が提供される予定です。

このトピックに関するこのチャンネル 9 のビデオをチェックしてください。

マルク

于 2009-03-17T06:27:35.360 に答える