.NET কনফিগারেশন (app.config / web.config / settings.settings)

Question

আমার কাছে একটি .NET অ্যাপ্লিকেশন রয়েছে যার মধ্যে ডিবাগ এবং রিলিজ বিল্ডগুলির জন্য বিভিন্ন কনফিগারেশন ফাইল রয়েছে। উদাহরণস্বরূপ, ডিবাগ অ্যাপ্লিকেশন কনফিগ ফাইলটি একটি ডেভলপমেন্ট এসকিউএল সার্ভারকে নির্দেশ করে যা ডিবাগিং সক্ষম করে এবং মুক্তির লক্ষ্যমাত্রা লাইভ এসকিউএল সার্ভারকে নির্দেশ করে। এছাড়াও অন্যান্য সেটিংস রয়েছে, যার কয়েকটি ডিবাগ / প্রকাশের ক্ষেত্রে আলাদা are

আমি বর্তমানে দুটি পৃথক কনফিগারেশন ফাইল (debug.app.config এবং release.app.config) ব্যবহার করি। আমার এই প্রকল্পে একটি বিল্ড ইভেন্ট রয়েছে যা বলছে এটি যদি রিলিজ বিল্ড হয় তবে রিলিজ.অ্যাপকনফিগটি অ্যাপ্লিকেশনটিতে অনুলিপি করুন, অন্যথায় ডিবাগ.এপ.কনফিগ অ্যাপ্লিকেশনটিতে অনুলিপি করুন।

সমস্যাটি হ'ল অ্যাপ্লিকেশনটি সেটিংস.সেটেটিং ফাইল থেকে তার সেটিংস পেয়েছে বলে মনে হয়, তাই আমাকে ভিজ্যুয়াল স্টুডিওতে সেটিংস.সেটেটিংগুলি খুলতে হবে যা আমাকে অনুরোধ করে যে সেটিংস পরিবর্তন হয়েছে তাই আমি পরিবর্তনগুলি গ্রহণ করব, সেটিংস সংরক্ষণ করুন এবং সেটিংস সংরক্ষণ করুন এটি সঠিক সেটিংস ব্যবহার করার জন্য পুনর্নির্মাণ করতে।

অনুরূপ প্রভাব অর্জনের জন্য কি আরও ভাল / প্রস্তাবিত / পছন্দসই পদ্ধতি আছে? বা সমানভাবে, আমি কি এটি সম্পূর্ণরূপে ভুলের কাছে পৌঁছেছি এবং এর চেয়ে আরও ভাল পদ্ধতির আছে?

Comments

আমি উইন্ডো থেকে ডিবাগটি অক্ষম করতে চাই, আমি সমস্ত চেক বাক্সটি ডিবাগ সেটিংসে

— আনচেক

Answer 1

যে কোনও কনফিগারেশন যা পরিবেশের ওপারে পৃথক হতে পারে তা অ্যাপ্লিকেশন স্তরে নয়, মেশিন পর্যায়ে সংরক্ষণ করা উচিত । (কনফিগারেশন স্তরের আরও তথ্য।)

এগুলি হ'ল ধরণের কনফিগারেশন উপাদান যা আমি সাধারণত মেশিন স্তরে সঞ্চয় করি:

• আবেদন নির্ধারণ
• সংযোগ স্ট্রিং
• খুচরো = সত্য
• শ্রীমতি সেটিং
• স্বাস্থ্য পর্যবেক্ষণ
• হোস্টিং পরিবেশ
• মেশিন কী

যখন প্রতিটি পরিবেশের (বিকাশকারী, সংহতকরণ, পরীক্ষা, পর্যায়, লাইভ) সি: unique উইন্ডোজ \ মাইক্রোসফট.নেট \ ফ্রেমওয়ার্ক 64 \ v2.0.50727 ON কনফিগ ডিরেক্টরিতে নিজস্ব অনন্য সেটিংস থাকে , তখন আপনি কোনও পরিবেশ ছাড়াই আপনার অ্যাপ্লিকেশন কোড প্রচার করতে পারেন পোস্ট বিল্ড পরিবর্তনসমূহ।

