2012-04-16 13 views
9

मैं हमारे लिए बिल्डर्स स्थापित करने पर काम कर रहा हूं टीम।माइक्रोसॉफ्ट (टीएफएस) सर्वर बनाएं - नाम या नामस्थान नाम '...' नामस्थान '...' में मौजूद नहीं है (क्या आप एक असेंबली संदर्भ खो रहे हैं?)

पृष्ठभूमि
हम माइक्रोसॉफ्ट विजुअल स्टूडियो 2010 अंतिम उपयोग कर रहे हैं। हमारे उत्पाद में सी # कोड (मुख्य रूप से), बाहरी डीएलएल और सी कोड शामिल है। हम नेट 4.0 के साथ काम कर रहे हैं और 70 से अधिक परियोजनाएं हैं।

हम अपने कोड के 3 शाखाओं के साथ काम कर रहे हैं:

  • उत्पादन branche (जो वर्तमान में जारी किया गया है)
  • टेस्ट branche (गर्म फिक्स, बग फिक्स, अंत उपयोगकर्ता परीक्षण)
  • विकास branche (नए भ्रूण जोड़ना)

सभी शाखाएं टीएफ स्रोत नियंत्रण में हैं।

लक्ष्य
क्या हम चाहते हैं एक बिल्ड सर्वर का निर्माण और एक दिन में एक बार सभी शाखाओं के लिए सभी इकाई परीक्षण चलाने के लिए है, बिल्ड सर्वर स्रोत नियंत्रण में कोड का उपयोग करना चाहिए। हमारा लक्ष्य कुछ तेज मानक त्रुटि पहचान होना है। हम बिल्ड सर्वर को बनाए रखने के लिए कम से कम पसंद करेंगे।

हम बिल्डर्स उत्पाद का निर्माण करने के लिए उपयोग नहीं करेंगे, हम चाहते हैं कि बिल्डिंग सर्वर का उपयोग लगातार हमारी शाखाओं का निर्माण और इकाई परीक्षण करने के लिए करें।

क्या की स्थापना की है
वर्तमान में दो निर्माण परिभाषा टेस्ट Branche के लिए एक और विकास Branche लिए, और दोनों स्रोत नियंत्रण से कोड लेने परिभाषाओं का निर्माण स्थापित कर रहे हैं (वह हिस्सा सब अच्छा काम करता है), लेकिन यहां वह जगह है जहां मजा शुरू होता है।

समस्या
टेस्ट Branche का निर्माण और रन इकाई परीक्षण सब ठीक कर सकते हैं।

विकास Branche (जैसे या की 5) एक की वजह से निर्माण नहीं कर सकते त्रुटियों:

The type or namespace name 'XXX' does not exist in the namespace 'YYY' (are you missing an assembly reference?) 

त्रुटि वाई दोनों परियोजना एक्स परियोजना से परियोजना एक्स refereing के लिए है और वाई सी # नेट 4.0 परियोजनाओं और हम दोनों पर पूरी तरह से नियंत्रण है, एक्स और वाई दोनों को डीएलएल के लिए संकलित किया गया है। प्रोजेक्ट वाई में प्रोजेक्ट एक्स में कक्षाएं इंटरफेस शामिल हैं।

कष्टप्रद विस्तार यह है कि परियोजना एक्स या वाई के लिए टेस्ट ब्रैंच और डेवलपमेंट ब्रेंस में कोई अंतर नहीं है। दोनों परियोजनाएं पिछले 3 महीने पूरी तरह से समान हैं।

तो सवाल यह है कि यह टेस्ट ब्रंच में क्यों काम करता है लेकिन विकास ब्रांच में नहीं?

