डिपेंडेंट DLL को Visual Studio में निर्मित आउटपुट फ़ोल्डर में कॉपी नहीं किया जा रहा है


185

मेरे पास एक दृश्य स्टूडियो समाधान है। मेरे पास समाधान में कई परियोजनाएं हैं। एक मुख्य परियोजना है जो स्टार्ट अप के रूप में कार्य करती है और अन्य परियोजनाओं का उपयोग करती है। एक प्रोजेक्ट है "प्रोजेक्टएक्स"। इसका संदर्भ मुख्य परियोजना में जोड़ा गया है। ProjectX एक अन्य .NET dll (abc.dll कहते हैं) का संदर्भ देता है जो समाधान का हिस्सा नहीं है।

अब इस abc.dll को मुख्य परियोजना के बिन / डीबग फ़ोल्डर में कॉपी किया जाना चाहिए, लेकिन यह वहां कॉपी नहीं हो रहा है। इसकी नकल क्यों नहीं हो रही है, कोई ज्ञात कारण?


यदि आप इसका पता नहीं लगा सकते हैं तो इसे अपने प्रीबिल्ट में कॉपी कर लें।
दिलशोड़

आप मुख्य परियोजना में अपने 'प्रोजेक्टएक्स' का उपयोग कैसे करते हैं - परियोजना का प्रकार, लक्ष्य आदि क्या है
एनएसगागा-ज्यादातर-निष्क्रिय

मेरे पास एक ही मुद्दा था और इस जवाब ने मेरी समस्या हल कर दी: stackoverflow.com/a/8213977/174469
गॉर्डन टकर


वहाँ RestoreProjectStyle समाधान उपलब्ध है<RestoreProjectStyle>PackageReference</RestoreProjectStyle>समाधान में प्रत्येक .Net फ्रेमवर्क परियोजना के लिए विचार करना है ।
oleksa

जवाबों:


105

मैंने पाया कि अगर ProjectX ने abc.dll को संदर्भित किया है, लेकिन abc.dll में किसी भी प्रकार का सीधे उपयोग नहीं किया है, तो abc.dll को मुख्य आउटपुट फ़ोल्डर में कॉपी नहीं किया जाएगा। (यह प्रोजेक्टएक्स आउटपुट फ़ोल्डर में कॉपी किया जाएगा, इसे अतिरिक्त-भ्रमित करने के लिए।)

तो, अगर आप स्पष्ट रूप से ProjectX में कहीं भी abc.dll से किसी भी प्रकार का उपयोग नहीं कर रहे हैं, तो ProjectX में फ़ाइलों में से एक में कहीं भी एक डमी घोषणा करें।

AbcDll.AnyClass dummy006; // this will be enough to cause the DLL to be copied

आपको हर वर्ग के लिए ऐसा करने की आवश्यकता नहीं है - बस एक बार DLL की प्रतिलिपि बनाने के लिए पर्याप्त होगा और सब कुछ अपेक्षित रूप से काम करेगा।

परिशिष्ट: ध्यान दें कि यह डिबग मोड के लिए काम कर सकता है, लेकिन रिलीज के लिए नहीं। विवरण के लिए @ nvirth का उत्तर देखें।


7
यह एक हैक की तरह लगता है। मुख्य परियोजना के संदर्भ को जोड़ना पर्याप्त प्रतीत होता है।
माइक के

3
यह एक हैक है, लेकिन जैसा कि आज के CodeProject समाचार ने हमें सिखाया है, यहां तक ​​कि संकलक भी गलत हो सकते हैं!
ओवरलॉर्ड ज़र्ग

4
पागल कैसे हो सकते हैं। @OverlordZurg ने आपके समाधान के रूप में काम किया क्योंकि मेरे पास मेरे XAML (WPF) में आश्रित dll का संदर्भ था और यह मुख्य परियोजना में DLL की नकल नहीं करता था जब तक कि मैंने एक साधारण डमी संदर्भ नहीं जोड़ा जैसा कि आपने बताया ... धन्यवाद वैसे भी
मोहम्मद अफशीन

5
@MohsenAfshin मेरे पास एक ही मुद्दा था --- मैं XAML में एक निर्भर DLL का उल्लेख कर रहा था। एक डमी चर घोषित करने के बजाय, हालांकि, मैंने बस उस घटक का नाम दिया जिसका मैं एक्सएएमएल में उपयोग कर रहा था, और जो कि इसकी विधानसभा को कॉपी करने के लिए पर्याप्त था।
redcurry

