.NET開発：DEV環境とPROD環境の切り替え。 パート1

はじめに

Visual Studioでプロジェクトを開発およびデバッグするときは、通常、デバッグ構成でコードをコンパイルしてこれを行います。 プロジェクトはバトルサーバーに配置され、リリース構成でコンパイルされます。 そして、各プロジェクトは遅かれ早かれ大きくなり、一種の「デバッグ」または「リリース」コード、つまり、いずれかの構成でのみ動作するコードになります。 問題がコードのみに限定されている場合、＃if条件付きコンパイルディレクティブはすべての問題を解決します。 しかし、通常、各構成に固有のコード、および多くの場合Webページのレイアウトも、コードの背後に広がっています。 冒頭で、そのような問題が現れ始めており、まだ深刻な頭痛ではない場合、通常のコメントは通常、特定の瞬間に必要ではない行/コード/マークアップ/設定にコメントするために使用されます。 しかし、これは最も純粋な形の「地獄への道」です。 そして、ここで天国への階段についてお話したいと思います。







私がそのような問題に最初に遭遇し、コメントやさまざまな構成ファイルのセットからすでに松葉杖に夢中になったとき、ある時点で他の人の経験に興味を持ち、開発環境と使用されるツールの可能性をよりよく探ることに決めました。 そして、突然、すべての人工松葉杖が完全に冗長であることがわかりました。問題は標準的な手段で、コードの可読性を損なうことなく解決できます。 研究の結果を短い記事で説明します。ここでは、環境の問題の例と、プロジェクトを公開するときにすべてのコード、設定、およびhtmlマークアップを目的の形式に自動的に変更できるメカニズムを検討します。 これは、私が主に仕事をしている分野として、ASP.NET MVCアプリケーションの開発に焦点を当てます。 ただし、書かれたものはすべて、Visual Studioでの.NET開発に適用できます。

Web.configファイルの変換

この記事では、最初の重要なツールであるweb.configファイルの変換から始めます。 それでもこの手法に慣れていない場合は、必ずこのセクションをお読みください。



この変換はVisual Studio 2010で登場し、DEV環境とPROD環境のさまざまな設定に関連する膨大な数の問題をすぐに解決しました。 同時に、変換を実行するルールは非常にシンプルで柔軟です。



VS 2010以降、web.configファイルが突然プロジェクトツリーにコンテナとして表示され始め、その中に2つの新しいweb.release.configファイルとweb.debug.configファイルが配置されていることに気づいたでしょう。 これらは、メインweb.configファイルの変換が構成されているファイルです。 これらの2つのファイルはまったく使用できず、メインのweb.configを唯一のファイルとして使用できます。これにより、問題が生じることはありません。 しかし、この禅を理解し、その後、常に賢明に実践するためには、それがより良いでしょう。



変換がどのように機能するかを研究する上で、最も重要なことは、設定時に2つの主なことを明確に理解することです。



1.変換は、プロジェクトの公開時にのみ機能します。



2. web.debug.configおよびweb.release.configファイルは元のweb.configを置き換えませんが、 変更（変換）します



最初の段落は、開発における変換の使用に重大な制限を課しているように思われます。 そして、実際には、たとえばIIS Expressの下で、つまりパブリケーションなしでプロジェクトを開発しているとき、何が良いでしょうか？ しかし、実際にはこれは問題ではありませんが、この点については後で触れます。



2番目の点については、これは私を含む最初の変換に遭遇した人のよくある間違いです。まず、公開時にweb.configファイルを対応するリリース/デバッグファイルに置き換えることを決めました。 もちろん、最初の出版物はマニュアルを注意深く読みました。これはまったく機能しないからです。



これは次のように機能します。変換ファイルでは、適切な構成で公開するときに元のweb.configを変更する方法が指定されます。 私たちは遠くに行かないで、標準的な例を考えます。 自動生成されたweb.release.configファイルには、デフォルトで変換のための1つの標準ディレクティブがすでに含まれています。 リストは次のとおりです（削除されたコメント付き）。

<?xml version="1.0" encoding="utf-8"?> <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <system.web> <compilation xdt:Transform="RemoveAttributes(debug)" /> </system.web> </configuration>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初に、重要な点に注意してください。XML-Document-Transform名前空間のxdtプレフィックスは、構成要素で定義されます。 この名前空間では、変換が定義されている2つの属性、LocatorとTransformが宣言されています。 Locator属性は、構成ファイルで何を変更するかを正確に決定し、Transform属性はこれを行う方法を示します 。 上記の例では、Transformのみが使用されます。その値は、元のweb.configファイルのコンパイル要素のdebug属性を削除する必要があることを示しています（もちろん、その値と共に）。



