इस प्रोजेक्ट के लिए OutputPath प्रॉपर्टी सेट नहीं है

Question

जब मैं Visual Studio 2008 में x86 डिबग मोड से अपनी परियोजना को संकलित करने का प्रयास करता हूं। मुझे यह त्रुटि मिल रही है। जब मैंने शिकायत की गई परियोजना के संपत्ति समूह को देखा, तो मुझे लगता है कि आउटपुट पथ सेट है।

यहाँ .csproj फ़ाइल के लिए संपत्ति समूह अनुभाग है

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
  <DebugSymbols>true</DebugSymbols>
  <OutputPath>bin\x86\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE</DefineConstants>
  <BaseAddress>285212672</BaseAddress>
  <FileAlignment>4096</FileAlignment>
  <DebugType>full</DebugType>
  <PlatformTarget>x86</PlatformTarget>
 <ErrorReport>prompt</ErrorReport>

क्या कोई इस पर प्रकाश डाल सकता है?

नोट: जब मैंने इस डिबग और किसी भी सीपीयू को संकलित किया तो यह काम किया।

अद्यतन: त्रुटि 1 इस प्रोजेक्ट के लिए OutputPath गुण सेट नहीं है। कृपया सुनिश्चित करें कि आपने एक मान्य कॉन्फ़िगरेशन / प्लेटफ़ॉर्म संयोजन निर्दिष्ट किया है। कॉन्फ़िगरेशन = 'डीबग' प्लेटफ़ॉर्म = 'x86'

Comments

ठीक है और आप किस कॉन्फ़िगरेशन और प्लेटफ़ॉर्म का उपयोग करते हैं? डिबग + x86 या कुछ और?

— ओन्ड्रेज टुकनी

हां वीएस कॉन्फ़िगरेशन मैनेजर मैं डिबग + x86

— अमजथ

@DmitryShkuropatsky अपडेटेड एरर मैसेज

— अमज़थ

यह सही लग रहा है। क्या समाधान में कोई अन्य परियोजना है जो त्रुटि का कारण हो सकती है?

— दिमित्री शुक्रोपत्स्की 21

@DmitryShkuropatsky आप सही हैं यह एक और परियोजना थी जिसका मुद्दा था। लेकिन वीएस ने उस परियोजना के बारे में शिकायत की जिसे संकलित किया जा रहा है

— अमज़थ

Answer 1

Visual Studio में कॉन्फ़िगरेशन प्रबंधक के माध्यम से एक नया कॉन्फ़िगरेशन जोड़ने के बाद मेरे पास सटीक त्रुटि थी।

यह तब पता चला जब पूरे समाधान (और प्रत्येक परियोजना) के लिए 'प्रोडक्शन' कॉन्फ़िगरेशन जोड़ा गया था । आउटपुट फ़ाइल को .csproj फ़ाइलों में नहीं जोड़ा गया था ।

ठीक करने के लिए, मैं प्रोजेक्ट संपत्तियों में बिल्ड टैब पर गया, आउटपुटपैथ \bin\Production\को \bin\Production(हटाए गए अनुगामी \) से बदल दिया और परिवर्तनों को सहेज लिया। यह .Psproj फ़ाइल में आउटपुटपाथ तत्व का निर्माण और प्रोजेक्ट सफलतापूर्वक बनाया गया है।

मेरे लिए एक गड़बड़ की तरह लगता है।

Comments

इस व्यापारिक त्रुटि पर अच्छी पकड़। कभी अनुमान नहीं लगाया होगा कि एक भी स्लैश उस अंतर को बड़ा बना सकता है। एक अच्छा जवाब बैज है।

— .फ्लिपक '

मेरे मामले में, एक proj फ़ाइल का निर्माण, के बीच का अंतर any cpuऔर anycpuमुद्दा था, लेकिन आपकी पोस्ट ने मुझे यह देखने में मदद की।

— जोशुआ ड्रेक

शुक्रिया रोमन आपने मेरा दिन बचाया ... अगर केवल मैं आपके उत्तर को 100 बार बढ़ा सकता था! :)

— मार्टिन

बस वीएस 2017 v15.6.6 में इसका सामना किया, बेकन ने बचाया, धन्यवाद!

— उग्रवादी

