Gestione dei pacchetti NuGet interni con accesso al codice sorgente

Abbiamo molte librerie interne che vorremmo condividere tra i progetti all'interno dell'azienda. Questi sono alcuni dei requisiti:

le fonti della biblioteca sono archiviate in repository separati dai progetti finali
i progetti finali includono librerie tramite NuGet
deve essere possibile ispezionare facilmente il codice sorgente per ogni data libreria mentre si lavora su un progetto finale

L'impostazione del nostro repository NuGet privato non è un problema, ma la gestione delle fonti lo è. Abbiamo cercato di esporre le fonti tramite il server di origine e in qualche modo funziona, ma non del tutto: VS scarica le fonti durante il debug del codice esterno, ma non quando si tenta di passare alla definizione / implementazione. Fondamentalmente, puoi solo andare al codice sorgente durante il debug, che non è proprio quello di cui abbiamo bisogno.

Quindi, le domande sono:

quali modi esistono per fornire l'accesso al codice sorgente delle librerie interne senza la necessità di avere il codice nello stesso repository / soluzione
c'è un modo per configurare la combinazione di server Symbol / NuGet in modo che VS utilizzi i simboli per la navigazione, non solo per il debug?

L'uso di ReSharper / altri componenti aggiuntivi è un'opzione.

c# source-code closed-source nuget

— Dyppl
fonte

Abbiamo trovato l'uso di Nuget per la gestione di progetti interni non ottimale; alla fine l'abbiamo strappato a favore di riferimenti a progetti e DLL. Mi piacerebbe sentire qualcuno che è stato in grado di farlo funzionare.

— Robert Harvey,

Hai anche impostato un server di simboli per i file pdb che corrispondono alle dll contenute nei pacchetti NuGet?

— RubberDuck

Abbiamo la stessa configurazione esatta nel mio attuale posto di lavoro. Server NuGet (contiene DLL senza PDB) più server di simboli (contiene DLL, PDB e origini). Abbiamo anche lo stesso problema (fonti e PDB recuperati solo durante il debug). @RobertHarvey: NuGet Package Manager è un client NuGet scadente. Non distingue tra dipendenze dirette e transitorie e richiede sciocche azioni di "consolidamento". Siamo passati a Paket e da allora non ci siamo più guardati indietro. Ha reso la gestione dei pacchetti sana e sopportabile, al limite del piacevole.

— Allon Guralnek,

Devo chiedere - anche se non penso che questo sia un requisito irragionevole - perché devi essere in grado di cercare i pacchetti condivisi / comuni? In teoria, almeno queste dovrebbero essere scatole nere documentate e la necessità di guardare dentro dovrebbe essere l'eccezione piuttosto che la norma. In ogni caso sono disponibili nel repository di origine e dovrebbe quindi essere tollerabilmente banale scaricare la soluzione da esaminare. Riesco a vedere un numero qualsiasi di motivi per cui questo o parte di questo potrebbe non essere del tutto vero, ma vale comunque la pena chiederlo.

— Murph,

@Murph - Non sono l'OP, ma nella mia esperienza la documentazione non cattura mai i dettagli che desidero. Devo ripulire questo stato o sarà la chiamata? Cos'è esattamente questa fuga? In che modo differiscono questi sovraccarichi? Queste entità supportano l'uguaglianza e, in caso affermativo, in base a cosa? Qual è la complessità approssimativa di questa chiamata? L'unica documentazione dettagliata che vale la pena avere è la fonte (pulita), perché ci saranno sempre e comunemente cose che il documentatore non ha mai preso in considerazione, ma che sono importanti per te. La documentazione peggiore e complessa contiene inevitabilmente errori e diventa stantia.

— Eamon Nerbonne,

Risposte:

Ciò che dovrebbe funzionare è semplicemente estrarre il codice sorgente per il pacchetto NuGet e aprire la soluzione in un'istanza separata di Visual Studio.

Visual Studio ha un trucco per passare da un codice all'altro in istanze aperte elaborando ciò a cui hai fatto riferimento. La prima volta che mi è successo mentre stavo eseguendo il debug, è stata una rivelazione.

Il problema principale che devi affrontare è assicurarti che il codice estratto per il pacchetto dipendente rappresenti la stessa versione del riferimento NuGet nel progetto principale. Non è un problema se segui una politica di costruzione sempre rispetto alla versione più recente del tuo pacchetto.

Un altro vantaggio di questo approccio è che se il pacchetto deve cambiare, è possibile apportare la modifica lì e poi.

— Stewart Ritchie
fonte

Puoi fornire ulteriori dettagli su come farlo funzionare? Non funziona come mi hai descritto. Devi includere i PDB nel pacchetto? Qualche altro trucco?

— Dyppl

-1

Forse puoi usare https://github.com/GitTools/GitLink . Aggiunge un collegamento nel file pdb che punta al repository in modo che Visual Studio recuperi il codice sorgente da lì - e quindi è sufficiente includere il file pdb nel pacchetto nuspec e non è necessario un server di origine.

— Jesper Balle
fonte

Funziona al di fuori del debug però? Non sembra così.

— Dyppl,

-1

Quindi non è una soluzione perfetta, ma dici che potresti usare Resharper; con dotPeek e resharper puoi navigare verso lo smontaggio del codice originale, è quello che uso al lavoro, dove abbiamo una configurazione simile alla tua.

Trovo una combinazione del Symbol Server che hai citato e sfogliare lo smontaggio è normalmente sufficiente per capire cosa sta succedendo.

Spero possa aiutare.

Modifica: dopo aver riletto la tua domanda, mi rendo conto che chiedi espressamente di poter sfogliare il codice sorgente, cosa che non è. Speriamo comunque che sia utile a qualcuno.

— BaronVonDrew
fonte