2013-03-15 14 views
15

Abbiamo problemi con gli aggiornamenti del pacchetto nuget e l'integrazione del controllo del codice sorgente TFS ultimamente. Ciò sta causando fastidi con il nostro team e ci fa esitare nell'adottare completamente i pacchetti di nuget.Aggiornamenti pacchetto Nuget e problema rimozione pacchetto Package.config (TF400024)

Il problema/bug; invece di aggiornare alcuni file "package.config" di progetti, vengono rimossi dal file system (e contrassegnati come eliminati dal controllo sorgente TFS ...) Non riesco a capire perché ...

Il comportamento che stiamo vedendo è il seguente:

  1. Open in soluzione in VS.NET 2012
  2. avviare un aggiornamento del pacchetto di livello della soluzione alla versione più recente tramite la finestra di gestione dei pacchetti, come descritto here (circa 18 progetti.) .
    • Il file package.config esiste e parte del/i progetto/i all'interno della soluzione selezionata.
    • Questi pacchetti.configs NON sono ancora controllati da TFS.
  3. Nuget pacchetto di aggiornamento si verifica, selezionare package.config vengono rimossi dal progetto e contrassegnato come eliminato entro TFS e riferimenti rimangono in progetto aggiornato alla versione corrente ....
  4. Ovviamente, questo significa che quando il check-in la soluzione e il progetto the packages.config saranno rimossi, rendendo gli aggiornamenti futuri (credo) dolorosi come sopra il progetto cadrà dal radar di nuget ....
  5. Ho notato questo e Annulla il check-out & ottenere questo errore:

    TF400024: The change on xxx\packages.config cannot be undone because a file already exists at xxx\packages.config. The file must be deleted from disk for the undo to succeed. 
    
    • Interessante, per TFS il file è contrassegnato come cancellato ma risiede ancora nel mio file system?

L'output fornito dal Gestore pacchetti elencati di seguito non indica eventuali problemi per il progetto in cui è stato rimosso il pacakage.config ...

Updating 'NugetPackageAssemblyA' from version '1.5.18.0' to '1.5.23.0' in project 'CommonUnitTests'. 
Removed reference 'AssemblyAA.dll' from project 'CommonUnitTests' 
Removed reference 'AssemblyBB.dll' from project 'CommonUnitTests' 
Removed reference 'AssemblyCC.dll' from project 'CommonUnitTests' 
Removed reference 'NugetPackageAssemblyA.dll' from project 'CommonUnitTests' 
Added file 'packages.config'. 
Removed file 'packages.config' 
Successfully removed 'NugetPackageAssemblyA 1.5.18.0' from CommonUnitTests. 
Added reference 'AssemblyAA' to project 'CommonUnitTests' 
Added reference 'AssemblyBB' to project 'CommonUnitTests' 
Added reference 'AssemblyCC' to project 'CommonUnitTests' 
Added reference 'NugetPackageAssemblyA' to project 'CommonUnitTests' 
'packages.config' already exists. Skipping... 
Successfully added 'NugetPackageAssemblyA 1.5.23.0' to CommonUnitTests. 

DEV. Ambiente Statistiche:

  • direttore Nuget pacchetto: versione 2.2.40116.9051
  • Visual Studio 2012: la versione di aggiornamento 11.051106.01 1

C'è qualcosa che mi manca ???? Grazie

+0

Ciao, ti dispiacerebbe depositare un bug su CodePlex per consentirci di investigare? http://nuget.codeplex.com/workitem/list/basic. Se puoi condividere la tua soluzione e i pacchetti, sarebbe fantastico. – superkinhluan

+0

Hey Superkinhluan, grazie per la risposta .... done Nuget bug [collegamento] (http://nuget.codeplex.com/workitem/3170)...Io dovrò creare una soluzione separata e allegare per dimostrare il problema – darthal

risposta

1

Prova:

  • UNBIND tutti i vostri progetti di controllo del codice sorgente
  • Installare il pacchetto NuGet
  • Rebind tutti i vostri progetti di nuovo
+0

Sì, quello ha funzionato per me. Tuttavia, non dimenticare di aggiungere i nuovi file .nupkg al controllo del codice sorgente quando si effettua nuovamente il collegamento. Ne avrai bisogno se esegui il ripristino di un pacchetto in Azure. – Elferone

1

Una soluzione per noi era di verificare l'intera soluzione e quindi aggiornare i pacchetti NuGet.

14

Un semplice check-in del codice per Visual Studio Online ha fatto il trucco per me.

+0

un tale peccato da Microsoft, spero che risolveranno presto. Ho perso troppo tempo a risolvere questo problema ... Stavo cercando il problema nei riferimenti e nei pacchetti ma tutti i problemi provenivano da TFS !! WTH ?! > :( – AmiNadimi

+0

Questo è quello che serve per me ... Grazie! – Coding4Fun

8

Quello che sta succedendo qui (probabilmente) è che avevi una versione precedente (o la stessa versione) del dll come riferimento, e in un punto ALCUNO (se lo hai fatto o VS lo ha fatto), ha rimosso il riferimento . Mentre non vedi il riferimento nella cartella, il processo di check-in TFS/GIT è ancora in attesa di "controllare" il fatto che tu l'abbia rimosso. Quindi, se non hai verificato questo fatto, VS pensa che sia ancora lì, quando in realtà non lo è. Puoi verificarlo nell'area Team Explorer dove dovresti essere in grado di vedere il file .dll rimosso (indicato da una linea che lo attraversa).

Un po 'stupido, ma è così che va.

+0

Lifesaver assoluto! Ho avuto circa 50 file in questo stato - ma armati con la conoscenza di cui sopra, ho risolto il problema eliminando tutti i file in conflitto in Windows Explorer , aprendo Visual Studio senza aprire una soluzione, aprendo Team Explorer, annullando le modifiche in Team Explorer, e ottenendo l'ultima versione dei file eliminati in precedenza. –

+0

Oh sì grazie, ho avuto un piccolo problema con VS non includendo le modifiche apportate nel check in. Dopo aver incluso le eliminazioni della cartella bootstrap nel mio caso e il check-in ha funzionato bene. – Juan

6

Ho avuto anche questo problema.

Per risolvere che:

  1. Aprire il controllo del codice sorgente Explorer (Team Foundation)
  2. La cartella 'pacchetti' di soluzione
  3. Fai arrivo di questa cartella

Dopo questo sarà possibile installare i pacchetti Nuget senza ricevere l'errore TF400024.

+0

Ha funzionato per me, grazie per averci informato che è sufficiente controllare la cartella dei pacchetti e non l'intera soluzione . –

Problemi correlati