এবং স্পষ্টতই, মেশিন স্তরের CONFIG ডিরেক্টরিতে থাকা সামগ্রীগুলি আপনার অ্যাপ্লিকেশন থেকে কোনও ভিন্ন সংগ্রহস্থল বা কোনও আলাদা ফোল্ডারের কাঠামোয় সংস্করণ-নিয়ন্ত্রিত হয়। আপনি কনফিগসোর্সের বুদ্ধিমান ব্যবহারের মাধ্যমে আপনার .config ফাইলগুলিকে আরও উত্স-নিয়ন্ত্রণ বান্ধব করে তুলতে পারেন ।

আমি এটি 7 বছরের জন্য করছি, 25+ বিভিন্ন সংস্থার 200 টিরও বেশি এএসপি.নেট অ্যাপ্লিকেশনগুলিতে। (দাম্ভিকতার চেষ্টা করে না, কেবল আপনাকে জানাতে চাই যে আমি এমন পরিস্থিতি দেখিনি যেখানে এই পদ্ধতির কাজ হয় না ))

Comments

এমন একটি পরিস্থিতি সম্পর্কে কী আপনি ওয়েব সার্ভার নিয়ন্ত্রণ করেন না এবং তাই মেশিন-স্তরের কনফিগারেশন পরিবর্তন করতে পারবেন না? উদাহরণগুলির মধ্যে একটি তৃতীয় পক্ষের ওয়েব সার্ভার বা একটি এন্টারপ্রাইজে একাধিক বিভাগের মধ্যে ভাগ করা একটি ওয়েব সার্ভার অন্তর্ভুক্ত রয়েছে।

— যৌক্তিকগীত

কাজ হবে না। তবে ভার্চুয়াল মেশিনগুলির যুগে, অ্যামাজন ইসি 2, এবং ডেল থেকে $ 400 সার্ভারগুলি, কেউ কি সত্যিই ভাগ করা মেশিনগুলিতে গুরুতর কিছু করতে পারে? মোটেই কমনীয় হওয়ার চেষ্টা করছি না - আমি সত্যিই মনে করি আপনি যদি একটি ভাগ করা ওয়েব সার্ভারে কাজ করে থাকেন তবে আপনার পুনর্মূল্যায়ন করা উচিত।

— পোর্টম্যান 27'10

বেশিরভাগ কর্পোরেশন যা আমি অভ্যন্তরীণ সাইটগুলির সাথে এক সার্ভারে একাধিক অ্যাপ্লিকেশন হোস্টের সাথে কাজ করেছি - সেখানে কর্পোরেট পর্যায়ে একটি পুনর্বিবেশন করতে হবে

— এমপিপ্রচার্ড

একটি সার্ভারে একাধিক অ্যাপ্লিকেশনগুলি এতক্ষণ ঠিক আছে যতক্ষণ অ্যাপগুলি সমস্ত একই "পরিবেশ" এ থাকে environment উদাহরণস্বরূপ, আপনি অ্যাপ্লিকেশনটির DEV উদাহরণ হিসাবে একই সার্ভারে App1 এর লাইভ উদাহরণটি চাইবেন না। উদাহরণস্বরূপ, আপনার এসএমটিপি সেটিংস আপনার সমস্ত অ্যাপ্লিকেশন জুড়ে ভাগ করা হবে। উত্পাদনে, আপনি একটি আসল মেল সার্ভারের দিকে নির্দেশ করেন; বিকাশে, আপনি ডিস্কের একটি ফাইলকে নির্দেশ করেন।

— পোর্টম্যান

আমি জানি যে এটি কাজ করবে, কিন্তু এটি এখনও মোতায়েন স্বয়ংক্রিয় করার চেষ্টা করার সময় আমি যা প্রস্তাব করব তার বিপরীতে রয়েছে। আমি মনে করি সেটিংস অ্যাপ্লিকেশন নির্দিষ্ট, তাদের অ্যাপ্লিকেশন সহ সংস্করণ নিয়ন্ত্রণ করা এবং এটির সাথে একত্রে বিবর্তিত হওয়া দরকার। মেশিন কনফিগারেশনের উপর নির্ভর করা কেবল শিফট হয়, আমার মতে এটি শক্ত করে তোলে। আমি একসাথে পরিবর্তিত জিনিসগুলি একসাথে রাখতে এবং সেগুলি একসাথে স্থাপন করতে পছন্দ করি। আমি যদি দেবের জন্য একটি নতুন সেটিং যুক্ত করি তবে আমার সম্ভবত প্রোডের জন্য একটি সমতুল্য প্রয়োজন।