मैं परीक्षण किया है:
- परियोजनाओं को सही ढंग से एक दूसरे के लिए संदर्भित कर रहे हैं। - सभी 3 शाखाओं में मेरे/किसी भी सहकर्मी विकास मशीनों (हमने 5 अलग-अलग मशीनों पर परीक्षण किया है) पर कोई समस्या नहीं है। - मैंने पूरे एक्स प्रोजेक्ट को हटाने और इसे फिर से बनाने की कोशिश की है, काम नहीं किया। - मैंने पूरे वाई प्रोजेक्ट को हटाने और इसे फिर से बनाने की कोशिश की है, काम नहीं किया है। - मैंने प्रोजेक्ट एक्स प्रोजेक्ट और इसकी कक्षाओं के लिए नेमस्पेस बदलने की कोशिश की है, काम नहीं किया। - मैंने प्रोजेक्ट वाई प्रोजेक्ट और इसकी कक्षाओं के लिए नेमस्पेस बदलने की कोशिश की है, काम नहीं किया। - (मैंने अपनी विकास मशीन को भी पुनरारंभ किया है) - सभी परिवर्तनों को हमेशा स्रोत नियंत्रण में चेक किया गया है जहां बिल्डर्स को बनाने के लिए सेट किया गया था।

अतिरिक्त जानकारी
मैं प्रवेश फाइलों में चारों ओर से खुदाई की गई है और पाया कुछ interessting विवरण, इस विकास Branche

Task "AssignProjectConfiguration" 
    Project reference "..\..\A" has been assigned the "Debug|x86" configuration. 
    Project reference "..\..\Y" has been assigned the "Debug|x86" configuration. (can see there is a project Y) 
    Project reference "..\..\B" has been assigned the "Debug|x86" configuration. 

में निर्माण परियोजना एक्स के विवरण के लिए है लेकिन फिर टास्क में एक ही कार्य के लिए "ResolveAssemblyReference"

Task "ResolveAssemblyReference" 
    TargetFrameworkMoniker: 
     .NETFramework,Version=v4.0 
    TargetFrameworkMonikerDisplayName: 
     .NET Framework 4 
    TargetedRuntimeVersion: 
     v4.0.30319 
    Assemblies: 
     System 
     System.Xml.Linq 
     System.Data.DataSetExtensions 
     Microsoft.CSharp 
     System.Data 
     System.Xml 
     System.Core 
    AssemblyFiles: 
     C:\Builds\1\A 
     C:\Builds\1\B 
(----- Missing project Y -----) 
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll 

कहाँ टेस्ट brance में

Task "ResolveAssemblyReference" 
    TargetFrameworkMoniker: 
     .NETFramework,Version=v4.0 
    TargetFrameworkMonikerDisplayName: 
     .NET Framework 4 
    TargetedRuntimeVersion: 
     v4.0.30319 
    Assemblies: 
     System 
     System.Data.Entity 
     System.Xml.Linq 
     System.Data.DataSetExtensions 
     Microsoft.CSharp 
     System.Data 
     System.Xml 
     System.Core 
    AssemblyFiles: 
     C:\Builds\1\A 
     C:\Builds\1\B 
     C:\Builds\1\Y (There it is) 
    C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll 

तो यह किसी कारण बस "भूल" वाई

सहायता

+0

यदि आप एमएसबिल्ड लॉगिंग विवरण के साथ विस्तृत या डायग्नोस्टिक पर सेट करते हैं तो इसे ResolveAssemblyReference कार्य के दौरान बहुत अधिक जानकारी थूकनी चाहिए, जिसमें प्रत्येक स्थान को देखा गया था और संदर्भ नहीं मिला था। क्या इसमें कोई चेतावनी/त्रुटियां हैं? –

+1

"ResolveAssemblyReference" कार्य से ठीक पहले यह चेतावनी फेंकता है: 'कार्य "चेतावनी" c: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (1200,9): चेतावनी: संदर्भित प्रोजेक्ट '.. \ Y' मौजूद नहीं है। [सी: \ बिल्ड \ 1 \ एक्स] कार्य निष्पादित करने "चेतावनी"। –

+0

