Gestione dei pacchetti NuGet interni con accesso al codice sorgente

Question

Gestione dei pacchetti NuGet interni con accesso al codice sorgente

#1 da (1 voti)
#2 da (-1 voti)
#3 da (-1 voti)

18

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

le fonti di libreria sono archiviate in repository separati da progetti finali
i progetti finali includono librerie via NuGet
deve essere possibile ispezionare facilmente il codice sorgente per qualsiasi libreria data mentre si lavora su un progetto finale

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

Quindi le domande sono:

quali sono i modi 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 usi i simboli per la navigazione, non solo per il debug?

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

c# source-code closed-source nuget

posta Dyppl 01.08.2016 - 21:22

fonte

3 risposte

Leggi altre domande sui tag c# source-code closed-source nuget

Modulo che richiede vs Iniezione di dipendenza in Javascript Insegnare a me stesso, come fisico, a diventare un programmatore migliore [chiuso]

score 1 · Answer 1

Ciò che dovrebbe funzionare è semplicemente il controllo del codice sorgente per il pacchetto NuGet e l'apertura della soluzione in un'istanza separata di Visual Studio.

Visual Studio ha l'accortezza di passare da codice a codice in istanze aperte elaborando ciò a cui si è 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 tuo riferimento NuGet nel progetto principale. Non è un problema se segui una norma che si basa sempre sulla versione più recente del tuo pacchetto.

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

score -1 · Answer 2

Forse puoi utilizzare il link . 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 avrà bisogno di un server di origine.

score -1 · Answer 3

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

Trovo che una combinazione del Symbol Server che hai citato e la navigazione nello smontaggio sia normalmente sufficiente per capire cosa sta succedendo.

Spero che ti aiuti.

Modifica: dopo aver riletto la tua domanda mi rendo conto che chiedi specificamente di poter consultare il codice sorgente, che non è questo. Tuttavia spero che possa essere utile a qualcuno.