settembre 2007 Blog Posts
I progetti Visual Studio 2003 sono dovrebbero essere dei file XML validi...Peccato che, se inserite nel progetto un file che contenga un carattere "&", questo non venga codificato correttamente e pertanto non é più un documento XML valido!
<File RelPath = "file.txt" BuildAction = "None"/><File RelPath = "this&that.txt" BuildAction = "None"/>
Il parser di Visual Studio continua però ad elaborarlo correttamente, il che mi fa pensare che in Microsoft si fossero divertiti a "reinventare la ruota" per l'ennesima volta (ennesimo parser XML?)!Visual Studio 2005 non soffre di questo problema: non consente file con il carattere "&".
Soluzione? Io mi sono costruito una regulaexpression che sostituisce il carattere...
Ci sono vari modi per scaricare del codice a partire da una label, il più corretto é indubbiamente costruire una GetRequest che prenda gli Item di un certo Path a partire dalla versione della Label:
private
static
void GetFromLabelVersion(VersionControlServer vcs, VersionControlLabel label, string folder, string workSpaceName, string workSpaceOwner){ //Ottengo il WorkSpace da Nome e Owner Workspace workspace = vcs.GetWorkspace(workSpaceName, workSpaceOwner); //Riferimento alla versione "della label" VersionSpec version = new
LabelVersionSpec(label.Name, label.Scope); //Costruisco la richiesta GetRequest request = new
GetRequest(folder, RecursionType.Full, version); //Scarico dal WorkSpace workspace.Get(request, GetOptions.None);}
Quello che invece sembra il più intuitivo é in realtà il più sbagliato: costruire delle richieste usando gli item caricati nella Label stessa uno per uno e specificandone...
...se dovesse servirvi, per eliminare i riferimenti al Source Control da una solution VS2003 dovete:
eliminare tutti i file con estensione: vssscc, vspscc, scc, suo
aprire i file di Solution ed eliminare la section "GlobalSection(SourceCodeControl)"
aprire i file di progetto, navigare nel tag <VisualStudioProject> <VisualBasic (o <VisualStudioProject> <CSHARP) ed eliminare gli attributi: SccProjectName, SccLocalPath, SccProvider
Con la doverosa premessa che la paternità di questo post va condivisa con il buon Janky.
Visual Studio .NET 2003 (credo anche 2002, ma, grazie a Dio, non devo pormi questa domanda) ha un comportamento che potrebbe sembrare piuttosto strano rispetto l'interazione tra i progetti Web e il Source Control.
Avete mai provato a scaricare per la prima volta una Web application .NET 1.1 da Team Foundation Server e successivamente aprirla con Visual Studio? Quasi sicuramente vi sarà comparsa una schermata che vi propone di creare il binding tra il vostro codice sorgente ed il famigerato progetto web (che non...
Questa mattina leggo le email e quando arrivo in fondo... SORPRESA!!!
Stavo iniziando a preoccuparmi che 2,7 Gb prima o poi sarebbero finiti, ma San google mi ha anticipato!
Sempre sulla scia della mia indagine sugli oggetti TeamFoundationServer creati mediante TeamFoundationServerFactory ho notato un altro dettaglio: se creiamo più oggetti con la Factory e poi si invoca Dispose su uno di essi tutti gli oggetti diventano inutilizzabili (perché sono banalmente lo stesso oggetto)!!!
TeamFoundationServer tfs1 = TeamFoundationServerFactory.GetServer("http://tfsrtmsp1:8080");
tfs1.Authenticate();
TeamFoundationServer tfs2 = TeamFoundationServerFactory.GetServer("http://tfsrtmsp1:8080");
tfs2.Authenticate();
tfs1.Dispose();
VersionControlServer vfs2 = (VersionControlServer)tfs2.GetService(typeof(VersionControlServer));
L'ultima linea, infatti, genera una bella NullReferenceException!
In effetti basta verificare che object.ReferenceEquals(tfs1, tfs2) é effettivamente true!
Quindi, se usate la Factory NON fate il dispose del TeamFoundationServer fino alla fine del programma a quando non siete certi che non ne usate più da nessuna parte!!!
Attenzione quando usate l'oggetto TeamFoundationServerFactory: sebbene permetta di riutilizzare da più oggetti TeamFoundationServer la stessa connessione al server (e quindi risparmiare un po' di risorse) ha un comportamento non molto intuitivo legato all'autenticazione.
premesso using Microsoft.TeamFoundation.Client; e una semplice classe CredentialProvider (che non includo perché il post mi sembra già troppo lungo) che ritorna user e password alla richiesta di TFS.
Gli esempi seguenti dovrebbero creare due oggetti autenticati rispettivamente come user1 e user2
TeamFoundationServer tfs1 = TeamFoundationServerFactory.GetServer("http://tfsrtmsp1:8080", new
CredentialProvider("user1", "pass1"));tfs1.Authenticate();TeamFoundationServer tfs2 = TeamFoundationServerFactory.GetServer("http://tfsrtmsp1:8080", new
CredentialProvider("user2", "pass2"));tfs2.Authenticate();Console.WriteLine("tfs1: " + tfs1.AuthenticatedUserName + "\ntfs2: " + tfs2.AuthenticatedUserName);E' facile vedere che in realtà sia tfs1 che tfs2 sono...