5
@ मायके इसे मुख्य परियोजना में जोड़ रहा है (जो वास्तव में सीधे इस पर निर्भर नहीं करता है) एक और भी बड़ा हैक है, इमो। फिर आपको इसे दो स्थानों ("प्रबंधन" के रूप में उन्नयन या हटाने में) का प्रबंधन करना होगा। इस हैक के साथ , कम से कम आपको एक अच्छा संकलन समय त्रुटि मिलती है, जो आपको निर्भरता को हटाते समय इस हैक को हटाने की याद दिलाती है, और आपको अभी भी इसे एक स्थान पर अपडेट करने की आवश्यकता है।
jpmc26

70

ओवरडर्ड ज़र्ग के जवाब के लिए सिर्फ एक सनद रहे।

मैंने इस तरह डमी संदर्भ जोड़ा है, और इसने डिबग मोड में काम किया है:

public class DummyClass
{
    private static void Dummy()
    {
        var dummy = typeof(AbcDll.AnyClass);
    }
}

लेकिन रिलीज़ मोड में, आश्रित dll अभी भी कॉपी नहीं किया गया था।
हालांकि यह काम किया:

public class DummyClass
{
    private static void Dummy()
    {
        Action<Type> noop = _ => {};
        var dummy = typeof(AbcDll.AnyClass);
        noop(dummy);
    }
}

यह जानकारी वास्तव में मुझे पता लगाने में घंटों की लागत आई, इसलिए मैंने सोचा कि मैं इसे साझा करता हूं।


6
रिलीज़ मोड में, ऑप्टिमाइज़र यह मानता है कि "डमी" का उपयोग नहीं किया जाता है इसलिए यह लाइन अनावश्यक है और इसे हटा दिया जाना चाहिए। लेकिन जब आप कोड में "डमी" का उपयोग करते हैं, तो ऑप्टिमाइज़र इसमें अनावश्यक नहीं लगता है।
Yucel

1
इस me.AbcDll.AnyClass के लिए काम नहीं करता है अभी भी अन्य परियोजना में प्रतिलिपि नहीं है
मैथ्यू लॉक

3
सुनिश्चित करें कि AbcDll.AnyClassसार्वजनिक क्षेत्र या सार्वजनिक वर्ग पर संपत्ति के रूप में उपयोग किया जाता है, फिर यह काम करेगा। यदि आप इसे एक विधि निकाय में उपयोग करते हैं तो यह कंपाइलर इसे नहीं देखता है । यह इस असेंबली को लोड करने में विलंब करेगा, न कि आप जो होना चाहते हैं।
जॉन लेदरग्रेन

52

हां, आपको सेट Copy Localकरना होगा true। हालाँकि, मुझे पूरा यकीन है कि आपको उस प्रोजेक्ट को मुख्य प्रोजेक्ट से भी संदर्भित करना होगा और साथ ही सेट Copy Localकरना होगा true- यह सिर्फ एक निर्भर विधानसभा से कॉपी नहीं किया जाता है।

आप Copy Localविधानसभा के नीचे क्लिक करके Referencesऔर F4 दबाकर संपत्ति प्राप्त कर सकते हैं ।


2
@ बृज, क्या विधानसभा उस मुख्य परियोजना से संदर्भित है जिसे आप चाहते हैं? जैसा कि मैंने कहा, मुझे पूरा यकीन है कि आपको उस परियोजना से भी संदर्भ लेने की आवश्यकता है - निर्भर विधानसभाओं को उस तरह से कॉपी नहीं किया जाता है। यदि ऐसा होता तो आपको NuGet का उपयोग करते समय सभी संबंधित परियोजनाओं में विधानसभाओं को जोड़ने की आवश्यकता नहीं होती।
माइक पेरेनॉउड

1
यहाँ निष्कर्ष क्या था? यह मुझे लगता है कि आप सही हैं - निर्भर संदर्भों की प्रतिलिपि नहीं बनाई जाती है भले ही CopyLocal सच पर सेट हो - इसके पीछे तर्क क्या है?
mcmillab