@ जोशुआ ड्रेक, वीएसटीएस का उपयोग करते समय यह एक महत्वपूर्ण मुद्दा है। दृश्य स्टूडियो ऑनलाइन 'किसी भी CPU' का उपयोग करता है, जबकि स्थानीय दृश्य स्टूडियो 'anycpy' का उपयोग करता है। स्क्रिप्ट बनाने के लिए महत्वपूर्ण है।

— फ्रेंकीहॉलीवुड

Answer 2

आप इस त्रुटि को VS 2008 में देख सकते हैं यदि आपके पास अपने समाधान में एक परियोजना है जो एक असेंबली का संदर्भ देती है जो नहीं मिल सकती है। यह तब हो सकता है यदि असेंबली किसी अन्य प्रोजेक्ट से आती है जो आपके समाधान का हिस्सा नहीं है, लेकिन होना चाहिए। इस मामले में बस समाधान के लिए सही परियोजना को जोड़ने से यह हल हो जाएगा।

अपने समाधान में प्रत्येक परियोजना के संदर्भ अनुभाग की जाँच करें। यदि उनमें से किसी के पास लाल x के साथ संदर्भ है, तो यह आपको आपकी समस्या मिल गई है। उस विधानसभा संदर्भ को समाधान द्वारा नहीं पाया जा सकता है।

त्रुटि संदेश थोड़ा भ्रमित करने वाला है लेकिन मैंने इसे कई बार देखा है।

Comments

मेरे मामले में यह एक "पीली चेतावनी" थी

— AXMIM

Answer 3

यदि आप इस पर वाईएक्स लुक का उपयोग कर रहे हैं (एक बग है) http://www.cnblogs.com/xixifusigao/archive/2012/03/20/2407651.html

कभी-कभी नए बिल्ड कॉन्फ़िगरेशन .wixprojफ़ाइल के नीचे फ़ाइल में जुड़ जाते हैं , अर्थात, अन्य असंबंधित एक्सएमएल तत्वों द्वारा उनकी सिबलिंग कॉन्फिग परिभाषाओं से अलग कर दिया जाता है।

बस .wixprojफ़ाइल को संपादित करें ताकि <PropertyGroup>आपके बिल्ड कॉन्फ़िगरेशन को परिभाषित करने वाले सभी अनुभाग एक दूसरे से सटे हों। ( .wixprojसमाधान एक्सप्लोरर में परियोजना पर राइट क्लिक VS2013 में संपादित करने के लिए , अनलोड परियोजना, फिर से राइट-क्लिक करें-> YourProject.wixproj संपादित करें। फ़ाइल संपादित करने के बाद पुनः लोड करें।)

Comments

धन्यवाद, इसने मेरे लिए इसे ठीक कर दिया। मेरे पास परियोजना में जोड़े जाने वाले अधिक अजीब व्यवहार थे। जैसे ही मैंने प्रोजेक्ट फाइल को साफ किया सब कुछ ठीक हो गया। (यह बग पहली बार 2012 में रिपोर्ट किया गया था? महान ...)

— किर्शी

धन्यवाद, इसने इसे मेरे लिए भी तय कर दिया

— PeterD

Answer 4

यह मेरे साथ हुआ क्योंकि मैंने निम्न पंक्ति को .csproj फ़ाइल की शुरुआत के करीब ले जाया था:

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets"/>

यह आपके कॉन्फ़िगरेशन को परिभाषित करने वाले PropertyGroups के बाद रखा जाना चाहिए।

Answer 5

प्रोजेक्ट के लिए विज़ुअल स्टूडियो में दिखाई गई त्रुटि (मान लें कि A) में समस्याएँ नहीं हैं। जब मैंने प्रत्येक परियोजना के लिए लाइन द्वारा बिल्ड लाइन के लिए आउटपुट विंडो को देखा, तो मैंने देखा कि यह एक अन्य प्रोजेक्ट (बी) के बारे में शिकायत कर रहा था जिसे प्रोजेक्ट ए में असेंबली के रूप में संदर्भित किया गया था। प्रोजेक्ट बी को समाधान में जोड़ा गया। लेकिन इसे परियोजना ए के रूप में परियोजना संदर्भ के बजाय अलग-अलग स्थान से विधानसभा संदर्भ के रूप में संदर्भित नहीं किया गया था। उस स्थान में विधानसभा शामिल है जो प्लेटफ़ॉर्म AnyCpu के लिए संकलित है। तब मैंने प्रोजेक्ट A से असेंबली संदर्भ को हटा दिया और प्रोजेक्ट B को संदर्भ के रूप में जोड़ा। इसका संकलन शुरू हुआ। यकीन नहीं हो रहा है कि यह तय कैसे हुआ।

