अच्छा प्रश्न। आपकी विशिष्ट समस्या के लिए, ऐसा लगता है कि आपकी सुलझी हुई निर्भरता में आप बेमेल हैं। जब इस तरह की चीजें होती हैं, तो यह संभव है क्योंकि आप अपना आवेदन असंगत dnx पर चला रहे हैं। हम अभी भी बहुत बड़े ब्रेकिंग परिवर्तन कर रहे हैं ताकि यदि आप कभी भी टाइप मिसिंग के तरीके को गायब देखते हैं, तो संभावना है कि आप रनिंग betaXपैकेज और betaYdnx या वर्सा समाप्त कर रहे हैं।
और भी विशेष रूप से, असेंबली न्यूट्रल इंटरफेस को बीटा 4 में हटा दिया गया था लेकिन ऐसा लग रहा है कि आप जो एप्लिकेशन चला रहे हैं वह अभी भी उनका उपयोग कर रहा है।
हमारे पास इसे बनाने की योजना है ताकि पैकेज न्यूनतम डीएनएक्स को चिह्नित कर सकें जो उन्हें त्रुटि संदेश को अधिक स्पष्ट करने के लिए चलाने की आवश्यकता होती है। साथ ही जैसे-जैसे समय बीतता जाएगा, ब्रेकिंग परिवर्तन नीचे मर जाएंगे।
सामान्य तौर पर, मुझे ऐसा लगता है कि यह समय है जब मैंने dnx का उपयोग करते समय इस तरह के मुद्दों का निदान करने के बारे में एक गाइड लिखा था (क्योंकि यह मौजूदा .NET के लिए बहुत अलग है)।
आपके द्वारा लगाई गई निर्भरताएं project.jsonकेवल शीर्ष स्तर हैं। संस्करण भी हमेशा न्यूनतम होते हैं (यह एक NuGet पैकेज की तरह है)। इसका मतलब यह है कि जब आप निर्दिष्ट Foo 1.0.0-beta4करते हैं कि आप वास्तव में निर्दिष्ट कर रहे हैं Foo >= 1.0.0-beta4। इसका मतलब यह है कि यदि आप पूछते हैं MVC 0.0.1और आपके कॉन्फ़िगर किए गए फ़ीड पर न्यूनतम संस्करण हैं MVC 3.0.0, तो आपको वह मिल जाएगा। जब तक आप इसे निर्दिष्ट नहीं करते, हम भी आपके संस्करण को फ्लोट करते हैं। यदि आप 1.0.0 मांगते हैं और यह मौजूद है, तो आपको नया संस्करण मौजूद होने पर भी 1.0.0 मिलेगा। खाली संस्करणों को निर्दिष्ट करना हमेशा खराब होता है और बाद के बिल्ड में बंद हो जाएगा।
एक नई सुविधा है जिसे हम फ्लोटिंग संस्करण कहे जाने वाले नगेट से परिचित करा रहे हैं। आज यह केवल प्रीलेरेज टैग पर काम करता है, लेकिन अगले संस्करण में यह संस्करण के अधिक हिस्सों पर काम करेगा। यह पैकेज विनिर्देश फ़ाइल में संस्करण श्रेणियों को निर्दिष्ट करने के लिए npm और रत्न सिंटैक्स के समान है।
1.0.0-*- मीन्स मुझे प्रीफ़िक्स ( सिमेंटिक वर्जनिंग रूल्स के अनुसार) से मेल करने वाला हाईएस्ट वर्ज़न देते हैं या यदि उस प्रीफ़िक्स से मेल खाने वाला कोई वर्ज़न नहीं है, तो सामान्य व्यवहार का उपयोग करें और मुझे LOWEST वर्ज़न> = निर्दिष्ट वर्ज़न प्राप्त करें।
जब आप नवीनतम बिल्ड में पुनर्स्थापना चलाते हैं, तो यह एक फ़ाइल लिखेगा जिसे कहा जाता है project.lock.json। इस फ़ाइल में परिभाषित सभी लक्ष्य रूपरेखाओं के लिए निर्भरता का सकर्मक समापन होगा project.json।
जब ऐसा कुछ विफल होता है तो आप निम्नलिखित कार्य कर सकते हैं:
उपयोग किए गए निर्भरता पर एक नज़र डालें kpm list। यह आपको आपकी परियोजना द्वारा संदर्भित संकुल के हल किए गए संस्करण दिखाएगा और किस निर्भरता ने इसे अंदर खींच लिया है। उदाहरण के लिए यदि A -> B, तो यह हो जाएगा:
ए
-> बी
बी
->
वास्तविक KPM सूची आउटपुट:
ClassLibrary39 के लिए निर्भरता सूचीकरण (C: \ Users \ davifowl \ Documents \ Visual Studio 14 \ Projects \ ClassLibrary39 \ src \ ClassLibrary39 \ project.json)
[Target framework DNX,Version=v4.5.1 (dnx451)]
framework/Microsoft.CSharp 4.0.0.0
-> ClassLibrary39 1.0.0
framework/mscorlib 4.0.0.0
-> ClassLibrary39 1.0.0
framework/System 4.0.0.0
-> ClassLibrary39 1.0.0
framework/System.Core 4.0.0.0
-> ClassLibrary39 1.0.0
*Newtonsoft.Json 6.0.1
-> ClassLibrary39 1.0.0
[Target framework DNXCore,Version=v5.0 (dnxcore50)]
*Newtonsoft.Json 6.0.1
-> ClassLibrary39 1.0.0
System.Runtime 4.0.20-beta-22709
-> ClassLibrary39 1.0.0
* का अर्थ है प्रत्यक्ष निर्भरता।
यदि आपके पास एक कामकाजी दृश्य स्टूडियो है (जो अभी DNX के साथ टूटता है), तो आप संदर्भ नोड को देख सकते हैं। इसमें समान रूप से प्रतिनिधित्व किया गया डेटा है:
आइए देखें कि निर्भरता की विफलता कैसी दिखती है:
यहाँ प्रोजेक्ट है
{
"version": "1.0.0-*",
"dependencies": {
"Newtonsoft.Json": "8.0.0"
},
"frameworks" : {
"dnx451" : {
"dependencies": {
}
},
"dnxcore50" : {
"dependencies": {
"System.Runtime": "4.0.20-beta-22709"
}
}
}
}
Newtonsoft.Json 8.0.0मौजूद नहीं है। तो चल रहे kpm पुनर्स्थापना निम्न दिखाता है:
पुनर्स्थापना विफल होने पर निदान करते समय, किए गए HTTP अनुरोधों को देखें, वे आपको बताते हैं कि कॉन्फ़िगर किए गए पैकेज स्रोत kpm क्या देखते हैं। उपरोक्त छवि में देखें, एक CACHEअनुरोध है। यह संसाधन के प्रकार (nupkg या nuspec) के आधार पर कैशिंग में बनाया गया है और इसमें एक विन्यास योग्य TTL (देखो kpm restore --help) है। यदि आप kpmदूरस्थ NuGet स्रोतों को हिट करने के लिए बाध्य करना चाहते हैं, तो --no-cacheध्वज का उपयोग करें :
इन त्रुटियों को पैकेज मैनेजर लॉग आउटपुट विंडो में विजुअल स्टूडियो में भी दिखाया जाता है:
पक्षीय लेख!
पैकेज स्रोत
मैं अभी जिस तरह से NuGet.config काम करता हूं, उसका वर्णन करूंगा (जो भविष्य में परिवर्तन की संभावना होगी)। डिफ़ॉल्ट रूप से आपके पास एक NuGet.config है जिसके साथ डिफ़ॉल्ट NuGet.org स्रोत वैश्विक स्तर पर कॉन्फ़िगर किया गया है %appdata%\NuGet\NuGet.Config। आप इन वैश्विक स्रोतों को दृश्य स्टूडियो के भीतर या NuGet कमांड लाइन टूल के साथ प्रबंधित कर सकते हैं। विफलताओं का निदान करने का प्रयास करते समय आपको हमेशा अपने प्रभावी स्रोतों (kpm आउटपुट में सूचीबद्ध) को देखना चाहिए।
NuGet.config के बारे में अधिक यहाँ पढ़ें
वास्तविकता में वापस:
जब निर्भरता अनसुलझे होते हैं, तो एप्लिकेशन चलाना आपको यह देगा:
> dnx . run
System.InvalidOperationException: Failed to resolve the following dependencies for target framework 'DNX,Version=v4.5.1':
Newtonsoft.Json 8.0.0
Searched Locations:
C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\{name}\project.json
C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\test\{name}\project.json
C:\Users\davifowl\.dnx\packages\{name}\{version}\{name}.nuspec
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\{name}.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_32\{name}\{version}\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_64\{name}\{version}\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL\{name}\{version}\{name}.dll
Try running 'kpm restore'.
at Microsoft.Framework.Runtime.DefaultHost.GetEntryPoint(String applicationName)
at Microsoft.Framework.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)
at Microsoft.Framework.ApplicationHost.Program.Main(String[] args)
रनटाइम मूल रूप से यह सत्यापित करने का प्रयास करता है कि चलाने के लिए प्रयास करने से पहले संपूर्ण निर्भरता ग्राफ हल हो गया है। यदि यह सुझाव देता है kpm restoreकि यह चल रहा है क्योंकि यह सूचीबद्ध निर्भरताओं को नहीं पा सकता है।
एक और कारण है कि आपको यह त्रुटि मिल सकती है यदि आप गलत dnx स्वाद चला रहे हैं। यदि आपका आवेदन केवल dnx451 को निर्दिष्ट करता है और आप CoreCLR dnx को चलाने का प्रयास करते हैं, तो आपको एक समान समस्या दिखाई दे सकती है। त्रुटि संदेश में लक्ष्य ढांचे पर पूरा ध्यान दें:
दौड़ने के लिए:
dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}
जब आप दौड़ने की कोशिश कर रहे हों, तो आपको यह याद रखना चाहिए कि आपके द्वारा परिभाषित फ्रेमवर्क से लेकर लक्ष्य तक मानसिक मानचित्रण project.json।
यह भी संदर्भ नोड के तहत विजुअल स्टूडियो में दिखाई देता है:
पीले रंग के रूप में चिह्नित नोड अनसुलझे हैं।
ये त्रुटि सूची में भी दिखाई देते हैं:
इमारत
ये त्रुटियां भी निर्माण करते समय दिखाई देती हैं। कमांड लाइन से निर्माण करते समय, आउटपुट बहुत ही क्रियात्मक होता है और समस्याओं का निदान करते समय यह बेहद उपयोगी हो सकता है:
> kpm build
Building ClassLibrary39 for DNX,Version=v4.5.1
Using Project dependency ClassLibrary39 1.0.0
Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json
Using Assembly dependency framework/mscorlib 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\mscorlib.dll
Using Assembly dependency framework/System 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.dll
Using Assembly dependency framework/System.Core 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.Core.dll
Using Assembly dependency framework/Microsoft.CSharp 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Microsoft.CSharp.dll
Building ClassLibrary39 for DNXCore,Version=v5.0
Using Project dependency ClassLibrary39 1.0.0
Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json
Using Package dependency System.Console 4.0.0-beta-22709
Source: C:\Users\davifowl\.dnx\packages\System.Console\4.0.0-beta-22709
File: lib\contract\System.Console.dll
Using Package dependency System.IO 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.IO\4.0.10-beta-22231
File: lib\contract\System.IO.dll
Using Package dependency System.Runtime 4.0.20-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Runtime\4.0.20-beta-22231
File: lib\contract\System.Runtime.dll
Using Package dependency System.Text.Encoding 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Text.Encoding\4.0.10-beta-22231
File: lib\contract\System.Text.Encoding.dll
Using Package dependency System.Threading.Tasks 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Threading.Tasks\4.0.10-beta-22231
File: lib\contract\System.Threading.Tasks.dll
आउटपुट संकुल और परियोजना संदर्भों से संकलक में पारित सभी विधानसभाओं को दर्शाता है। जब आप बिल्ड विफलताओं को प्राप्त करना शुरू करते हैं, तो यह सुनिश्चित करना उपयोगी है कि आप जिस पैकेज का उपयोग कर रहे हैं, वह वास्तव में उस लक्ष्य प्लेटफॉर्म पर काम करता है।
यहां एक पैकेज का उदाहरण दिया गया है जो dnxcore50 पर काम नहीं करता है:
{
"version": "1.0.0-*",
"dependencies": {
"Microsoft.Owin.Host.SystemWeb": "3.0.0"
},
"frameworks": {
"dnx451": {
"dependencies": {
}
},
"dnxcore50": {
"dependencies": {
"System.Console": "4.0.0-beta-22709"
}
}
}
}
Microsoft.Owin.Host.SystemWeb संस्करण 3.0.0 में ऐसी कोई असेंबली नहीं है जो dnxcore50 पर चलती है (अनज़िप्ड पैकेज के लीबर फ़ोल्डर पर नज़र डालें)। जब हम चलाते हैं kpm build:
ध्यान दें कि यह "पैकेज Microsoft.win.Host.SystemWeb का उपयोग करता है" लेकिन "फ़ाइल:" नहीं है। यह एक बिल्ड विफलता का कारण हो सकता है।
यहाँ मेरा दिमाग ख़त्म हो जाता है