参考： configuration / system.web / compilation要素のdebug属性は、asp.netページのコンパイルを担当します。 デフォルトのweb.configファイルでは、この属性の値は通常trueであり、これはasp.netページがデバッグ情報が追加されてコンパイルされることを意味します。 リリース構成（つまり、通常PRODでのレイアウト用にプロジェクトがコンパイルされる構成）では、これは必要ありません。このため、この属性を削除するコマンドは、デフォルトでweb.release.config変換ファイルに挿入されます。 これについては、後で詳しく説明します。



例に戻りましょう。 プロジェクトがリリース構成で公開されると、構成値/ system.web / compilation要素のデバッグ属性は、その値とその値が存在するかどうかに関係なく、最終的なweb.configファイルから削除されます。 構成ファイルの特定の要素に対して変換が明示的に設定されているため、この例ではロケーター属性が欠落していることに注意してください。 ただし、Locator属性を使用すると、特にXPath式を使用したり、属性値の明示的な対応を設定したりして、より柔軟な方法で変換のためにweb.configファイルの要素を指定できます。 別の例を次に示します。

 <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <appSettings> <add key="Setting1" value="SettingValue" xdt:Locator="Condition(@key='key1')" xdt:Transform="Replace"/> </appSettings> </configuration>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、ソースweb.configでキーkey1の設定が検索され（これはロケーターのXPathで示されます）、これが見つかった場合は完全に置き換えられます



（Transform属性のReplace属性の値）を使用して、変換を使用してファイルから設定します。 Locator属性のCondition値には、それが定義されている構成ファイルの要素に適用されるXPath式が含まれますが、要素自体は自動的にXPath式の現在の要素になります。 条件に加えて、XPath値はLocator属性で指定できます。XPath式がグローバルコンテキストで考慮される点のみが異なります。



別の例：

 <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <system.web> <customErrors mode="On" xdt:Transform="Insert"> <error statusCode="404" redirect="/Error404" /> <error statusCode="500" redirect="/Error500" /> </customErrors> </system.web> </configuration>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、customErrorsのセクション全体を最終的なweb.configに追加します（ちなみに、エラーが発生した場合のWebアプリケーションの動作を構成するために非常に便利でよく使用されるセクションです）。 Transform属性のInsert値を使用すると、元のweb.configにこのセクションが存在しないことを前提としています。 存在する場合は、InsertではなくReplaceを使用する必要があります。



その結果、さまざまな方法でプロジェクトを公開するときにweb.configファイルをオンザフライで変更できる強力なツールがあります。つまり、個々の要素または要素属性（および要素のグループ全体）を変更、削除、または追加し、値を変更します要素の属性。 これにより、デバッグ中にweb.configファイルの設定や、定期的な「テスト」/「戦闘」の代替に関するコメントを取り除くことができます。 変換属性値の完全なリストと使用例は、 MSDNで見つけることができます。



私のプロジェクトでの変換の実際の使用について話す場合、web.configファイルのすべての設定のうち、次が最も頻繁に影響を受けます。



1.接続文字列、つまりすべてのデータベース接続設定。 これは、接続文字列自体とすべてのORMフレームワークの設定にも適用されます。



2. appSettingsセクションの設定。 すべての設定は、開発/デバッグモードから戦闘使用モードに転送されます。



3. Webアプリケーションのエラー処理設定-上記の例のセクション/<system.web>/。 私のために個人的に開発およびテストするときは、テキストとスタックトレースを含むすべてのエラーを一度に確認し、美しいスタブページにスローされないことが望ましいです。 もちろん、これは戦闘アプリケーションには受け入れられません。



4.設定トレース/ログ/デバッグ。 上記の設定に加えて、>> web.configから、デバッグとトレースに関連するすべての設定がクリアされます（または残されますが、オフになります）。 そして、ログ設定はパラノイドモードから動作モードに転送されます。



5. Webページキャッシュプロファイルの設定。 デバッグ中、ページのHTTPキャッシュは完全に不要であるため、web.debug.configのキャッシュプロファイルは、enabled = = false属性を介して単純に無効にされます。 （OutputCache属性でキャッシュプロファイルを使用しますか？）



もちろん、これは完全なリストではありません-すべては特定のプロジェクトに依存します。 しかし、ほとんどすべての場合、変換によって影響を受けるのはまさにこれらの設定です。



発行が発生しないIIS Expressを使用した開発については、前述したように、これは変換を使用する場合の問題ではありません。 私は非常に頻繁にIIS Expressを使用して（つまり、実際のWebサーバーに公開せずに）Webアプリケーションを開発します。元のweb.configファイルには、DEVバージョンで必要なすべての設定が含まれ、変換はWebでのみ設定されます.release.config。 つまり、元のweb.configは基本的にweb.debug.configファイルとして機能します。



そのため、Visual Studioを使用すると、さまざまな松葉杖やスタブを使用してコード、レイアウト、設定に埋め込むことなく、DEVおよびPROD環境でアプリケーションを柔軟に制御できます。 それでもこの手法を所有していない場合は、このギャップを早急に解消する必要があります。 次の記事で-縮小、バンドル、スクリプト、デバッグ、およびそれを正しく使用する方法について。