— মিগুয়েল মাদেরো

Answer 2

এটি কিছু লোককে सेटिंगস.সেটেটিংস এবং অ্যাপকনফাইগের সাথে ডিল করতে সহায়তা করতে পারে: ভিজ্যুয়াল স্টুডিওতে আমার সেটিংস.সেটেটিং গ্রিডে কোনও মান সম্পাদনা করার সময় প্রপার্টি ফলকটিতে জেনারেটডেফল্টভ্যালুআইনকোড বৈশিষ্ট্যটি দেখুন (আমার ক্ষেত্রে ভিজ্যুয়াল স্টুডিও ২০০।)।

আপনি যদি জেনারেটডিফল্টভ্যালিউইনকোডকে সত্যে সেট করেন (সত্য এখানে ডিফল্ট!), ডিফল্ট মানটি EXE (বা DLL) তে সংকলিত হয়, আপনি যখন সরল পাঠ্য সম্পাদকটিতে এটি খুলবেন তখন আপনি এটি ফাইলটিতে এম্বেড পাবেন।

আমি একটি কনসোল অ্যাপ্লিকেশন নিয়ে কাজ করছিলাম এবং যদি আমি EXE এ খেলাপি হয়ে যায়, অ্যাপ্লিকেশনটি সর্বদা একই ডিরেক্টরিতে রাখা কনফিগারেশন ফাইলটিকে উপেক্ষা করে! বেশ একটি দুঃস্বপ্ন এবং পুরো ইন্টারনেটে এটি সম্পর্কে কোনও তথ্য নেই।

Comments

এই গত সপ্তাহান্তে আমার সঙ্গে ঘটেছিল অবিকল এটি। আমি কেন আমার অ্যাপ্লিকেশনটি আমার app.config ফাইলটিকে উপেক্ষা করছে বলে মনে করার চেষ্টা করে প্রচুর চুল টানলাম! এটি কোনও ওয়েব পরিষেবায় সংযুক্ত হওয়ার কথা এবং পরিষেবা url আমার app.config এ রয়েছে। আমার অজানা, আমি যখন ওয়েব রেফারেন্স তৈরি করেছি তখন এটি একটি সেটিংসও তৈরি করেছে et সেটিংস ফাইল এবং কোডটিতে ডিফল্ট মানটিকে হার্ডকড করে। এমনকি যখন আমি অবশেষে সেটিংস ফাইলটি বের করে ফেললাম (এবং সরিয়ে দিয়েছি), তখনও সেই ডিফল্ট মান হার্ডকোডে থেকে যায় এবং এক্সে এম্বেড হয়ে যায়। খুবই হতাশাজনক!! এই পোস্টটির জন্য ধন্যবাদ, এখন আমি সেই "বৈশিষ্ট্য" থেকে মুক্তি পেতে পারি

— মাইকে কে

+1 এই উত্তরটি সমালোচনামূলক : আপনি যদি নিজের সেটিংটি অ্যাপ.config ফাইলে যেতে চান তবে এর জেনারেটডফ্যাল্টভ্যালিউইনকোড বৈশিষ্ট্যটিকে মিথ্যাতে সেট করুন (ডিফল্টটি সত্য)।

— সবুঙ্কু

Answer 3

এখানে একটি সম্পর্কিত প্রশ্ন রয়েছে:

আপনার বিল্ড প্রক্রিয়াটি উন্নত করা হচ্ছে

কনফিগারেশন ফাইলগুলি সেটিংসকে ওভাররাইড করার একটি উপায় নিয়ে আসে:

<appSettings file="Local.config">

দুটি ফাইল (বা আরও বেশি) পরীক্ষা করার পরিবর্তে, আপনি কেবলমাত্র ডিফল্ট কনফিগারেশন ফাইলটি পরীক্ষা করে দেখুন এবং তারপরে প্রতিটি টার্গেট মেশিনে আপনি একটি লোকালকনফিগ রেখেছেন, সেই অ্যাপ্লিকেশন বিভাগে সেই নির্দিষ্ট মেশিনের ওভাররাইড রয়েছে।