Comments

Deffo ने इसे \ p: Platform = "AnyCPU" के बजाय \ p: Platform = "Any CPU" के साथ आज़माया। वह रूप मेरे काम आया! युगों से यही देख रहा था!

— ली एन्ग्लस्टोन

AnyCPU (अंतरिक्ष के बिना) ने भी मेरे लिए काम किया। धन्यवाद ली।

— विलेम

TFS 2017 पर एक बिल्ड प्रक्रिया चलाते समय मुझे त्रुटि का सामना करना पड़ा, जब मैंने एक .sln से एक .vbproj में "समाधान या पैकेज के लिए पथ" परिवर्तित कर दिया। BuildPlatform को AnyCPU में बदलने से मेरे लिए भी काम हुआ। "प्लेटफ़ॉर्म" के तहत नोट यहाँ देखें: docs.microsoft.com/en-us/vsts/build-release/tasks/build/…

— Mr.Zzyzzx

मेरे मामले में, टीएफएस से बिल्ड लॉन्च करते समय, "any cpu"बिल्डप्ले रिकॉर्डर के लिए डिफ़ॉल्ट मूल्य था। "AnyCPU"समस्या को हल करने के लिए बदल रहा है।

— XouDo

यह 2020 है - AnyCPU बनाम एनी सीपीयू अभी भी एक मुसीबत निर्माता है। मैं VS2019 का उपयोग कर रहा हूं और अभी भी नई परियोजनाओं पर इसे प्राप्त कर रहा हूं। MS आप डेवलपर समुदाय को दंडित क्यों कर रहे हैं?

— ईसाई

Answer 6

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

यह संबंधित समाधान को खोलकर और इसके साथ नए कॉन्फ़िगरेशन को जोड़कर हल किया जा सकता है।

इस पोस्ट ने मुझे संदर्भित विधानसभाओं की जांच करने का विचार दिया, क्योंकि मैंने पहले ही पुष्टि कर दी थी कि मेरे समाधान की सभी परियोजनाओं में सही कॉन्फ़िगरेशन था:

http://gabrielmagana.com/2010/04/solution-to-the-outputpath-property-is-not-set-for-this-project/

Answer 7

इस समस्या का निर्माण Azure DevOps के आउटपुट के रूप में किया गया था। बिल्ड पाइपलाइन में .sln के बजाय .csproj बनाने के लिए सेट करने के बाद।

मेरे लिए समाधान: प्रभावित परियोजना के संपादन .csproj, फिर अपने पूरे की प्रतिलिपि बनाएँ

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCpu' ">

नोड, इसे पेस्ट करें, और उसके बाद पहली पंक्ति को बदलें:

    <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|any cpu' ">

कारण है, कि मेरे मामले में त्रुटि ने कहा

Please check to make sure that you have specified a valid combination of Configuration and Platform for this project.  Configuration='release'  Platform='any cpu'.  

क्यों Azure डिफ़ॉल्ट के बजाय "Any cpu" का उपयोग करना चाहता है "AnyCpu" मेरे लिए एक रहस्य है, लेकिन यह हैक काम करता है।

Comments

आपके विचार का अनुसरण करके मुझे पता चला कि मेरे मामले में मुझे परियोजना में बदलाव करने की आवश्यकता नहीं थी, लेकिन इसके बजाय DevOps में मेरे Visual Studio Build स्टेप में मैंने AnyCpu मान के साथ चर का उपयोग करने के लिए कन्फ़िगेशन फ़ील्ड सेट किया।

— donatasj87

@ donatasj87 क्या आप इस फ़ील्ड का पूरा मूल्य पोस्ट करना चाहेंगे?

— जय

पूर्ण मूल्य बिल्कुल समान है, यह टीएफएस बिल्ड में भी काम करना चाहिए। इसे केवल आपके .csproj फ़ाइल में सेट किए गए मान से मेल खाना चाहिए। आप इसे इस चित्र में देख सकते हैं: pasteboard.co/JbdvBT5.png