मैं पहले लॉग-फ़ाइल में देख सकता हूं: 'फ़ाइल से कॉपी नहीं किया गया "सी: \ बिल्ड \ 1 \ ... \ ... \ y "फाइल करने के लिए" सी: \ बिल्ड \ 1 \ y "क्योंकि" SkipUnchangedFiles "पैरामीटर को प्रोजेक्ट में" सत्य "और फ़ाइलों के आकार और टाइमस्टैम्प मैच पर सेट किया गया था। तो ऐसा लगता है कि इसे चाहिए वहाँ रहना। और और भी, वाई डीएल ड्रॉप स्थान पर भेजा जाता है, लेकिन एक्स डीएल नहीं है। तो वाई डीएल संकलित है। –

उत्तर

6

परियोजना के लिए मैं एक ही समस्या थी परियोजना एक्स से संदर्भ के लिए यह की तरह लगता है। में Path.GetFullPath में बग के कारण

यह समस्या इसलिए होती:

यह मुझे कुछ घंटों पता लगाने के लिए कि इस मामले में समस्या मेरी गलती :-)

http://support.microsoft.com/kb/2516078 नहीं था ले लिया .NET फ्रेमवर्क लाइब्रेरी। यह दृश्य स्टूडियो में एक ज्ञात मुद्दा 2010

लक्षण है:

... जब आप में, कई परियोजनाओं के साथ एक समाधान जहां उन के बीच निर्भरता रिश्तों वहां मौजूद बनाने की कोशिश विशिष्ट स्थितियां एक त्रुटि निम्न त्रुटि संदेश के साथ विफल रहता है।

त्रुटि संदेश: "C: \ WINDOWS \ Microsoft.NET \ फ्रेमवर्क \ v4.0.30319 \ Microsoft.Common.targets (1200, 9): चेतावनी: संदर्भित परियोजना 'से संदर्भित परियोजना के सापेक्ष पथ वर्तमान निर्देशिका 'मौजूद नहीं है। "

एक बिल्ड ऊपर दिए गए त्रुटि संदेश के साथ विफल रहता है जब निम्न शर्तों को पूरा किया जाता है।

  1. आपके पास कई परियोजनाओं का समाधान है जहां उनके बीच निर्भरता संबंध मौजूद हैं।