আপনি যদি কনফিগার বিভাগগুলি ব্যবহার করেন তবে সমতুল্য হ'ল:

configSource="Local.config"

অবশ্যই, অন্যান্য মেশিন থেকে সমস্ত লোকালকনফিগ ফাইলগুলির ব্যাকআপ অনুলিপি তৈরি করা এবং কোথাও এটি পরীক্ষা করা ভাল ধারণা, তবে আসল সমাধানের অংশ হিসাবে নয়। প্রতিটি বিকাশকারী লোকালকনফাইগ ফাইলে একটি "উপেক্ষা" রাখে যাতে এটি চেক ইন না হয়, যা প্রত্যেকের ফাইলকে ওভাররাইট করে।

(আপনাকে আসলে এটিকে "লোকালকনফিগ" বলতে হবে না, আমি কেবল এটিই ব্যবহার করি)

Answer 4

আমি যা পড়ছি তা থেকে মনে হচ্ছে আপনি আপনার বিল্ড প্রক্রিয়াটির জন্য ভিজ্যুয়াল স্টুডিওটি ব্যবহার করছেন। আপনি কি এমএসবিল্ড এবং ন্যান্ট ব্যবহার সম্পর্কে ভেবে দেখেছেন? পরিবর্তে ?

ন্যান্টের এক্সএমএল সিনট্যাক্সটি কিছুটা অদ্ভুত তবে একবার আপনি এটি বুঝতে পারার পরে, আপনি যা যা উল্লেখ করেছেন তা করা তুচ্ছ becomes

<target name="build">
    <property name="config.type" value="Release" />

    <msbuild project="${filename}" target="Build" verbose="true" failonerror="true">
        <property name="Configuration" value="${config.type}" />
    </msbuild>

    <if test="${config.type == 'Debug'}">
        <copy file=${debug.app.config}" tofile="${app.config}" />
    </if>

    <if test="${config.type == 'Release'}">
        <copy file=${release.app.config}" tofile="${app.config}" />
    </if>

</target>

Answer 5

আমার কাছে মনে হচ্ছে আপনি ভিজ্যুয়াল স্টুডিও 2005 ওয়েব ডিপ্লোয়মেন্ট প্রকল্প থেকে উপকৃত হতে পারেন ।

এটির সাহায্যে আপনি বিল্ড কনফিগারেশনের উপর নির্ভর করে আপনার ওয়েবকনফিগ ফাইলের বিভাগগুলি আপডেট / পরিবর্তন করতে পারেন।

দ্রুত ওভারভিউ / নমুনার জন্য স্কট গু থেকে এই ব্লগ এন্ট্রিটি একবার দেখুন ।

Answer 6

আমরা ওয়েব ডিপ্লোয়মেন্ট প্রকল্পগুলি ব্যবহার করতাম তবে তখন থেকে ন্যান্টে স্থানান্তরিত হয়েছি। বিভিন্ন সেটিং ফাইলগুলিকে ব্রাঞ্চ করা এবং অনুলিপি করার পরিবর্তে আমরা বর্তমানে কনফিগারেশন মানগুলি সরাসরি বিল্ড স্ক্রিপ্টে এম্বেড করে xmlpoke কার্যের মাধ্যমে তাদের আমাদের কনফিগারেশন ফাইলগুলিতে ইনজেক্ট করি:

  <xmlpoke
    file="${stagingTarget}/web.config"
    xpath="/configuration/system.web/compilation/@debug"
    value="true"
  />

উভয় ক্ষেত্রেই, আপনার কনফিগারেশন ফাইলগুলিতে আপনার যে কোনও বিকাশকারী মান থাকতে পারে তা থাকতে পারে এবং তারা আপনার প্রোডাকশন সিস্টেমগুলি না ভেঙে আপনার দেব পরিবেশের মধ্যে থেকে ভাল কাজ করবে। আমরা খুঁজে পেয়েছি যে বিকাশকারীরা নির্ধারিতভাবে বিল্ড স্ক্রিপ্টের ভেরিয়েবলগুলি পরিবর্তন করার সম্ভাবনা কম দেখায়, তাই দুর্ঘটনাক্রমে ভুল কনফিগারেশনগুলি আমরা চেষ্টা করেছি এমন অন্যান্য কৌশলগুলির তুলনায় বিরল হয়েছে, যদিও প্রক্রিয়াটির প্রথম দিকে প্রতিটি বার যোগ করা এখনও প্রয়োজনীয় ডিভ মানটি ডিফল্টরূপে উত্সাহিত হয় না।