— donatasj87

Answer 8

मेरे पास एक ही त्रुटि थी, इसलिए मैंने परियोजना सेटिंग्स पर देखा और "बिल्ड" अनुभाग में "बिल्ड आउटपुट पथ" विकल्प है। और मान रिक्त था। तो मैं "बिन \" मूल्य में भर गया एक त्रुटि गायब हो गई। इसने मेरी समस्या हल कर दी।

Answer 9

मेरे पास है:

1. प्रॉजेक्ट पर राइट क्लिक करें -> अनलोड प्रोजेक्ट
2. प्रोजेक्ट पर राइट-क्लिक करें और Edit * .csproj चुनें

3. मौजूदा कॉन्फ़िगरेशन से कॉन्फ़िगरेशन को कॉपी-पेस्ट करें जो विशिष्ट नाम और लक्ष्यीकरण प्लेटफ़ॉर्म के साथ काम करता है (मेरे पास रिलीज़ था । x 64 )

   <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
     <OutputPath>bin\x64\Release\</OutputPath>
     <DefineConstants>TRACE</DefineConstants>
     <Optimize>true</Optimize>
     <DebugType>pdbonly</DebugType>
     <PlatformTarget>x64</PlatformTarget>
     <ErrorReport>prompt</ErrorReport>
     <CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
     <Prefer32Bit>true</Prefer32Bit>
   </PropertyGroup>

4. राइट-क्लिक प्रोजेक्ट -> रीलोड प्रोजेक्ट
5. परियोजना / समाधान का पुनर्निर्माण

Answer 10

यदि आपको यह त्रुटि तभी मिलती है जब आप MSBuild (मेरे मामले में) की तरह कमांडलाइन से अपने प्रोजेक्ट को संकलित करने का प्रयास करते हैं, तो समाधान आउटपुट तर्क के साथ MSBuild को मैन्युअल रूप से पास करना होता है जैसे तर्क /p:OutputPath=MyFolder।

Answer 11

एक और पागल संभावना: यदि आप ब्रांच \ मेन, मेन, और रिलीज को एक दूसरे के बगल में रखने के एक सरल स्रोत नियंत्रण व्यवस्था का पालन करते हैं और आप किसी तरह ब्रांच \ मेन के बजाय मेन से एक मौजूदा प्रोजेक्ट को जोड़ते हैं (यह मानते हुए कि आपका वर्किंग सोल्यूशन ब्रांच है) मुख्य), आप इस त्रुटि को देख सकते हैं।

समाधान सरल है: सही परियोजना का संदर्भ लें!

Answer 12

मुझे इस समस्या का सामना करना पड़ा जब एक परियोजना को एक समाधान में जोड़ा गया, फिर इसे उसी समाधान में एक और परियोजना से संदर्भित किया गया - संदर्भ पर पीला चेतावनी आइकन मिला, ध्यान दें कि पथ खाली था।

समाधान जैसा कि @Amzath ने सुझाव दिया था, मेरी परियोजनाओं को विभिन्न टारगेट फ्रेमवर्क के साथ संकलित किया जा रहा था, जैसे। .NET 4.0 बनाम 4.5।

Answer 13

मेरे मामले में मेरे ऐप का निर्मित पता किसी अन्य कंप्यूटर पर सेट किया गया था जिसे बंद कर दिया गया था, इसलिए मैंने इसे चालू किया और वीएस और समस्या को हल किया।

Answer 14

एक अन्य कारण: आप समाधान X में प्रोजेक्ट A से प्रोजेक्ट B में प्रोजेक्ट संदर्भ जोड़ते हैं। हालांकि, समाधान Y जिसमें पहले से ही प्रोजेक्ट A शामिल है, अब टूट चुका है, जब तक कि आप समाधान Y के लिए प्रोजेक्ट B भी नहीं जोड़ते।

Answer 15

नई कॉन्फ़िगरेशन को जोड़ने और "डीबग" और "रिलीज़" कॉन्फ़िगरेशन को हटाने के बाद मुझे एक ही समस्या थी। मेरे मामले में मैं बिल्ड और प्रकाशन प्रक्रिया को चलाने के लिए एक cmd फ़ाइल का उपयोग कर रहा था, लेकिन उसी त्रुटि को फेंक दिया गया। मेरे लिए समाधान: csproj फ़ाइल में निम्नलिखित हैं:

