Buona domanda. Per il tuo problema specifico, sembra che tu abbia una discrepanza nelle dipendenze risolte. Quando accadono cose del genere, è probabile che tu stia eseguendo la tua applicazione su un dnx incompatibile. Stiamo ancora apportando modifiche sostanziali, quindi se noti che manca il metodo di tipo mancante, è probabile che tu abbia finito con l'esecuzione di betaXpacchetti e betaYdnx o viceversa.
Ancor più specificamente, le interfacce neutre di Assembly sono state rimosse in beta4 ma sembra che l'applicazione in esecuzione le stia ancora utilizzando.
Abbiamo in programma di farlo in modo che i pacchetti possano contrassegnare il minimo dnx che devono eseguire per rendere più chiaro il messaggio di errore. Anche col passare del tempo, i cambiamenti di rottura moriranno.
In generale, però, mi sento come se fosse il momento di scrivere una guida su come diagnosticare problemi come questo quando si utilizza il dnx (poiché è piuttosto diverso da .NET esistente).
Le dipendenze che inserisci project.jsonsono solo di livello superiore. Le versioni sono anche sempre minime (è proprio come un pacchetto NuGet). Questo significa che quando specifichi Foo 1.0.0-beta4che stai davvero specificando Foo >= 1.0.0-beta4. Questo significa che se lo chiedi MVC 0.0.1e la versione minima del tuo feed configurato è MVC 3.0.0, otterrai quella. Inoltre, non galleggiamo MAI la tua versione, a meno che non la specifichi. Se si richiede 1.0.0 ed esiste, si otterrà 1.0.0 anche se esistono versioni più recenti. La specifica di versioni vuote è SEMPRE negativa e non sarà consentita nelle build successive.
C'è una nuova funzionalità che stiamo introducendo in nuget chiamata versioni mobili. Oggi funziona solo con il tag pre-release, ma nella prossima versione funzionerà su più parti della versione. Questo è simile alla sintassi npm e gem per specificare gli intervalli di versioni nel file delle specifiche del pacchetto.
1.0.0-*- Significa che mi dà la versione PIÙ ALTA corrispondente al prefisso (in base alle regole semantiche di versioning ) OPPURE se non esiste una versione corrispondente a quel prefisso, usa il comportamento normale e procurami la versione PIÙ BASSA> = la versione specificata.
Quando esegui il ripristino nelle ultime build, verrà scritto un file chiamato project.lock.json. Questo file avrà la chiusura transitiva delle dipendenze per tutti i framework di destinazione definiti in project.json.
Quando qualcosa del genere fallisce puoi fare quanto segue:
Dai un'occhiata alle dipendenze risolte usando kpm list . Questo ti mostrerà le versioni risolte dei pacchetti a cui fa riferimento il tuo progetto e quale dipendenza lo ha attirato. Ad esempio, se A -> B, mostrerà:
UN
-> B
B
->
Output effettivo dell'elenco KPM:
Elenco delle dipendenze per 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
* significa dipendenza diretta.
Se hai uno studio visivo funzionante (che al momento non funziona con DNX), puoi guardare il nodo riferimenti. Ha gli stessi dati rappresentati visivamente:
Diamo un'occhiata a come appare un errore di dipendenza:
Ecco il project.json
{
"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.0non esiste. Quindi l'esecuzione di kpm restore mostra quanto segue:
Quando si diagnostica quando il ripristino potrebbe non essere riuscito, guardare le richieste HTTP effettuate, ti dicono quali sono le fonti del pacchetto configurato kpm. Nota nell'immagine sopra, c'è una CACHErichiesta. Questa è la cache integrata basata sul tipo di risorsa (nupkg o nuspec) e ha un TTL configurabile (vedi kpm restore --help). Se vuoi forzare kpma colpire le sorgenti NuGet remote, usa il --no-cacheflag:
Questi errori compaiono anche in Visual Studio nella finestra di output del registro del gestore pacchetti:
Nota a margine!
Fonti del pacchetto
Descriverò come funziona NuGet.config in questo momento (che probabilmente cambierà in futuro). Per impostazione predefinita, hai un NuGet.config con l'origine NuGet.org predefinita configurata globalmente in%appdata%\NuGet\NuGet.Config . È possibile gestire queste fonti globali in Visual Studio o con lo strumento da riga di comando NuGet. Dovresti sempre guardare alle tue fonti efficaci (quelle elencate nell'output di kpm) quando provi a diagnosticare i guasti.
Maggiori informazioni su NuGet.config qui
Torna alla realtà:
Quando le dipendenze sono irrisolte, l'esecuzione dell'applicazione ti darà questo:
> 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)
Il runtime fondamentalmente tenta di convalidare che l'intero grafico delle dipendenze è stato risolto prima di tentare l'esecuzione. Se suggerisce l'esecuzione kpm restoreè perché non riesce a trovare le dipendenze elencate.
Un altro motivo per cui potresti ricevere questo errore è se stai eseguendo il sapore dnx sbagliato. Se l'applicazione specifica solo dnx451 e si tenta di eseguire CoreCLR dnx, è possibile che si verifichi un problema simile. Prestare molta attenzione al framework di destinazione nel messaggio di errore:
Per correre:
dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}
Quando stai cercando di eseguire, dovresti ricordare quella mappatura mentale da clr a framework di destinazione definita nel tuo project.json.
Questo appare anche in Visual Studio sotto il nodo riferimenti:
I nodi contrassegnati come gialli non sono risolti.
Questi vengono visualizzati anche nell'elenco degli errori:
Edificio
Questi errori compaiono anche durante la costruzione. Quando si crea dalla riga di comando, l'output è molto dettagliato e può essere estremamente utile durante la diagnosi dei problemi:
> 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
L'output mostra tutti gli assembly passati nel compilatore da pacchetti e riferimenti di progetto. Quando inizi a ricevere errori di compilazione, è utile guardare qui per assicurarsi che il pacchetto che stai utilizzando funzioni effettivamente su quella piattaforma di destinazione.
Ecco un esempio di un pacchetto che non funziona su 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 versione 3.0.0 non ha alcun assembly che gira su dnxcore50 (dai un'occhiata alla cartella lib del pacchetto decompresso). Quando corriamo kpm build:
Notare che dice "utilizzando il pacchetto Microsoft.Owin.Host.SystemWeb" ma non c'è "File:". Questo potrebbe essere il motivo di un errore di compilazione.
Qui finisce la mia discarica di cervello