Answer 7

আমার বর্তমান নিয়োগকর্তা প্রথমে ডেস্ক লেভেল (ডিবাগ, স্টেজ, লাইভ ইত্যাদি) মেশিনকনফিগ ফাইলে রেখে এই সমস্যাটি সমাধান করেছেন। তারপরে তারা এটিকে বেছে নিতে এবং সঠিক কনফিগারেশন ফাইলটি ব্যবহার করার জন্য কোড লিখেছিল। এটি অ্যাপ্লিকেশন স্থাপনের পরে ভুল সংযোগের স্ট্রিং দিয়ে সমস্যাটি সমাধান করেছে।

তারা সম্প্রতি একটি কেন্দ্রীয় ওয়েবসার্ভিস লিখেছেন যা মেশিনে কনফিগের মান থেকে সঠিক সংযোগের স্ট্রিংটি আবার পাঠায়।

এটিই কি সেরা সমাধান? সম্ভবত না, তবে এটি তাদের জন্য কাজ করে।

Comments

প্রকৃতপক্ষে আমি মনে করি এটি প্রশংসনীয় মার্জিত, যেহেতু আমি কনফিগারেশনের বিভিন্ন সংস্করণটিকে কোনও সমাধানের মধ্যে দৃশ্যমান রাখতে চাই, সেগুলি লাইভ না হলেও।

— অন্নাকাটা

এটি একটি অত্যন্ত উদ্বেগজনক সমাধান। ক্রিয়াকলাপে এর একটি উদাহরণ সন্ধান করতে চাই।

— মাইক কে

Answer 8

যে সমাধানগুলি আমাকে সূক্ষ্মভাবে কাজ করেছে তার মধ্যে একটি হ'ল ওয়েবডেপাইজেশনপ্রজেক্ট ব্যবহার করা। আমার সাইটে আমার 2/3 বিভিন্ন ওয়েবকনফাইগ ফাইল ছিল এবং নির্বাচিত কনফিগারেশন মোডের উপর নির্ভর করে (প্রকাশ / স্টেজিং / ইত্যাদি ...) প্রকাশের সময় আমি ওয়েব.রেইলকনফাইগের অনুলিপি করে এটির নামকরণ ওয়েবে করব। আফটার বিল্ড ইভেন্টে কনফিগার করুন এবং আমার যেগুলি প্রয়োজন নেই তা মুছুন (উদাহরণস্বরূপ Web.Stasing.config)।

<Target Name="AfterBuild">
    <!--Web.config -->
    <Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\Web.Release.config" DestinationFiles="$(OutputPath)\Web.config" />
    <Copy Condition=" '$(Configuration)|$(Platform)' == 'Staging|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\Web.Staging.config" DestinationFiles="$(OutputPath)\Web.config" />
    <!--Delete extra files -->
    <Delete Files="$(OutputPath)\Web.Release.config" />
    <Delete Files="$(OutputPath)\Web.Staging.config" />
    <Delete Files="@(ProjFiles)" />
  </Target>

Answer 9

আপনি এখানে আরও একটি সমাধান পাবেন: এএসপি.নেট-এ ডেভলপমেন্ট / ইউএটি / প্রোড পরিবেশের মধ্যে কনফিগারেশন স্যুইচ করার সেরা উপায়?যা ওয়েবকনফিগটি স্থানান্তর করতে এক্সএসএলটি ব্যবহার করে।

ন্যান্ট ব্যবহারের জন্য কয়েকটি ভাল উদাহরণ রয়েছে।

Answer 10

আমাদের প্রকল্পের একই সমস্যা রয়েছে যেখানে আমাদের ডিভ, কিএ, ইউট এবং প্রোডের কনফিগারেশন বজায় রাখতে হয়েছিল। আমরা যা অনুসরণ করেছি তা এখানে (আপনি কেবল এমএসবিল্ডের সাথে পরিচিত হলেই প্রযোজ্য):

