2011-05-10 20 views
9

उन एमएस बिल्ड/वीएस पोस्ट बिल्ड एक्सपोनेंट्स के दिमाग को चुनना चाहता था।विजुअल स्टूडियो 2010 - प्रति डेवलपर/मशीन/पर्यावरण वेब। कॉनफिग सेटिंग्स

मैं अपनी web.config प्रविष्टियों प्रति उपयोगकर्ता/मशीन/पर्यावरण अनुकूलन योग्य होना चाहता हूं।

मैं web.config में चिह्नित मेरी कॉन्फ़िगर करने योग्य/परिवर्तनीय प्रविष्टियां प्राप्त कर सकता हूं और उन प्रविष्टियों को संबंधित उपयोगकर्ता/पर्यावरण फ़ाइल द्वारा ओवरराइड करना चाहूंगा और यह आदेश देना चाहूंगा कि कौन सी प्रविष्टियां दूसरे को ट्रम्प करें यदि प्रविष्टि है कई फाइलों में मिला।

उदाहरण के लिए

: web.config एक $ connectionstring प्रवेश और प्रति उपयोगकर्ता/पर्यावरण अनुकूलन फ़ाइलों संदर्भ/विन्यास समाधान

जिसका मतलब है कि बनाया गया है पर निर्भर करता है $ connectionstring को बदलने के लिए संभावित मान हो सकता है, मैं

user_joe.config

 $connectionstring = db_where_joe_like_to_connect_to 

staging.config

: नीचे की तरह फ़ाइलों का सेट हो सकता था

production.config

 $connectionstring = db_production 

इसलिए यदि जो अपने देव बॉक्स के समाधान के संकलन है, web.config connectionstring $ के लिए मूल्य "db_where_joe_like_to_connect_to" होना चाहिए।

मुझे आशा है कि वहां एक ऐसा समाधान हो सकता है जिसमें नंत शामिल न हो।

उम्मीद है कि कोई पॉइंटर्स फेंक सकता है।

उत्तर

7

आप विजुअल स्टूडियो 2010 की वेब.कॉन्फिग ट्रांसफॉर्म सेटिंग्स का उपयोग कर सकते हैं।

http://weblogs.asp.net/gunnarpeipman/archive/2009/06/16/visual-studio-2010-web-config-transforms.aspx

यह प्रत्येक डेवलपर एक web.config है कि उनके निर्माण सेटिंग्स के लिए में विलय हो सकता है के अपने हिस्से के लिए अनुमति देगा।

आंतरिक रूप से हम एक ऐसी घटना का उपयोग करते हैं जो नेट पर विभिन्न स्थानों से एकसाथ पाई जाती है- आम तौर पर यह प्रकाशन के दौरान होती है और हम संकलन समय पर ऐसा करना चाहते थे।

तो एक BeforeBuild लक्ष्य जोड़ें - csproj फ़ाइल से:

 
<Target Name="BeforeBuild"> 
    <TransformXml Source="$(SolutionDir)Web.config" Transform="$(SolutionDir)Web.$(Configuration).config" Destination="$(SolutionDir)Web.$(Configuration).config.transformed" /> 
    </Target> 
    <PropertyGroup> 
    <PostBuildEvent>xcopy "$(SolutionDir)Web.$(Configuration).config.transformed" "$(SolutionDir)Web.config" /R /Y</PostBuildEvent> 
    </PropertyGroup> 


+0

पॉइंटर्स एडम के लिए धन्यवाद। इससे मदद मिली :) – thanikkal

+1

यह एक भयानक सुझाव है। तो आप कह रहे हैं कि यदि आपके पास 20 डेवलपर्स हैं, तो आपको निर्माण के प्रकारों की संख्या 20 अलग-अलग निर्माण लक्ष्य बनाना चाहिए? यह एक रखरखाव दुःस्वप्न है। –

+1

ओच। भयानक सुझाव या मुश्किल सुविधा? यदि आपके पास बेहतर तरीका है तो हम बेहतर सुझावों के लिए खुले हैं अन्यथा मैं 'दुर्भाग्यपूर्ण' पर वापस जाने पर विचार करता हूं। यदि आप प्रकाशन के दौरान ऐसा करना चाहते हैं तो यह आसान है। यह दुर्भाग्यपूर्ण है हालांकि निर्माण के लिए केवल अतिरिक्त कदम उठाना है। –

1

के रूप में एडम ने कहा कि उनके जवाब में, आप एक तरह से इस web.config का उपयोग कर बदल कर सकते हैं। असल में आपको प्रत्येक पर्यावरण के लिए एक नया समाधान विन्यास बनाना होगा। ध्यान दें कि प्रत्येक डेवलपर के लिए एक होने की संभावना जल्द से जल्द अनजान हो जाएगी, क्योंकि प्रत्येक कॉन्फ़िगरेशन/प्लेटफ़ॉर्म संयोजन में इसकी अपनी बिल्ड सेटिंग्स हो सकती हैं।

