Come specificare la maschera di ricerca corretta per la finestra di dialogo "Specifica del file dell'assembly di prova" nella definizione di build TFS2010?

Question

Non so come specificare la maschera corretta per cercare i miei assiemi di test nella definizione di build TFS2010. Non sto utilizzando la cartella Binaries predefinita per gli assembly di output. Ogni progetto di test ha la propria cartella di output bin \ Debug o bin \ Release. Se uso la maschera di default ** \ * test * .dll miei test non riuscita con questo errore:

API restriction: The assembly 'file:///E:\Builds\....\obj\Debug\xxx.IntegrationTests.dll' 
has already loaded from a different location. It cannot be loaded from a new location within the same appdomain. 

Questo perché ** \ * test * .dll maschera troverà più risultati per lo stesso assemblaggio in le cartelle bin \ Debug e obj \ Debug.

Ho provato a cambiare questa maschera per escludere cartella obj \ Debug e utilizzare bin solo:

**\bin\Debug\*test*.dll 
**\bin\**\*test*.dll 
**\Debug\*test*.dll 

ma l'attività FindMatchingFiles restituiscono sempre 0 risultati.

Funziona solo quando passo il percorso completo al gruppo di test.

Qual è la maschera corretta se si desidera escludere le cartelle obj \ Debug dalla ricerca dell'assieme di test?

SOLUZIONE:
sto ancora utilizzando l'attività FindMatchingFiles, ma ho dovuto aggiungere l'attività Assegnare con i seguenti params:

To - testAssemblies 
From - testAssemblies.Where(Function(o) Not o.Contains("\obj\")).ToList() 

sto filtrando tutte le linee di prova presenti nel "obj" cartelle in questo modo.

Answer 1

sto ancora utilizzando l'attività FindMatchingFiles, ma ho dovuto aggiungere l'attività Assegnare con i seguenti params:

To - testAssemblies Da - testAssemblies.Where (function (o) Non o.Contains ("\ obj \ ")). ToList() Sto filtrando tutti i gruppi di test trovati nelle cartelle" obj "in questo modo.

Answer 2

L'attività di costruzione che è di interesse per voi si chiama "Trova test Assemblee":

Allora, che si posiziona alla definizione build è concatenato dopo script di build variabile outputDirectory.

Questo outputDirectory viene inizializzato per ogni configurazione di attività "Inizializza OutputDirectory":

È possibile mettere in coda una nuova build in cui si imposta la 'di dettaglio di registrazione' pari a Diagnostic. Una volta che questo è stato eseguito (e fallito), controlla cosa sta succedendo con la tua build.

La mia ipotesi è che si abbiano problemi con le impostazioni di configurazione/piattaforma, ma senza un input concreto che sia solo una supposizione.

Answer 3

Probabilmente il ** all'inizio del filtro è il problema. Il punto di partenza della ricerca è in una posizione che non ci si aspetterebbe che fosse e le sottodirectory non contengono i file di test.

Per risolvere questo problema, aggiungere ..\..\.. all'inizio dell'espressione del filtro. A scopo di debug, questo uscirà dalla struttura della sottodirectory in cui ti trovi ed eseguirà una ricerca più ampia sul tuo sistema per i file di test. Puoi anche rendere assoluta la prima parte, per assicurarti di cercare nei sotto-canali di destra.

In alternativa, è anche possibile eseguire una sessione processmonitor sul sistema di generazione, per vedere dove il proprio motore di compilazione TFS sta effettivamente cercando gli assembly di test. O eseguire alcune operazioni di registrazione nel flusso di lavoro di build/attività stessa.

Dopo aver trovato il problema, restringere nuovamente la finestra di ricerca per non cercare strutture di sottodirectory non pertinenti.

Answer 4

Mi sono imbattuto praticamente nello stesso problema che hai. Ho sviluppatori che utilizzano un assembly di test helper (TestHelper) e una cartella _PublishedWebsites che causa questo problema.

Quello che ho finito per risolvere questo problema è stato risolvere il problema di ottenere più della stessa DLL di test passata a MSTest. "Bene, questo è quello che sto cercando di fare con la mia maschera", si potrebbe pensare! Ho provato la stessa soluzione ma sono venuto vuoto.

Ho scritto un'attività personalizzata e l'ho inserita dopo che il processo di generazione ha trovato gli assembly di prova. Ecco il codice per l'attività personalizzata:

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
using Microsoft.TeamFoundation.Build.Client; 
using Microsoft.TeamFoundation.Build.Workflow.Activities; 
using System.Activities; 
using System.IO; 

namespace BuildTasks.Activities 
{ 
    [BuildActivity(HostEnvironmentOption.All)] 
    public class DistinctFileList : CodeActivity<IEnumerable<String>> 
    { 
    public InArgument<IEnumerable<String>> ListIn { get; set; } 

    protected override IEnumerable<String> Execute(CodeActivityContext context) 
    { 
     IEnumerable<string> listIn = context.GetValue(this.ListIn); 

     context.TrackBuildMessage("Items in ListIn: " + listIn.Count(), BuildMessageImportance.High); 

     var filenameGroupings = listIn.Select(filename => new FileInfo(filename.ToString())) 
     .GroupBy(fileInfo => fileInfo.Name); 

     IEnumerable<string> listOut = filenameGroupings.Select(group => group.FirstOrDefault().FullName); 

     context.TrackBuildMessage("Items in out list: " + listOut.Count(), BuildMessageImportance.High); 

     string multiples = string.Join(", ", 
     filenameGroupings.Where(group => group.Count() > 1).SelectMany(group => group.Select(fileInfo => fileInfo.FullName)).ToArray()); 

     context.TrackBuildMessage("Duplicate test items: " + multiples, BuildMessageImportance.High); 

     return listOut.ToList(); 
    } 
    } 
} 

Si potrebbe inserire questo dopo l'operazione "Trova test Assemblee".

Answer 5

Mi sono imbattuto in questo problema ma ho trovato che piuttosto che solo bin e obj contenenti duplicati, avevo molte copie delle stesse DLL che appaiono in varie cartelle di progetto.

La risposta di Ludwo con Assign era quasi sufficiente per risolverlo, ma per la mia situazione avevo bisogno di un valore più generale per il parametro From. Questo VB raggruppa i percorsi di file rilevati per nome file e quindi preleva il primo percorso da ciascun gruppo. E, naturalmente, funziona solo se e solo se ogni nome di file mappato a una DLL logica:

testAssemblies.GroupBy(Function(a) New System.IO.FileInfo(a).Name).[Select](Function(g) g.First())