এমএসবিল্ড সম্প্রদায়ের কাজগুলি এক্সটেনশনের সাথে এমএসবিল্ড ব্যবহার করুন। এটিতে 'XMLMassUpdate' টাস্ক অন্তর্ভুক্ত যা কোনও এক্সএমএল ফাইলটিতে প্রবেশের 'ভর-আপডেট' করতে পারে একবার আপনি একে সঠিক নোড দিয়ে শুরু করার পরে।

বাস্তবায়ন:

1) আপনার একটি কনফিগারেশন ফাইল থাকা দরকার যাতে আপনার ডেভ এনভী এন্ট্রি থাকবে; এটি আপনার সমাধানের কনফিগারেশন ফাইল।

২) আপনার কাছে একটি 'সাবস্টিটিশনস.এক্সএমএল' ফাইল থাকা দরকার, যাতে প্রতিটি পরিবেশের জন্য বিভক্ত (অ্যাপসেটিংস এবং সংযোগসূত্রগুলি) কেবলমাত্র এন্ট্রি থাকে। পরিবেশে যে পরিবর্তনগুলি পরিবর্তিত হয় না তাদের এই ফাইলে রাখার দরকার নেই। তারা সমাধানটির ওয়েবকনফিগ ফাইলে থাকতে পারে এবং কাজটি দ্বারা তাদের স্পর্শ করবে না

3) আপনার বিল্ড ফাইলে, কেবল এক্সএমএল ভর আপডেট টাস্কটি কল করুন এবং প্যারামিটার হিসাবে সঠিক পরিবেশ সরবরাহ করুন।

নীচে উদাহরণ দেখুন:

    <!-- Actual Config File -->
    <appSettings>
        <add key="ApplicationName" value="NameInDev"/>
        <add key="ThisDoesNotChange" value="Do not put in substitution file" />
    </appSettings>

    <!-- Substitutions.xml -->
    <configuration xmlns:xmu="urn:msbuildcommunitytasks-xmlmassupdate">
      <substitutions>
        <QA>
           <appSettings>
            <add xmu:key="key" key="ApplicationName" value="NameInQA"/>
           </appSettings>            
        </QA>
        <Prod>
          <appSettings>
            <add xmu:key="key" key="ApplicationName" value="NameInProd"/>
          </appSettings>            
        </Prod>
     </substitutions>
    </configuration>


<!-- Build.xml file-->

    <Target Name="UpdateConfigSections">
            <XmlMassUpdate ContentFile="Path\of\copy\of\latest web.config" SubstitutionsFile="path\of\substitutionFile" ContentRoot="/configuration" SubstitutionsRoot="/configuration/substitutions/$(Environment)" />
        </Target>

কী কী। আপনি জন্য নির্মিত হয়। মনে রাখবেন যে কোনও সম্ভাব্য পুনরুদ্ধারযোগ্য ভুল এড়াতে আপনার কোনও কনফিগার ফাইলের অনুলিপি ব্যবহার করা উচিত এবং প্রকৃত কনফিগারেশন ফাইলটি নয়।

কেবল বিল্ড ফাইলটি চালান এবং তারপরে আপডেট কনফিগারেশন ফাইলটিকে আপনার স্থাপনার পরিবেশে সরিয়ে দিন এবং আপনার কাজ শেষ হয়েছে!

আরও ভাল ওভারভিউয়ের জন্য, এটি পড়ুন:

http://blogs.microsoft.co.il/blogs/dorony/archive/2008/01/18/easy-configuration-deployment-with-msbuild-and-the-xmlmassupdate-task.aspx

Answer 11

আপনার মত আমিও 'মাল্টি' app.config সেট আপ করেছি - যেমন app.configDEV, app.configTEST, app.config.LOCAL। আমি প্রস্তাবিত কিছু দুর্দান্ত বিকল্প দেখতে পাচ্ছি, তবে আপনি যদি এটি আপনার পক্ষে কাজ করে তবে আপনি নিম্নলিখিতটি যুক্ত করতে পারেন:

আমার আছে একটি
<appSettings>
<add key = "Env" value = "[Local] "/> শিরোনাম বারে আমি এটি ইউআইতে যুক্ত প্রতিটি প্রতিবেদনের জন্য : কনফিগারেশন ম্যানেজআর অ্যাপসেটেটিংস থেকে। ("এনভ");

