59

मैंने हमेशा अपनी परियोजनाओं को कॉन्फ़िगर करने के लिए जीयूआई समर्थन में निर्मित विजुअल स्टूडियो का उपयोग किया है, अक्सर संपत्ति शीट का उपयोग करके ताकि कई परियोजनाएं एक सामान्य सेट का उपयोग करें।एकाधिक परियोजनाओं और कॉन्फ़िगरेशन के लिए प्रभावी रूप से विजुअल स्टूडियो प्रोजेक्ट गुणों का उपयोग

इसके साथ मेरी मुख्य पकड़ में से एक कई परियोजनाओं, विन्यास और प्लेटफार्मों का प्रबंधन कर रहा है। यदि आप मुख्य जीयूआई के साथ सबकुछ करते हैं (प्रोजेक्ट -> गुणों पर राइट क्लिक करें) यह जल्दी से गड़बड़ हो जाता है, बनाए रखने में मुश्किल होती है और बग प्रवण होती है (जैसे कुछ मैक्रो को सही ढंग से परिभाषित करने में विफल, या गलत रनटाइम लाइब्रेरी का उपयोग करना आदि)। इस तथ्य से निपटने के लिए कि विभिन्न लोगों ने अलग-अलग स्थानों पर निर्भरता पुस्तकालयों को रखा है (उदाहरण के लिए मेरा सभी "सी: \ लिब्स \ [सी, सी ++] \ [lib-name] \" में रहते हैं) और फिर अक्सर उन पुस्तकालयों के विभिन्न संस्करणों का प्रबंधन करते हैं अलग-अलग (रिलीज, डिबग, x86, x64, आदि) भी एक बड़ी समस्या है क्योंकि यह इसे नए सिस्टम पर स्थापित करने के लिए समय को जटिल रूप से जटिल करता है, और उसके बाद संस्करण-नियंत्रण के साथ समस्याएं होती हैं और सभी के पथ अलग-अलग होते हैं ..

संपत्ति पत्रक इसे थोड़ा बेहतर बनाते हैं, लेकिन मेरे पास एक शीट में अलग-अलग कॉन्फ़िगरेशन और प्लेटफॉर्म (ड्रॉप डाउन बक्से एक ग्रिड आउट) के लिए अलग-अलग सेटिंग्स नहीं हो सकती हैं, जिसके परिणामस्वरूप मुझे कई चादरें मिलती हैं जो सही क्रम में विरासत में होती हैं जो मैं चाहता हूं ("x86", "x64", "डीबग", "रिलीज", "सामान्य", "निर्देशिकाएं" (बूस्टएक्स 86 लिबडिर जैसे उपयोगकर्ता मैक्रोज़ को परिभाषित करके पहले उल्लिखित निर्भरता मुद्दे से संबंधित है), और यदि विरासत गलत क्रम में (उदाहरण के लिए "x64" और "डीबग" से पहले "सामान्य") गलत लाइब्रेरी संस्करण को लिंक करने का प्रयास करने या गलत तरीके से नामकरण करने की कोशिश करने जैसे मुद्दों का कारण बनता है ...

जो मैं चाहता हूं वह एक तरीका है इन सभी बिखरी हुई निर्भरताओं से निपटने और "नियम" का एक सेट स्थापित करना जो समाधान में मेरी सभी परियोजनाओं द्वारा उपयोग किया जाता है, जैसे आउटपुट लाइब्रेरी को "mylib- [vc90, vc100] - [x86, x64] [- d] .lib ", प्रत्येक व्यक्तिगत परियोजना, कॉन्फ़िगरेशन और प्लेटफ़ॉर्म संयोजन के लिए यह सब करने के बिना, और फिर उन्हें सिंक में सही ढंग से रखें।

मुझे सीएमके जैसी पूरी तरह से अलग प्रणालियों में जाने की जानकारी है जो आवश्यक फाइलें बनाते हैं, हालांकि यह परियोजनाओं में एक नई फाइल जोड़ने जैसे सरल कार्यों को कहीं और जटिल बनाते हैं, फिर अन्य जगहों में अतिरिक्त परिवर्तन की आवश्यकता होती है, जो कि कुछ ऐसा नहीं है जो मैं पूरी तरह से खुश हूं, जब तक कि वीएस -2010 एकीकरण के साथ कुछ न हो जो इन प्रकार के परिवर्तनों का ट्रैक रख सके।

+1

शामिल होंगे मैं अपने दर्द महसूस: हम काम पर हमारे उत्पाद में 600 से अधिक vcproj की है। :( –

उत्तर

67

मुझे कुछ ऐसा पता चला जो मैंने नहीं सोचा था (यह जीयूआई द्वारा खुलासा नहीं किया गया है) जो संपत्ति शीट को और अधिक उपयोगी बनाने में मदद करता है। प्रोजेक्ट प्रॉपर्टी फाइलों में कई टैग्स की "हालत" विशेषता है और इसका उपयोग .props फ़ाइलों में भी किया जा सकता है!

मैंने अभी परीक्षण के रूप में निम्नलिखित को एक साथ रखा है और यह बहुत अच्छा काम करता है और 5 (सामान्य, x64, x86, डीबग, रिलीज) अलग संपत्ति शीट का कार्य करता है!

<?xml version="1.0" encoding="utf-8"?> 
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <PropertyGroup Label="UserMacros"> 
    <!--debug suffix--> 
    <DebugSuffix Condition="'$(Configuration)'=='Debug'">-d</DebugSuffix> 
    <DebugSuffix Condition="'$(Configuration)'!='Debug'"></DebugSuffix> 
    <!--platform--> 
    <ShortPlatform Condition="'$(Platform)' == 'Win32'">x86</ShortPlatform> 
    <ShortPlatform Condition="'$(Platform)' == 'x64'">x64</ShortPlatform> 
    <!--toolset--> 
    <Toolset Condition="'$(PlatformToolset)' == 'v90'">vc90</Toolset> 
    <Toolset Condition="'$(PlatformToolset)' == 'v100'">vc100</Toolset> 
    </PropertyGroup> 
    <!--target--> 
    <PropertyGroup> 
    <TargetName>$(ProjectName)-$(Toolset)-$(ShortPlatform)$(DebugSuffix)</TargetName> 
    </PropertyGroup> 
</Project> 

केवल मुद्दा गुण जीयूआई नहीं कर सकते इसे संभाल, एक परियोजना के ऊपर संपत्ति शीट का उपयोग करता है सिर्फ रिपोर्ट डिफ़ॉल्ट लक्ष्य के लिए "$ (ProjectName)" की तरह मान विरासत में मिला।

+0

अच्छी तकनीक! – Mordachai

+0

+1 यह – AJG85

+0

हाँ का उपयोग करने के समान ही है, हाँ, संपत्ति शीट VS2k10 में कहीं अधिक शक्तिशाली हैं। सिर्फ एक शर्म की बात है कि आईडीई के माध्यम से इसका कोई खुलासा नहीं हुआ है। मैंने कुछ ऐसा किया है और यह वास्तव में चीजों को सरल बनाता है। – jalf

4

जहां तक ​​उत्पादन पुस्तकालय के रूप में चला जाता है, तो आप अपने सभी परियोजनाओं का चयन कर सकते, तो संपत्ति पृष्ठों लाने के सभी विन्यास, सभी प्लेटफार्म चयन करें और फिर सेट लक्ष्य नाम करने के लिए:

$(ProjectName)-$(PlatformToolset)-$(PlatformShortName)-$(Configuration)

जो की तरह एक निर्गम mylib-V100-86-Debug.lib देना होगा

हम $(PlatformName) और #(Configuration) का उपयोग कर सही पुस्तकालय पथ बाहर लेने के लिए है, हालांकि इसका मतलब यह है कुछ चारों ओर खिलवाड़ के साथ-साथ अतिरिक्त लाइब्रेरी निर्देशिकाएँ के लिए यह करने के लिए कुछ इसी तरह करते हैं, ली के प्रारंभिक सेटअप के साथ braries। उदाहरण के लिए हमने 0 libया boost/lib.x64 पर अपनी libs इंस्टॉल को बढ़ावा दिया है।


साथ पुस्तकालयों के संबंध में, और उन्हें विभिन्न स्थानों में स्थापित करने से लोगों को, वहाँ विकल्पों में से एक जोड़े हैं। यदि आपके पास एक बहुत ही मजबूत स्रोत नियंत्रण प्रणाली है, तो आप अपने स्रोत के बगल में एक libs फ़ोल्डर में रहने, बस सब कुछ स्रोत नियंत्रण में डाल सकते हैं। यदि आप कुछ पुस्तकालयों से अधिक उपयोग करते हैं, या यदि वे विशेष रूप से बड़े हैं तो शायद यह काम नहीं करेगा।

अन्य विकल्प है कि मन में आता है प्रत्येक उपयोगकर्ता मशीन है कि उनके पुस्तकालयों फ़ोल्डर की जड़ है, जैसे LIB_ROOT=c:\libraries को इंगित करता है पर एक वातावरण चर सेट करने के लिए है, और आप तो $(LIB_ROOT) के रूप में दृश्य स्टूडियो में पहुँच सकते हैं।

+0

मैं पहले से ही कुछ बिट्स इस तरह एक सा किया है, लेकिन फिर वहाँ पुस्तकालयों कि उनके नाम में कुछ और ही इस्तेमाल करते हैं (उदाहरण के लिए जारी किए जाने के बजाय चुनते हैं, -d -Debug के बजाय) आदि, जो अभी भी विशेष नियम का एक बहुत आवश्यकता है (my debug.props और release.props ने इस के साथ मदद करने के लिए उपयोगकर्ता मैक्रोज़ सेट अप किया है। वास्तव में शामिल/lib पथ स्थापित करना)। इसे बढ़ावा देने के साथ नहीं माना गया था, अच्छा विचार (अगर ऑटो-लिंकिंग शामिल है तो भी अच्छे हो _not_ x86 के लिए एक ही नाम का उपयोग और 64 बनाता है लेकिन boost.build लोग न अपने एक मुद्दा लगता है लगता है) –

+0

मुझे लगता है कि अपने PlatformShortName एक x86.props और x64.props कि सही ढंग से विरासत में मिला दिया जाना चाहिए या कुछ और से आया है या यह सिर्फ है अप्रलेखित –

+0

@Fire लांसर:।। ईमानदार मुझे यकीन है कि जहां PlatformShortName से आ रहा है मुझे लगता है कि यह एक अंतर्निहित, क्योंकि हम अपने संपत्ति शीट में कुछ भी विशेष नहीं है – ngoozeff

7

मुझे पहले मेरी कंपनी (200+ परियोजनाओं) के उत्पाद के लिए एक ही दर्द था। जिस तरह से मैंने हल किया है वह संपत्ति शीट का एक अच्छा पदानुक्रम बनाना है।

परियोजनाओं इसके उत्पादन प्रकार के आधार पर संपत्ति चादर विरासत, x64.Debug.Dynamic.Library.vsprops का कहना है। यह vsprops फ़ाइल बस विरासत InheritedPropertySheets का उपयोग अन्य संपत्ति शीट विशेषता

<VisualStudioPropertySheet 
    ProjectType="Visual C++" 
    Version="8.00" 
    Name="x64.Debug.Dynamic.Binary" 
    InheritedPropertySheets=".\Common.vsprops;.\x64.vsprops;.\Debug.vsprops;.\Runtime.Debug.Dynamic.vsprops;.\Output.x64.Library.vsprops" 
    > 

तुम भी चर का उपयोग कर सकते हैं (यानी UserMacro, जिसका मूल्य निरपेक्ष या यहाँ तक कि वातावरण चर हो सकता है) संपत्ति शीट में के आधार पर बहुत कुछ अनुकूलित करने के लिए अपने जरुरत। उदाहरण के लिए, Debug.vsprops

<UserMacro name="BIN" Value="Debug" /> 

में एक बिन चर को परिभाषित तो आप vsprops, कहते हैं की श्रृंखला, Output.x64.Library.vsprops

<VisualStudioPropertySheet 
    ProjectType="Visual C++" 
    Version="8.00" 
    OutputDirectory="$(BIN)" 
> 

$ में उत्पादन नाम सेट जब (बीआईएन) चर सेट किया जाएगा जो सेट किया गया है (इस मामले में, डीबग)। इस तकनीक का उपयोग करें, आप आसानी से अपनी मांग को पूरा करने के लिए संपत्ति पत्रों का एक अच्छा पदानुक्रम बना सकते हैं। कि अपनी संपत्ति शीट सेट का उपयोग करता अपनी परियोजना टेम्पलेट्स का निर्माण:

अब एक और बात आप क्या करना चाहते हो सकता है। असली मुश्किल हिस्सा टेम्पलेट्स और संपत्ति शीट के उचित उपयोग को लागू करना है। मेरा व्यक्तिगत अनुभव है कि भले ही सब कुछ सेटअप है, किसी को अभी भी नई परियोजनाओं को बनाने के लिए टेम्पलेट का उपयोग करने भूल जाएगा है ...

0

ऐसा लगता है कि यह एक निर्माण उपकरण बाहर की जाँच के लायक हो सकता है - मेरे घर पर हम एक कस्टम का उपयोग बनाया गया उपकरण जो परिवर्तनों के लिए फ़ाइलों और परियोजनाओं को देखता है और निर्भरता और संकलन आदेश आंकड़े करता है। एक नई फाइल जोड़ना कोई बड़ा सौदा नहीं है - एमएसबिल्ड के साथ संकलन किया जाता है।

तो मैं परियोजनाओं की एक गुच्छा मैं nant की तरह कुछ का प्रयोग करेंगे और अधिक से अधिक संकलित करने के लिए किया था: http://nant.sourceforge.net/

20

मैं कुछ सुधार किए, किसी

<?xml version="1.0" encoding="utf-8"?> 
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <PropertyGroup Label="UserMacros"> 
    <!--IsDebug: search for 'Debug' in Configuration--> 
    <IsDebug>$([System.Convert]::ToString($([System.Text.RegularExpressions.Regex]::IsMatch($(Configuration), '[Dd]ebug'))))</IsDebug> 

    <!--ShortPlatform--> 
    <ShortPlatform Condition="'$(Platform)' == 'Win32'">x86</ShortPlatform> 
    <ShortPlatform Condition="'$(Platform)' == 'x64'">x64</ShortPlatform> 

    <!--build parameters--> 
    <BUILD_DIR>$(registry:HKEY_CURRENT_USER\Software\MyCompany\@BUILD_DIR)</BUILD_DIR> 
    </PropertyGroup> 

    <Choose> 
    <When Condition="$([System.Convert]::ToBoolean($(IsDebug)))"> 
     <!-- debug macroses --> 
     <PropertyGroup Label="UserMacros"> 
     <MyOutDirBase>Debug</MyOutDirBase> 
     <DebugSuffix>-d</DebugSuffix> 
     </PropertyGroup> 
    </When> 
    <Otherwise> 
     <!-- other/release macroses --> 
     <PropertyGroup Label="UserMacros"> 
     <MyOutDirBase>Release</MyOutDirBase> 
     <DebugSuffix></DebugSuffix> 
     </PropertyGroup> 
    </Otherwise> 
    </Choose> 

    <Choose> 
    <When Condition="Exists($(BUILD_DIR))"> 
     <PropertyGroup Label="UserMacros"> 
     <MyOutDir>$(BUILD_DIR)\Bin\$(MyOutDirBase)_$(ShortPlatform)\</MyOutDir> 
     <MyIntDir>$(BUILD_DIR)\Build\$(Configuration)_$(ShortPlatform)_$(PlatformToolset)\$(ProjectGuid)\</MyIntDir> 
     </PropertyGroup> 
    </When> 
    <Otherwise> 
     <PropertyGroup Label="UserMacros"> 
     <MyOutDir>$(SolutionDir)\Bin\$(MyOutDirBase)_$(ShortPlatform)\</MyOutDir> 
     <MyIntDir>$(SolutionDir)\Build\$(Configuration)_$(ShortPlatform)_$(PlatformToolset)\$(ProjectGuid)\</MyIntDir> 
     </PropertyGroup> 
    </Otherwise> 
    </Choose> 

    <PropertyGroup> 
    <OutDir>$(MyOutDir)</OutDir> 
    <IntDir>$(MyIntDir)</IntDir> 
<!-- some common for projects 
    <CharacterSet>Unicode</CharacterSet> 
    <LinkIncremental>false</LinkIncremental> 
--> 
    </PropertyGroup> 
</Project> 
के लिए उपयोगी हो सकता है

मजा!

+2

आप ... पागल हो। लेकिन एक अच्छे तरीके से :) –

+0

इसका मूल्यांकन कब किया जाएगा? परियोजना लोड करते समय? मैं प्रॉपर्टी शीट में कस्टम पोस्ट-बिल्ड कॉपी नियम जोड़ना चाहता हूं ताकि केवल डीएलएल की प्रतिलिपि बनाई जा सके जो वास्तव में परियोजना से जुड़े हुए हैं। क्या आपको लगता है कि यह संभव होगा? – Bim

+0

बिम, मुझे लगता है कि इसे निर्माण से पहले मूल्यांकन किया गया है, क्योंकि यह रजिस्ट्री से चर पढ़ता है (देखें $ (रजिस्ट्री: कुंजी))। – lunicon

4

यह प्रत्येक विन्यास के लिए एक अलग संपत्ति पत्रक बनाने के लिए संभव है।ऐसा करने के लिए:

  1. एक विन्यास विशिष्ट संपत्ति चादर
  2. ओपन संपत्ति प्रबंधक बनाएं
  3. सही विन्यास (नहीं परियोजना) आप
  4. क्लिक करें संशोधित करना चाहते हैं पर क्लिक करें "जोड़ें मौजूदा संपत्ति पत्रक "और अपनी शीट

यह आपको कई कॉन्फ़िगरेशन के लिए एकल शीट में स्थितियों को सम्मिलित करने से मुक्त करता है। यदि आपके पास कुछ सामान्य विशेषताएं हैं जिन्हें आप कॉन्फ़िगरेशन के बीच साझा करना चाहते हैं, तो पदानुक्रम बनाएं। शीर्ष चादर सभी विन्यास में प्रयोग किया जा सकता है और नेस्ट शीट केवल विन्यास विशेष attribut

+0

परफेक्ट! धन्यवाद। तो आप प्रत्येक कॉन्फ़िगरेशन नोड में नए पेज भी बना सकते हैं। साझा पृष्ठ को संपादित करने के जाल में गिरना आसान है जो सभी कॉन्फ़िगरेशन को प्रभावित करता है, भले ही इसे प्रत्येक कॉन्फ़िगरेशन नोड के तहत एक्सेस किया गया हो। – Justin

संबंधित मुद्दे

 संबंधित मुद्दे