इसके अलावा, रूपांतरण केवल वेब साइट पैकेजिंग (पैकेज लक्ष्य को कॉल करने) के दौरान लागू होते हैं। तो यदि आप इसका उपयोग करने की कोशिश कर रहे हैं ताकि जो और सैली की अपनी मशीन पर अलग-अलग कॉन्फ़िगर हो सकें, तो यह आपके लिए ऐसा नहीं करेगा।

उस स्थिति में आप कॉन्फ़िगरेशन को विखंडन की अनुमति देने के बजाय, प्रत्येक कॉन्फ़िगरेशन पर सभी को प्राप्त करने का प्रयास करने से शायद बेहतर हो सकते हैं। प्रत्येक पर्यावरण के बीच अधिक अंतर, कठिन समय आप तैनाती करेंगे।

+0

सहमत हैं, व्यक्तिगत कॉन्फ़िगरेशन रखने से रखरखाव गड़बड़ हो सकती है, लेकिन हमारी टीम है छोटा और मुझे उम्मीद है कि वे जानते हैं कि वे क्या कर रहे हैं :) – thanikkal

+1

ठीक है, यह भी ध्यान रखें कि आप देवताओं को ट्रांसफॉर्म के लिए प्रोजेक्ट को पैकेज करना होगा, और फिर इसे इंस्टॉल करना होगा। तो परिवर्तन दिन-प्रतिदिन के विकास में मदद नहीं करेंगे। – Andy

2

मैं डीबग बिल्ड के लिए web.config प्रविष्टियों में configSource विशेषता का उपयोग करने का सुझाव दूंगा। फिर, आपके परीक्षण और रिलीज में बिल्डिंग में आप परीक्षण और उत्पादन प्रविष्टियों को सम्मिलित करने के लिए डेटा ट्रांसफॉर्मेशन का उपयोग कर सकते हैं।

आप कुछ इस तरह करना होगा:

<connectionStrings configSource="myLocalConnectionStrings.cfg" /> 

तो फिर तुम एक स्थानीय myLocalConnectionStrings बुलाया फ़ाइल है कि आप स्रोत नियंत्रण में जांच नहीं करते है। अपने Web.config.Release में आप उत्पादन स्ट्रिंग्स को शामिल करने और configSource विशेषता को हटाने के लिए कनेक्शनस्ट्रिंग अनुभाग को बस बदल दें।

+0

मुझे स्ट्रिंग कनेक्ट करने के लिए यह पसंद है, लेकिन जब आप किसी कस्टम कॉन्फ़िगरेशन प्रदाता के बिना अन्य सेटिंग्स (ऐप सेटिंग्स, लॉग कॉन्फ़िगरेशन इत्यादि) से निपटते हैं, तो क्या रूपांतरण के अलावा कोई अन्य विकल्प है या ...? –

+0

@AdamTuliper - यह web.config में किसी भी चीज़ के लिए काम करता है। मुझे लगता है कि यह केवल खंडों पर लागू होता है, व्यक्तिगत प्रविष्टियों में नहीं। तो आपको अपने स्थानीय संस्करण में सभी प्रविष्टियों को शामिल करना होगा। एफवाईआई, आप अनुभाग में आंतरिक सामान शामिल कर सकते हैं, लेकिन इसे अनदेखा कर दिया जाएगा। यह आपको अपनी कस्टम फ़ाइल बनाने के लिए एक अच्छा टेम्पलेट देता है। –

0

यहां एक टी 4 समाधान है। यह मेरे मामले के लिए काम करता था क्योंकि यह एक आंतरिक उपकरण था जिसका उपयोग केवल डेवलपर्स द्वारा किया जाएगा और क्योंकि मुझे "शामिल" फ़ाइलों के लिए आगे की प्रक्रिया की आवश्यकता नहीं है।

फ़ाइल का नाम App.tt.

<#@ template debug="false" hostspecific="true" language="C#" #> 
<#@ import namespace="System" #> 
<#@ import namespace="System.IO" #> 
<#@ output extension=".config" #> 
<# 
string pathToConfigurations = Host.ResolvePath("Configurations"); 
string pathToMachine = Path.Combine(pathToConfigurations, Environment.MachineName + ".config"); 
if (File.Exists(pathToMachine)) 
{ 
    Write(File.ReadAllText(pathToMachine)); 
} 
else 
{ 
    Write(File.ReadAllText(Path.Combine(pathToConfigurations, "App.config"))); 
} 
#> 
संबंधित मुद्दे