আমি যে টার্গেট করছি তার একটির পরিবর্তে আমি কনফিগারটির নতুন নামকরণ করেছি (4 টি ইভেন্টের বিপরীতে প্রচুর ডাটাবেস / ডাব্লুসিএফ কনফিগারেশন সহ আমার 8 টি অ্যাপস রয়েছে)। প্রতিটিটিতে ক্লিকঅনস দিয়ে স্থাপন করতে আমি প্রকল্পে 4 টি সিটিং পরিবর্তন করি এবং যাই। (এটি আমি স্বয়ংক্রিয় করতে পছন্দ করি)

আমার একমাত্র গ্যাচা পরিবর্তনের পরে 'সমস্ত পরিষ্কার করা' মনে রাখা উচিত, কারণ ম্যানুয়াল নামকরণের পরে পুরানো কনফিগারেশনটি 'আটকে' থাকে। (যা আমি মনে করি আপনি সেটিংস.সেটিংয়ের বিষয়টি ঠিক করবেন) fix

আমি এটি সত্যিই ভাল কাজ খুঁজে পেয়েছি (একদিন আমি এমএসবিল্ড / ন্যান্ট দেখার জন্য সময় পাবেন)

Answer 12

Web.config:

আপনি যখন আইআইএস-এ আপনার অ্যাপ্লিকেশনটি হোস্ট করতে চান তখন ওয়েবকনফিগের প্রয়োজন হয়। ওয়েব-কনফিগ আইএসআইএসের জন্য কীস্টরেলের সামনে বিপরীত প্রক্সি হিসাবে আচরণ করবে তা কনফিগার করার জন্য এটি একটি বাধ্যতামূলক কনফিগার ফাইল। আপনি যদি এটি আইআইএস-এ হোস্ট করতে চান তবে আপনাকে একটি ওয়েব কনফিগ বজায় রাখতে হবে।

AppSetting.json:

আইআইএসকে উদ্বেগ না করে এমন সমস্ত কিছুর জন্য আপনি অ্যাপসেটিং.জসন ব্যবহার করেন। অ্যাপসেটিং.জসন Asp.Net কোর হোস্টিংয়ের জন্য ব্যবহৃত হয়। ASP.NET কোর বর্তমান পরিবেশ নির্ধারণ করতে "ASPNETCORE_ENVIRONMENT" পরিবেশের পরিবর্তনশীল ব্যবহার করে। ডিফল্টরূপে, আপনি যদি এই মানটি সেট না করেই আপনার অ্যাপ্লিকেশনটি চালনা করেন তবে এটি স্বয়ংক্রিয়ভাবে উত্পাদনের পরিবেশে ডিফল্ট হবে এবং "অ্যাপসেটিং.প্রডাকশন.জসন" ফাইলটি ব্যবহার করবে। আপনি যখন ভিজ্যুয়াল স্টুডিওর মাধ্যমে ডিবাগ করেন এটি পরিবেশের উন্নয়নে সেট করে যাতে এটি "অ্যাপসেটিং.জসন" ব্যবহার করে। কীভাবে উইন্ডোজটিতে হোস্টিং পরিবেশের পরিবর্তনশীল সেট করতে হয় তা বুঝতে এই ওয়েবসাইটটি দেখুন।

App.config:

অ্যাপকনফিগ হ'ল .NET দ্বারা ব্যবহৃত অন্য একটি কনফিগারেশন ফাইল যা মূলত উইন্ডোজ ফর্ম, উইন্ডোজ পরিষেবাদি, কনসোল অ্যাপস এবং ডাব্লুপিএফ অ্যাপ্লিকেশনগুলির জন্য ব্যবহৃত হয়। যখন আপনি আপনার Asp.Net কোর হোস্টিং কনসোল অ্যাপ্লিকেশন app.config- এর মাধ্যমে ব্যবহার করা হয় তখনও ব্যবহৃত হয়।

---

টি এল; ডিআর