29
छोटे दृश्य स्टूडियो में @ mcmillab, अन्य आश्रित परियोजनाओं से निर्भरता का अनुमान नहीं लगाता है । यदि प्रोजेक्ट A संदर्भ प्रोजेक्ट B है, तो प्रोजेक्ट A को प्रोजेक्ट B के सभी संदर्भों की आवश्यकता होगी। यह अच्छी तरह से काम करता है जब सभी प्रोजेक्ट B की जरूरत .NET असेंबली होती है, लेकिन अगर यह एक 3 पार्टी असेंबली है तो आपको दोनों प्रोजेक्ट का संदर्भ जोड़ना होगा।
माइक पेर्रेनौड

12
@MichaelPerrenoud मुझे नहीं लगता कि यह सच है। यदि आप एक विस्तृत MSBuild आउटपुट को देखते हैं, तो आप ResolveAssemblyReference पर कॉल देखेंगे जो बताता है कि "इसमें दूसरा और nth- ऑर्डर निर्भरता शामिल है"। यह मेरे बिन फ़ोल्डर्स (एन-वें निर्भरता की प्रतिलिपि बनाई गई) में मुझे जो दिखता है, उसके साथ भी सहमति देता है। मुद्दा यह है कि नकल के बारे में कुछ कैविएट हैं, ज्यादातर जीएसी और अप्रत्यक्ष संदर्भों के आसपास हैं (संदर्भ कभी-कभी पर्याप्त नहीं है)
जैक उकलेजा

2
मेरा वर्तमान अनुभव यह है कि यह 'कॉपी' निर्भरता को छोड़कर काम करेगा : प्रोजेक्ट A.net बाह्य C ++ dlls को फाइलों के रूप में संदर्भित करता है जो 'हमेशा कॉपी' होते हैं। प्रोजेक्ट B.net संदर्भ प्रोजेक्ट A. बिल्ड पर, B / डीबग में C ++ dll शामिल हैं। हालाँकि, जब मैं अनुप्रयोग X का निर्माण करता हूं, जो प्रोजेक्ट B को संदर्भित करता है, तो C ++ dlls कभी-कभी कॉपी हो जाता है (लगता है कि मैं केवल एक पुनर्निर्माण करता हूं)।
बेंजॉल

33

जब आप इसे असेंबली विशेषता बनाते हैं, तो यह धीमा दिखता है

[AttributeUsage(AttributeTargets.Assembly)]
public class ForceAssemblyReference: Attribute
{        
    public ForceAssemblyReference(Type forcedType)
    {
        //not sure if these two lines are required since 
        //the type is passed to constructor as parameter, 
        //thus effectively being used
        Action<Type> noop = _ => { };
        noop(forcedType);
    }
}

उपयोग होगा:

[assembly: ForceAssemblyReference(typeof(AbcDll.AnyClass))]

धन्यवाद, लेकिन मेरे लिए यह केवल कुछ करता है जब मैं विधानसभा विशेषता को निर्भरता (प्रोजेक्ट एक्स) में जोड़ता हूं, जो पहले से ही एबीसीडेल.एनीक्लास का संदर्भ देता है। और फिर, यह सामान्य रूप से अधिक नहीं करता है, जहां यह एबीसीडीएल पर निर्भरता के आउटपुट निर्देशिका को कॉपी करता है। यह अभी भी इसे मुख्य आश्रित परियोजना के आउटपुट पर कॉपी नहीं करता है। और जब तक मैं AbcDll का संदर्भ भी नहीं जोड़ता तब तक मैं निर्भर असेंबली में विशेषता नहीं जोड़ सकता। जब मैं ऐसा करता हूं, AbcDll पहले से ही विशेषता के बिना कॉपी हो जाता है।
जेएस

25

इसी मुद्दे में भाग गया। पृष्ठभूमि की जानकारी: निर्माण से पहले, मैंने समाधान के लिए एक नया प्रोजेक्ट एक्स जोड़ा था। प्रोजेक्ट Y प्रोजेक्ट X पर निर्भर प्रोजेक्ट X और प्रोजेक्ट A, B, C पर निर्भर करता है।

बिल्ड त्रुटियाँ यह थीं कि प्रोजेक्ट A, B, C, Y और X dll नहीं मिल सके।