<Configuration Condition=" '$(Configuration)' == '' ">Debug< /Configuration>

यदि मैं स्पष्ट विवरण निर्दिष्ट नहीं करता, तो विन्यास को "डीबग" में सेट कर रहा था। "डिबग" से नोड मान को मेरे कस्टम कॉन्फ़िगरेशन में बदलने के बाद, यह सभी सुचारू रूप से काम करता है। आशा है कि यह भी मदद करेगा जो कोई भी इसे पढ़ रहा है :)

Comments

इस समाधान का विवरण इस मंच पोस्ट में दिया गया है। social.msdn.microsoft.com/Forums/vstudio/en-US/…

— सनी

Answer 16

मेरे पास एक ही समस्या थी, बस .wixproj को सभी <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... >तत्वों को एक साथ रखने के लिए संपादित करें ।

इससे मेरी समस्या हल हो गई

Answer 17

मेरे द्वारा उपयोग किया जा रहा वाईएक्स प्रोजेक्ट x64पूरे बोर्ड के लिए कॉन्फ़िगरेशन मैनेजर में हार्ड-सेट था । समाधान के लिए कस्टम एक्शन प्रोजेक्ट बनाते समय, उसने फ़ाइल के x86भीतर सब कुछ डिफ़ॉल्ट कर दिया .csproj। इसलिए मैं परियोजना उतार दिया, यह सब बदल रहा द्वारा संपादित x86करने के लिए x64, बचाया, पुनः लोड, और उसके बाद जाने के लिए अच्छा था।

मुझे समझ नहीं आता कि मुझे ऐसा क्यों करना पड़ा। कॉन्फ़िगरेशन प्रबंधक x64 के रूप में बनाने के लिए सेट किया गया था, लेकिन बस csprojफ़ाइल में सेट नहीं होगा :(

Answer 18

यहाँ पोस्ट किए गए अन्य सभी सुझावों को आज़माने के बाद, मुझे पता चला कि मेरे लिए इसका हल .csprojफ़ाइल से निम्न अनुभाग को निकालना था :

  <ItemGroup>
    <Service Include="{808359B6-6B82-4DF5-91FF-3FCBEEBAD811}" />
  </ItemGroup>

जाहिरा तौर पर मूल परियोजना (स्थानीय मशीन पर अनुपलब्ध) से यह सेवा पूरी निर्माण प्रक्रिया को रोक रही थी, हालांकि यह संकलन के लिए आवश्यक नहीं था।

Answer 19

मुझे अपनी परियोजना में एक नया मंच जोड़ने के बाद यह समस्या हुई। मेरे मामले में .csproj फ़ाइल Perforce स्रोत नियंत्रण में थी और केवल-पढ़ने के लिए थी। मैंने इसकी जाँच की, लेकिन जब तक मैंने इसे पुनः आरंभ नहीं किया, वीएस ने बदलाव को नहीं पकड़ा।

Answer 20

मेरे पास एक एक्समरीन प्रोजेक्ट पर इसी तरह का मुद्दा था। यह शायद दुर्लभ मामला है लेकिन मामले में किसी और के पास समस्या है। मेरी परियोजना संरचना नीचे की तरह थी

• xamarin.Android प्रोजेक्ट में xamarin.android.library प्रोजेक्ट का संदर्भ था।
• मैंने android.library प्रोजेक्ट के कुछ कोड का उपयोग करके एक प्लगइन बनाया।
• अब यहाँ समस्या है। यदि आप xamarin.android लाइब्रेरी प्रोजेक्ट पर प्रोजेक्ट संदर्भ या नगेट इंस्टॉलेशन जोड़ते हैं। आपको यह त्रुटि मिलेगी। डेवलपर्स मानते हैं कि कोड एंड्रॉइड.लिफ्ट्स प्रोजेक्ट के अंदर था और मुझे इस प्रोजेक्ट पर नए प्लगइन का संदर्भ देना चाहिए। नहीं!
• आपको मुख्य Android प्रोजेक्ट पर एक संदर्भ जोड़ना होगा। क्योंकि प्लगइन-> पुस्तकालय-> मुख्य परियोजना आउटपुट का उत्पादन नहीं किया जाता है।