কনফিগারেশন ফাইলের পছন্দটি আপনি পরিষেবার জন্য বেছে নেওয়া হোস্টিং পরিবেশের দ্বারা নির্ধারিত হয়। আপনি যদি আপনার পরিষেবা হোস্ট করার জন্য আইআইএস ব্যবহার করে থাকেন তবে একটি ওয়েবকনফিগ ফাইলটি ব্যবহার করুন। আপনি যদি অন্য কোনও হোস্টিং পরিবেশ ব্যবহার করে থাকেন তবে একটি App.config ফাইল ব্যবহার করুন। কনফিগারেশন ফাইল ডকুমেন্টেশন ব্যবহার করে পরিষেবাগুলি কনফিগার করা দেখুন এবং এএসপি.নেট কোরে কনফিগারেশনটি পরীক্ষা করে দেখুন ।

Answer 13

এটি উপরে Asp.net বলেছে, সুতরাং কেন আপনার সেটিংসটি ডাটাবেসে সংরক্ষণ করতে এবং সেগুলি পুনরুদ্ধারে কাস্টম-ক্যাশে ব্যবহার করবেন না?

কারণটি আমরা এটি করেছি কারণ ক্রমাগত উত্পাদন ফাইল আপডেট করার অনুমতি পাওয়ার চেয়ে ক্রমাগত ডাটাবেস আপডেট করা (আমাদের পক্ষে) সহজ।

একটি কাস্টম ক্যাশের উদাহরণ:

public enum ConfigurationSection
{
    AppSettings
}

public static class Utility
{
    #region "Common.Configuration.Configurations"

    private static Cache cache = System.Web.HttpRuntime.Cache;

    public static String GetAppSetting(String key)
    {
        return GetConfigurationValue(ConfigurationSection.AppSettings, key);
    }

    public static String GetConfigurationValue(ConfigurationSection section, String key)
    {
        Configurations config = null;

        if (!cache.TryGetItemFromCache<Configurations>(out config))
        {
            config = new Configurations();
            config.List(SNCLavalin.US.Common.Enumerations.ConfigurationSection.AppSettings);
            cache.AddToCache<Configurations>(config, DateTime.Now.AddMinutes(15));
        }

        var result = (from record in config
                      where record.Key == key
                      select record).FirstOrDefault();

        return (result == null) ? null : result.Value;
    }

    #endregion
}

namespace Common.Configuration
{
    public class Configurations : List<Configuration>
    {
        #region CONSTRUCTORS

        public Configurations() : base()
        {
            initialize();
        }
        public Configurations(int capacity) : base(capacity)
        {
            initialize();
        }
        public Configurations(IEnumerable<Configuration> collection) : base(collection)
        {
            initialize();
        }

        #endregion

        #region PROPERTIES & FIELDS

        private Crud _crud; // Db-Access layer

        #endregion

        #region EVENTS
        #endregion

        #region METHODS

        private void initialize()
        {
            _crud = new Crud(Utility.ConnectionName);
        }

        /// <summary>
        /// Lists one-to-many records.
        /// </summary>
        public Configurations List(ConfigurationSection section)
        {
            using (DbCommand dbCommand = _crud.Db.GetStoredProcCommand("spa_LIST_MyConfiguration"))
            {
                _crud.Db.AddInParameter(dbCommand, "@Section", DbType.String, section.ToString());

                _crud.List(dbCommand, PopulateFrom);
            }

            return this;
        }

        public void PopulateFrom(DataTable table)
        {
            this.Clear();

            foreach (DataRow row in table.Rows)
            {
                Configuration instance = new Configuration();
                instance.PopulateFrom(row);
                this.Add(instance);
            }
        }

        #endregion
    }

    public class Configuration
    {
        #region CONSTRUCTORS

        public Configuration()
        {
            initialize();
        }

        #endregion

        #region PROPERTIES & FIELDS

        private Crud _crud;

        public string Section { get; set; }
        public string Key { get; set; }
        public string Value { get; set; }

        #endregion

        #region EVENTS
        #endregion

        #region METHODS

        private void initialize()
        {
            _crud = new Crud(Utility.ConnectionName);
            Clear();
        }

        public void Clear()
        {
            this.Section = "";
            this.Key = "";
            this.Value = "";
        }
        public void PopulateFrom(DataRow row)
        {
            Clear();

            this.Section = row["Section"].ToString();
            this.Key = row["Key"].ToString();
            this.Value = row["Value"].ToString();
        }

        #endregion
    }
}