मूल कारण यह था कि नव निर्मित प्रोजेक्ट X ने .NET 4.5 को लक्षित किया जबकि शेष समाधान परियोजनाओं ने .NET 4.5.1 को लक्षित किया। प्रोजेक्ट X का निर्माण बाकी परियोजनाओं के कारण नहीं हुआ।

सुनिश्चित करें कि कोई भी नया जोड़ा गया प्रोजेक्ट शेष समाधान के समान .NET संस्करण को लक्षित करता है।


1
संदर्भित प्रोजेक्ट .NET का पुराना संस्करण हो सकता है। मैं .NET 4.5 के लिए बनाई गई परियोजना द्वारा .NET 4 के लिए बनाई गई परियोजना का संदर्भ देने में सक्षम हूं।
redcurry'

18

यकीन नहीं होता कि यह मदद करता है लेकिन मेरे लिए, कई बार मैं एक डीएलएल का संदर्भ देता हूं (जो स्वचालित रूप से इसे बिन फ़ोल्डर में जोड़ता है)। हालाँकि, DLL को अतिरिक्त DLL की आवश्यकता हो सकती है (यह इस बात पर निर्भर करता है कि मैं किन कार्यों का उपयोग कर रहा हूँ)। मैं अपने प्रोजेक्ट में उन लोगों को संदर्भित नहीं करना चाहता, क्योंकि उन्हें बस उसी फ़ोल्डर में समाप्त होने की आवश्यकता है जिस तरह DLL मैं वास्तव में उपयोग कर रहा हूं।

मैं इसे "एक मौजूदा फ़ाइल जोड़ना" द्वारा विज़ुअल स्टूडियो में पूरा करता हूं। आपको Add_data फ़ोल्डर को छोड़कर कहीं भी इसे जोड़ने में सक्षम होना चाहिए। व्यक्तिगत रूप से मैं इसे मूल में जोड़ता हूं।

फिर उस फ़ाइल के गुणों में परिवर्तन करें ...

बिल्ड एक्शन = कोई नहीं (इस सेट को कुछ इस तरह से सेट करना कि वास्तव में "रूट" संस्करण रूट पर कॉपी हो जाए, साथ ही बिन में एक कॉपी)।

आउटपुट फ़ोल्डर में कॉपी करें = कॉपी करें यदि नया (मूल रूप से इसे BIN फ़ोल्डर में रखता है केवल अगर यह गायब है, लेकिन इसके बाद ऐसा नहीं करता है)

जब मैं प्रकाशित करता हूं .. तो मेरा जोड़ा गया DLL केवल BIN फ़ोल्डर में मौजूद है और कहीं और प्रकाशित स्थान (जो मुझे चाहिए) में है।


10

आप यह सुनिश्चित करने के लिए भी जाँच कर सकते हैं कि आप जिस DLL को देख रहे हैं वह GAC में शामिल नहीं है। मेरा मानना ​​है कि विज़ुअल स्टूडियो उन फ़ाइलों को कॉपी नहीं करने के बारे में स्मार्ट हो रहा है अगर यह पहले से ही जीएसी में मशीन पर मौजूद है।

मैं हाल ही में इस स्थिति में भाग गया था जहां मैं एक SSIS पैकेज का परीक्षण कर रहा था जिसे GAC में मौजूद होने के लिए असेंबली की आवश्यकता थी। मैं तब से भूल गया था और सोच रहा था कि एक निर्माण के दौरान उन DLL क्यों नहीं निकल रहे थे।

यह देखने के लिए कि GAC में क्या है (एक विजुअल स्टूडियो डेवलपर कमांड प्रॉम्प्ट से):

gacutil -l

या फ़ाइल को पढ़ने के लिए आसान बनाने के लिए आउटपुट:

gacutil -l > output.txt
notepad.exe output.txt

एक विधानसभा को हटाने के लिए:

gacutil -u MyProjectAssemblyName

मुझे यह भी ध्यान देना चाहिए, कि एक बार जब मैंने जीएसी से फाइलें हटा दीं तो वे एक निर्माण के बाद \ बिन निर्देशिका में सही ढंग से आउटपुट थे (यहां तक ​​कि विधानसभाओं के लिए जो सीधे रूट प्रोजेक्ट में संदर्भित नहीं थे)। यह विजुअल स्टूडियो 2013 अपडेट 5 पर था।