1) एक संदर्भित परियोजना की निर्देशिका का पथ -

  • निम्न दो पथ लंबाई की राशि वास्तव में 259 वर्ण (1 = MAX_PATH) तक जोड़ा गया है।2) वर्तमान निर्देशिका से एक संदर्भित परियोजना के लिए सापेक्ष पथ (= एक संदर्भ प्रोजेक्ट की निर्देशिका)।

    नोट: MAX_PATH अधिकतम पथ लंबाई Windows API और 260 अक्षरों का होना करने के लिए सेट कर दिया जाता द्वारा परिभाषित किया गया है।

  • वर्कअराउंड:

    इस समस्या के समाधान के लिए, आपको पथ की लंबाई बदल सकते हैं और सुनिश्चित कर सकते हैं कि निम्न दो पथ लंबाई की राशि 259 पात्रों को नहीं जोड़ा गया है अप।

    1. एक संदर्भ परियोजना की निर्देशिका का मार्ग।

    2. वर्तमान निर्देशिका से एक संदर्भित परियोजना के लिए सापेक्ष पथ (= एक संदर्भ प्रोजेक्ट की निर्देशिका)।

    2

    मैं हाल ही में एक ही त्रुटि आई। समाधान VS2010 में स्थानीय रूप से बनाया गया बस ठीक है, लेकिन लगातार निर्माण सर्वर पर असफल रहा। अंत में, MSBuild परिभाषा रिलीज 86 विन्यास के लिए स्थापित किया गया था, लेकिन शिकायत परियोजना \ 86 \ रिलीज डीबगबिन \ 86 \ में एक विधानसभा संदर्भित बिन के बजाय,।

    विधानसभा के रिहाई संस्करण सत्यापित किया जा रहा डिबग संस्करण के बजाय संदर्भित किया गया था (और आवश्यकतानुसार संशोधन) मेरे लिए चाल करने के लिए लग रहा था।

    0

    मैं सिर्फ एक समान मुद्दा मिला है और यह डेवलपर हैं जो पिछले काम पर कोड obj \ डिबग निर्देशिका में कुछ DLLs के लिए संदर्भ जोड़ने का निर्णय लिया जा रहा है समाप्त हो गया।

    1

    दुर्भाग्य से मेरे अंत में समस्या पूरी तरह से अलग थी।

    मैं एक ही फ़ाइल नाम (.Framework.dll) के साथ ही आम कोड के दो विभिन्न संस्करणों, Silverlight 5 के लिए .Net4 के लिए और दूसरा, निर्माण किया गया था।

    के बाद से बिल्ड सर्वर डिफ़ॉल्ट रूप से एक ही फ़ोल्डर के लिए सब कुछ आउटपुट, एकत्र होने की सिल्वरलाइट संस्करण .Net4 एक अधिलेखन समाप्त हो गया क्योंकि MSBuild इसे बाद में बनाने का निर्णय लिया। इसने समाधान में अगली परियोजना के निर्माण के साथ ही एक समस्या उत्पन्न की, जो कि कुछ कक्षाओं पर निर्भर था जो डीएल के .NET4 संस्करण पर उपलब्ध थे, लेकिन सिल्वरलाइट पर नहीं।

    मैं कई समाधान में परियोजनाओं के बंटवारे और निर्माण परिभाषा 'प्रक्रिया' टैब पर सच करने के लिए 'समाधान विशिष्ट बिल्ड आउटपुट' विकल्प सेट समाप्त हो गया।

    1

    मेरे पास एक बहुत ही समान समस्या थी। मैंने पाया कि कॉन्फ़िगरेशन प्रबंधक में, रिलीज़ कॉन्फ़िगरेशन के तहत, प्लेटफ़ॉर्म को किसी भी CPU पर सेट किया गया था और बिल्ड चेकबॉक्स चेक नहीं किया गया था।

    86 के लिए मंच (के रूप में मेरे सारे अन्य परियोजनाओं विरासत कारणों से इस की तैयारी में हैं) की स्थापना और यह सुनिश्चित करें परियोजना इस विन्यास मेरी समस्या का समाधान हो के तहत निर्माण करने के लिए सेट किया गया था बना रही है।

    0

    यह एक छोटा सा सवाल है लेकिन मैं अभी भी इसी तरह के मुद्दे पर आया हूं और मेरे मामले में यह गलत संदर्भित प्रोजेक्ट आईडी (चलो इसे बी बी) प्रोजेक्ट की .cproj फ़ाइल में विफल रहा था (प्रोजेक्ट ए)। मूल रूप से, मैंने प्रोजेक्ट ए को दूसरे समाधान से कॉपी किया और इसे उस समाधान में शामिल किया जो मैं अभी काम कर रहा हूं। संदर्भित परियोजना बी तो दृश्य स्टूडियो स्वचालित रूप से हल हो गई संदर्भ भले ही एक के .cproj संदर्भित परियोजना बी अभी भी समाधान में बी की ओर इशारा करते था में मैं इसे से नकल भी दोनों समाधान में मौजूद था:

    <ProjectReference Include="..\B.csproj"> 
        <Project>{F3006530-D421-4A89-AA8B-376DBAA31E03}</Project> - wrong Id! 
        <Name>ProjectB</Name> 
    </ProjectReference> 
    

    अजीब तरह से, दृश्य स्टूडियो गलत आईडी को अनदेखा कर देगा और संभावित रूप से केवल पथ का उपयोग करेगा, इसलिए कोई बिल्ड त्रुटियां नहीं थीं और प्रोजेक्ट ए के बिन में सही डीएल दिखाई देगा। मेरे बिल्ड सर्वर पर एमएसबिल्ड हालांकि उदार नहीं होगा। इसे ठीक करने के लिए आप या तो टेक्स्ट संपादक में .cproj फ़ाइल संपादित कर सकते हैं या संदर्भों को हटा सकते हैं और यह सुनिश्चित कर सकते हैं कि वे आपके वर्तमान समाधान में हैं।