agosto 2007 Blog Posts
Se da un sito ASP.NET con impersonation state caricando un vostro IConfigurationSectionHandler l'utente che esegue System.Configuration.ConfigurationManager.GetSection non é l'utente loggato nella pagina, ma bensì "Network Service"!!!
Attenti perché da quello che posso vedere questo "dettaglio" non é documentato (oppure é documentato chissà dove).
Molto meno complesso del capitolo precedente...
1. Non é possibile avere due versioni dello stesso file all'interno della stessa etichetta (sì, ok, vi sembrerà scontato), nemmeno se effettuate il rename dello stesso:
creamo la label paperino su: $/pippo/x.cs
effettuiamo un rename di $/pippo/x.cs in $/pippo/y.cs e facciamo il check-in dell'operazione di rename
se cerchiamo di aggiungere $/pippo/y.cs alla label paperino questo file sostituirà silenziosamente $/pippo/x.cs
2. Non é possibile avere due file con lo stesso nome (e percorso) all'interno della stessa etichetta:
creamo la label paperino su: $/pippo/x.cs
rinominiamo $/pippo/x.cs in $/pippo/y.cs ed effettuiamo il checkin
rinominiamo $/pippo/z.cs (un qualsiasi altro file) in $/pippo/x.cs ed effettuiamo il...
Le labels sono uno strumento molto utilizzato, ma la cui gestione non é sempre molto chiara.
Apparentemente non é possibile avere label con nome duplicato all'interno dello stesso team project:
se creo una label di nome paperino sul file $/pippo/x.cs
e cerco di creare un'altra label con lo stesso nome sul file $/pippo/y.cs
il secondo file verrà semplicemente aggiunto alla label esistente (di cui verrà fatto l'update dei commenti).
Questo comportamento non é solo a livello di Team Explorer, ma anche dall'Object Model:
se chiamo, con gli opportuni parametri, il metodo VersionControlServer.CreateLabel due volte otterrò come risposta rispettivamente: LabelResultStatus.Created e LabelResultStatus.Updated (se da Team Eplorer capisco...
La documentazione MSDN in merito al metodo QueryLabels della classe VersionControlServer mi sembra poco chiara. In particolare esistono 3 overloads del metodo:
public
VersionControlLabel[] QueryLabels(string labelName, string labelScope, string owner, bool includeItems);public
VersionControlLabel[] QueryLabels(string labelName, string labelScope, string owner, bool includeItems, string filterItem, VersionSpec versionFilterItem);public
VersionControlLabel[] QueryLabels(string labelName, string labelScope, string owner, bool includeItems, string filterItem, VersionSpec versionFilterItem, bool includeDownloadInfo);
I parametri sono in parte comuni, ma secondo me poco chiari:
labelName: Nome della label cercata, se sconosciuta indicare null.
labelScope: Il teamproject a cui é applicata la label. Potete anche indicare un folder del versioncontrol, ma verrà tenuto conto solo del team project, null se sconosciuto
owner:...
Una piccola nota sul metodo CreateLabel della classe VersionControlServer: l'ID della label da creare passata ovviamente non viene aggiornato, pertanto per avere l'oggetto label corretto é necessario ricaricarlo.
public
virtual
VersionControlLabel CreateLabel(VersionControlLabel label, ItemSpec items, VersionSpec version)
{
VersionControlServer vcs = label.VersionControlServer;
LabelItemSpec item = new
LabelItemSpec(items, version, false);
LabelResult[] res = vcs.CreateLabel(label, new
LabelItemSpec[] { item }, LabelChildOption.Replace);
if (res.Length > 0 && res[0].Status == LabelResultStatus.Created)
{
//Reload label per ottenere l'ID giusto!
label = vcs.QueryLabels(label.Name, label.Scope, label.OwnerName, false)[0];
return label;
}
return
null;
}
Complice l'upgrading a subtext che digerisce poco bene gli spazi negli URL ho deciso di fare un passo a cui pensavo da tempo...
Ora il mio blog é stato rinominato da ".NET%20Forever" a "dotnet4ever"!!!
E' un po' come rinascere nella comunità dei blogger!
Scusate la cripticità del titolo.
Come sappiamo per sviluppare progetti web in Visual Studio 2005 sotto windows Vista é necessario avviare VS2005 con privilegi amministrativi.
Ve ne sarete accorti già tutti, e vi sembrerà una cosa logica, ma se fosse sfuggito a qualcuno vorrei segnalare che la finestra di Internet Explorer che viene aperta per il debugging del vostro progetto web ha gli stessi privilegi amministrativi di Visual Studio!!! In cosa si traduce questo? Sostanzialmente non compariranno mai messaggi della UAC. Conclusione: non riutilizzate quella finestra di IE per navigare perché perdereste i bonus per la sicurezza di Windows Vista.
Se usate windows Vista ed avete dei progetti Web vi sarete probabilmente rassegnati ad avviare Visual Studio "As Administrator" .
Se mentre avete delle modifiche pendenti in un progetto avviato come Administrators e aprite un'altra finestra di Visual Studio NON come Administrators molto probabilmente (se il file é già stato salvato nella cartella "Backup Files" da Visual Studio come nello screenshot qui sotto) vi verrà proposto di recuperare dei files modificati come se Visual Studio fosse crashato:
Ovviamente NON avreste un comportamento simile anche su altri SO (ad esempio XP) se avviaste VS con due utenti diversi in quanto...
Questa me la devo segnare: per scoprire se un utente di TFS fa parte del gruppo "Team Foundation Administrators" si può fare così:
using Microsoft.TeamFoundation.Client;using Microsoft.TeamFoundation.Server;
public
virtual
bool IsAdminUser(TeamFoundationServer tfs){ IGroupSecurityService gss = (IGroupSecurityService)m_tfServer.GetService(typeof(IGroupSecurityService)); Identity userIdentity = this.TFS.AuthenticatedUserIdentity; Identity groupIdentity = gss.ReadIdentity(SearchFactor.AccountName, "Team Foundation Administrators", QueryMembership.Direct); return gss.IsMember(groupIdentity.Sid, userIdentity.Sid);}