धन्यवाद, आप सही हैं, MSBuild आउटपुट फ़ोल्डर में dll की नकल नहीं करेगा यदि यह उन्हें GAC में मिला।
जॉन-फिलिप

3

मेरे मामले में, यह सबसे मूर्खतापूर्ण बात थी, जो कि टीएफएस / वीएस के एक डिफ़ॉल्ट व्यवहार के कारण था जिससे मैं असहमत हूं।

चूंकि dll को मुख्य परियोजना के संदर्भ के रूप में जोड़ने से काम नहीं चला, इसलिए मैंने इसे "मौजूदा वस्तु" के रूप में जोड़ने का फैसला किया, कॉपी लोकल = ऑलवेज के साथ। तब भी फाइल वहां नहीं थी।

यह बताता है कि भले ही फ़ाइल वीएस सॉल्यूशन पर मौजूद हो और सब कुछ स्थानीय और सर्वर पर संकलित हो, लेकिन वीएस / टीएफएस ने वास्तव में फाइल को सोर्स कंट्रोल में नहीं जोड़ा। यह "लंबित परिवर्तन" पर बिल्कुल भी शामिल नहीं था। मुझे मैन्युअल रूप से सोर्स कंट्रोल एक्सप्लोरर में जाना था और स्पष्ट रूप से "फ़ोल्डर में आइटम जोड़ें" आइकन पर क्लिक करें।

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

मुझे आशा है कि यह किसी को कुछ समय बचाता है, क्योंकि मैंने अपने जीवन के 2 दिन इसे खो दिया है।


1
मैं आपको पर्याप्त धन्यवाद नहीं दे सकता ... आपने मुझे इतना समय बचा लिया। यह मेरे लिए समाधान था। इसने मूल समस्या को भी उजागर किया, DLL I को एक संदर्भ के रूप में जोड़ा गया एक gitignoreपैटर्न से मेल खाता है , इसलिए जब एक संदर्भ के रूप में इसे परियोजना में नहीं जोड़ा गया। आप मैन्युअल रूप से स्रोत नियंत्रण में फ़ाइल जोड़ना होगा !!!
मटकिविश

2

यह nvirth के उदाहरण पर एक मामूली ट्विक है

internal class DummyClass
{
    private static void Dummy()
    {
        Noop(typeof(AbcDll.AnyClass));
    }
    private static void Noop(Type _) { }
}

2

मैं इसे उत्पादन निर्देशिकाओं के लिए आवश्यक पुस्तकालयों की प्रतिलिपि बनाने के लिए घटनाओं के पुनर्निर्माण के लिए जोड़ूंगा। XCopy pathtolbooks targetdirectory की तरह कुछ

आप उन्हें प्रोजेक्ट प्रॉपर्टीज़ -> बिल्ड इवेंट्स पर पा सकते हैं।


इसने मेरे लिए काम किया, और मुझे लगता है कि यह बेहतर उत्तर है। डमी संदर्भ समाधान काम करता है, लेकिन यह एक हैक है, जबकि पोस्ट-बिल्ड नियम एक ही परिणाम को पूरा करने का एक साफ तरीका है।
केविन फिशर

2

मुद्दा:

एक NuGet पैकेज DLL (Newtonsoft.json.dll) के लिए एक समान समस्या से सामना करना पड़ता है, जहां बिल्ड आउटपुट संदर्भित DLL को शामिल नहीं करता है। लेकिन संकलन ठीक हो जाता है।

ठीक कर:

एक पाठ संपादक में अपनी परियोजनाओं के माध्यम से जाओ और उनमें टैग के साथ संदर्भ देखें। सत्य या असत्य की तरह। "निजी" "स्थानीय कॉपी करें" का एक पर्याय है। कहीं क्रियाओं में, MSBuild निर्भरता का पता लगाने के लिए ले जा रहा है, यह कहीं और आपकी निर्भरता का पता लगा रहा है और इसे कॉपी नहीं करने का निर्णय ले रहा है।

इसलिए, प्रत्येक .csproj / .vbproj फ़ाइल पर जाएं और मैन्युअल रूप से टैग हटा दें। Visual Studio और MSBuild दोनों में पुनर्निर्माण, और सब कुछ काम करता है। एक बार जब आपको वह काम मिल गया, तो आप वापस अंदर जा सकते हैं और अपडेट कर सकते हैं कि जहां आपको लगता है कि उन्हें होना चाहिए।

संदर्भ:

https://www.paraesthesia.com/archive/2008/02/13/what-to-do-if-copy-local-works-in-vs-but.aspx/


1

कोड में डमी के लिए कोई आवश्यकता नहीं है
:

निष्पादन योग्य परियोजना के लिए एक संदर्भ जोड़ें

या / और सुनिश्चित करें कि निष्पादन योग्य परियोजना में संदर्भ (जो मेरी " गलती " थी) के "Copy Local"लिए सेट TRUEकिया गया है, ऐसा लगता है कि इस " संदर्भित " ने आधार को संदर्भित पुस्तकालय-परियोजना में स्थापित कर दिया ...


1

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

यहां छवि विवरण दर्ज करें


1
कॉपी Loal विकलांग था, इस मदद की stackoverflow.com/questions/15526491/...
CodeMirror

1

TLDR; विजुअल स्टूडियो 2019 को बस पुनः आरंभ की आवश्यकता हो सकती है।

मैंने Microsoft.NET.Sdk प्रोजेक्ट पर आधारित परियोजनाओं का उपयोग करके इस स्थिति का सामना किया।

<Project Sdk="Microsoft.NET.Sdk">

विशेष रूप से:

  • Project1: लक्ष्य .netstandard2.1
    • Microsoft.Extensions.Logging.ConsoleNuget के माध्यम से संदर्भ
  • Project2: लक्ष्य .netstandard2.1
    • Project1एक परियोजना के संदर्भ के माध्यम से संदर्भ
  • Project2Tests: लक्ष्य .netcoreapp3.1
    • Project2एक परियोजना के संदर्भ के माध्यम से संदर्भ

परीक्षण के निष्पादन में, मुझे त्रुटि संदेश प्राप्त हुआ जो यह दर्शाता है कि Microsoft.Extensions.Logging.Consoleनहीं मिल सकता है, और यह वास्तव में आउटपुट निर्देशिका में नहीं था ।

मैं जोड़कर समस्या के समाधान करने का निर्णय लिया Microsoft.Extensions.Logging.Consoleकरने के लिए Project2, केवल यह है कि दृश्य स्टूडियो के Nuget प्रबंधक सूची नहीं था की खोज करने Microsoft.Extensions.Logging.Consoleके रूप में में स्थापित Project1, में यह की उपस्थिति के बावजूद Project1.csprojफ़ाइल।

विज़ुअल स्टूडियो के एक साधारण शट डाउन और पुनरारंभ ने अतिरिक्त संदर्भ जोड़ने की आवश्यकता के बिना समस्या को हल किया। शायद यह किसी को 45 मिनट की उत्पादकता खो देगा :-)


वास्तव में मैंने अपने पीसी को चीजों के परीक्षण के तरीके पर फिर से शुरू किया लेकिन यह मेरे लिए काम किया
Noman_1

0

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


0

सुनिश्चित करें कि आपके द्वारा उपयोग किए गए निर्भर dll में लक्ष्य नहीं है। आपके प्रोजेक्ट के अनुप्रयोग के .net फ्रेमवर्क की तुलना में अधिक .net ढांचा।

आप अपनी परियोजना का चयन करके इसकी जांच कर सकते हैं, फिर ALT + ENTER दबाएं, फिर बाईं ओर से एप्लिकेशन का चयन करें और फिर अपनी परियोजना के लक्ष्य फ्रेमवर्क का चयन करें।

मान लीजिए, निर्भर dll लक्ष्य ढाँचा = 4.0 और अनुप्रयोग dll लक्ष्य ढाँचा = 3.5 तो इसे 4.0 में बदल दें

धन्यवाद!


0

ऊपर आम लोगों के अलावा, मेरे पास प्रकाशित करने के लिए एक बहु-परियोजना समाधान था। जाहिरा तौर पर कुछ फाइलें विभिन्न चौखटों को लक्षित करती हैं।

तो मेरा समाधान: गुण> विशिष्ट संस्करण (गलत)


0

किसी एक प्रोजेक्ट में DLL को मौजूदा आइटम के रूप में जोड़ें और इसे सॉर्ट किया जाना चाहिए

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.