Installare e configurare Microsoft Visual Source Safe 2005 e l’accesso remoto via Internet

March 10, 2007 00:00 by Admin

Questo articolo è semplicemente una traduzione in italiano dell’articolo originale proposto da Alin Constantin nel suo sito web. Alin è un dipendente Microsoft che lavora al team di Source Safe, quindi chi meglio di lui poteva avere una certa esperienza nel scrivere questo articolo? Fatto sta, che nonostante la chiarezza, ho avuto modo di mettermi in contatto con Alin perché avevo trovato difficoltà nella configurazione di VSS, cioè … meglio mi beccavo degli errori che non riuscivo a risolvere, perché la sua guida è così chiara che non dovrebbe sbagliare praticamente nessuno. Alla fine del discorso il problema era stata l’installazione di SharePoint server sulla default root, e per questo fornirò soluzione a parte in coda all’articolo.
Comunque, fatto sta che un paio di ping in chat, Alin mi risponde e dopo neanche 24 ore avevo il mio problema risolto. Mi è sembrato quindi giusto proporre – dietro consenso dell’autore – la traduzione del suo articolo con qualche commento in mezzo per aiutare altri poveri mortali nella configurazione del plug-in di VS per il Source Safe.
L’articolo quindi non spiega cosa è Source Safe, come di configura ecc., ma spiega solo come impostare correttamente questa feature che trovo a dir poco straordinaria. Grazie Alin.

****************************

Visual SourceSafe Internet è un plug-in che consente l’accesso ai database di Source Safe attraverso la rete Internet. Precisiamo intanto una cosa che nell’articolo di Alin e comunque in tutti i post dei forum incontrati si legge sempre alla fine. Quando si parla di Internet in questo caso si parla esclusivamente di porta 80 o di porta 443 (protocollo SSL). Se quindi volete far girare il sito web e questo web service sotto un porta differente, semplicemente scordatevelo.
La configurazione, prosegue Alin, dovrebbe risolversi semplicemente spuntando due checkbox, ma nella maggior parte dei casi ci si può imbattere in problem di vario genere sui permessi, sull’installazione dei certificate SSL, ecc. Credo che le persone che non abbiano una certa dimestichezza con il Source Safe potrebbero avere serie difficoltà nell’impostare il Remote Access correttamente, per questo ho deciso di preparare una guida step-by-step. In questo esempio di configurazione andrò ad utilizzare il peggior caso possibile: quello di due computer che non appartengono allo stesso dominio con un nuovo database VSS senza che i nomi utenti coincidano con gli utenti Windows su di una configurazione http non sicura (nessun certificato SSL). Il nome del server in questo esempio è stato impostato su ALINC-HOME, e manco a dirlo deve essere un computer visibile sulla rete Internet, quindi accessibile senza problemi. Per ovviare alla situazione, in caso di computer di casa o più in generale senza un indirizzo IP fisso si può ricorrere a servizi di DNS dinamici come No-IP o DtDns. Alin nel suo caso ha utilizzato DtDns, io No-IP ed entrambe siamo riusciti nel nostro intento. Il computer di Alin, visibile dall’esterno, è (o era) raggiungibile al seguente indirizzo http://alinconstantin.dtdns.net address (voi tenete traccia del vostro indirizzo UNC). Una volta loggato nella sua macchina, Alin ha configurato VSS per l’accesso remoto, ha creato un database sulla macchina di casa e voleva accedervi – tramite internet – dal posto di lavoro.

Installazione di Microsoft Visual SourceSafe Internet
1. Primo step necessario è installare su tutti I computer che si vogliono coinvolgere nel test il pacchetto di Microsoft Visual SourceSafe. L’installazione può essere tranquillamente per tutti i computer quella completa, anche perché l’installazione di default risparmia poco più di 600K, quindi fate voi.
2. Se proprio avete carenza di spazio, scegliete una installazione di default sul client, mente sul server no, scegliete l’installazione customizzata perchè di default non vengono installati i componenti necessari, quindi magari sulla parte server, scegliete l’installazione customizzata e assicuratevi che sia spuntata la casella http Remote Access Component sotto la scheda Server Component.
3. Completata l’installazione, sul client aprite il Visual Studio, andate nel menu strumenti, opzioni e quindi sulla scheda Source Control e selezionate il Source Safe Internet come il provider per la gestione del codice sorgente. Questo vale per il VS 2005. Per il VS 2003 sarà necessario ricorrere ad uno switcher esterno come ad esempio SccSwitcher. Alin suggerisce anche un possibile cambio a manina, ma personalmente nel 2007 a pochi mesi dall’uscita di Orcas, spero bene che siano rimaste poche le copie di VS 2003 in circolazione.



4. A questo punto cliccare sulla voce Plug-in Settings e quindi su Advanced (se utilizzate VS 2005) e assicuratevi di macare la checkbox se intendete utilizzare il protocollo SSL. Diversamente togliete la spunta.



Configurare SourceSafe e VisualStudio per l’accesso remoto via internet (HTTP)
Considerando che la comunicazione con il server viaggia in modo non sicuro su protocollo HTTP, Alin suggerisce di utilizzare la configurazione senza certificate solo in caso di LAN locale o di situazione di test. C’è anche da dire che – ad esempio – No-IP non consente l’utilizzo di certificati SSL (non so DtDns) non gratuitamente almeno. Addirittura, sembra che questo metodo sia caldamente consigliato in condizione di rete locale, perché tecnicamente le operazioni di check-in e check-out dovrebbero essere un peletto più veloce. Non ho provato perchè il mio scopo era quello proprio di lavorare da remoto.
Allo stato attuale non ho ancora provato, pertanto non vi posso dire nulla in merito.
In entrambe i casi, quindi connessione HTTP, che con connessione HTTPS, gli step da seguire sono i seguenti:
1. Aprire la console amministrativa di Source Safe (ssadmin) per creare un database. Dal menu File, scegliere New Database, quindi seguire il wizard per completare l’operazione. Essendo un nuovo database, al termine dell’operazione lo stesso conterrà esclusivamente gli utenti standard di VSS (Admin e Guest) più l’account Windows correntemente loggato.
2. Per abilitare l’accesso remote, è necessario anzitutto condividere il database. Utilizzando Windows Explorer, andare nella radice della cartella che avete destinato al vostro database e condividere la cartella.
3. In SSAdmin, utilizzando il menu File / Open, scegliere Add e riaggiungere a questo punt oil database utilizzando per la locazione UNC (\\nomemacchina\nomecondivisione).
4. Dopo aver aperto il database, andare nel menu Server/Configure e spuntare le caselle "Enable SourceSafe Internet for this computer" e "Enable SourceSafe Internet for this database".
5. Nella casella di testo “Web server name”, digitare il nome del computer accessibile dalla rete Internet o dalla LAN locale, quindi cliccare su OK.



6. Se tutto è andato come deve, semplicemente tentanto di accedere al web service di Source Safe vi dovrebbe comparire una maschera di login. Per fare una prova, aprire Firefox e puntarlo sul vostro pc. Nel caso di Alin è stato http://alinconstantin.dtdns.net/SourceSafe/VssService.asmx.
7. Utilizzando delle credenziali valide per la macchina remota, dovreste accedere al pc. Alin ha fatto i test utilizzando l’utente Amministratore, ma in una situazione reale è caldamente sconsigliata la cosa.



Se il server è configurato correttamente, si dovrebbe aprire una bella pagina di errore (si leggete bene, errore) che invece indica che c’è comunicazione con il server e il web service è perfettamente raggiungibile. Questa pagina di errore viene fuori per ragioni di sicurezza. Il Web Service di Source Safe infatti disabilita per default la visualizzazione dei metodi. E’ consigliabile lasciare così le impostazioni. Tuttavia quando si incominciano a beccare errori strani tipo lo 0xc00ce556 o similari, a differenza di me che è stata l’ultima cosa che ho fatto, sarebbe il caso di modificare il web.config e farsi ritornare eventuali veri errori del Web Service.
Le impostazioni da lasciare così come nasce il web service sono: custom error, da impostare su off () e cancellare la riga .



Questa . Dico dovrebbe perchè nel mio caso, io non ce le ho trovate, e quando sono andate a cercarle - seguendo l'articolo di Alin - sono diventato "scemo" a capire dove fossero fino a che non mi sono rassegnato. Quindi se anche voi state cercando quella riga e non la trovate, semplicemente aggiungetela quando intendete ripristinare lo stato iniziale in questa posizione:

 

   





8. Il web service di VSS utilizza l’impersonalizzazione. Questo significa che l’account utilizzato per effettuare il login alla macchina deve avere anche i permessi di lettura e scrittura sia per la condivisione della cartella, sia come permessi NTFS sul path.





9. Quando non viene utilizzato il protocollo SSL per connettersi al web service, il client VSS non passa nessun username e password al servizio, questo significa che deve esistere nel Source Safe anche un utente che abbia stesso login name e password di quello utilizzato da Windows.



10. Il database di SourceSafe dovrebbe inoltre avere impostato il logon automatic con il nome di rete (opzione di default, ma a scanso di equivoci controllate andando in SSAdmin, Tools/Options/General/"Use Network name for automatic user log in").

E’ praticamente tutto concluso.
Non resta che accedere al nostro database SourceSafe remote. Per fare questo cliccare su apri o su nuovo, quindi scegliere sulla parte sinistra My SourceSafe e fare doppio click su Add SourceSafe Database e seguire il wizard. Sulla casella address dovrete specificare il nome del computer remoto, mentre sulla cartella folder dovrete specificare in formato UNC il path fisico della cartella che contiene il vostro database SourceSafe. Premendo su next, il Visual Studio dovrebbe richiedervi nuovamente il login e se tutto è veramente ok, concedervi l’accesso.
Nota: sulla maschera di login c’è il famoso salva password. Se non siete sicuri di voler utilizzare quell’utente per sempre, evitate di marcare quella casella, perché a meno che il nome utente o la password inserita non siano sbagliati, l’unico modo che avrete per cambiarla sarà quella di distruggere la connessione e ricrearla nuovamente.



Nota 2: Se cliccando su Next, dovreste beccarvi errori vari, ripercorrete I passaggi sopra elencati e sinceratevi che sia tutto come descritto.
In questo articolo ometto di proposito la parte relativa al settaggio via HTTPS/SSL, leggibile – in inglese – sul sito web di Alin a questo indirizzo: http://alinconstantin.homeip.net/webdocs/scc/vss_internet.htm.

Mi soffermo invece sull’errore che mi ero beccato io e che non mi consentiva di andare oltre. Nonostante avessi ripercorso più volte tutti i passaggi, avessi l’accesso alla macchina, mi beccavo quella maschera di errore sopra mostrata, non c’era verso di far accedere Visual Studio al database di SourceSafe. E l’errore che mi si presentava (0xc00ce556) aveva come risoluzione quella di reinstallare il package di Ms XML 6.0 o superiori. Dato che non ero sicuro della vera natura del problema, ho contattato Alin, e nel mentre del nostro scambio di e-mail, mi è venuto il lampo di genio. Fammi provare a togliere il custom error. Se è vero che tutto funziona devo poter vedere la lista dei metodi del web service. E invece? Ta-Daaaaaaaaaaaaa.
Ecco il problema. Praticamente c’erano ulterior problem di permessi che con quella prima maschera di errore venivano praticamente nascosti. Per farla breve cosa era successo. Sulla stessa macchina era stato installato SharePoint Server. Non so se di default SPS si installa nella root del default web site o se inavvertitamente era stato scelto di installarlo li (buona regola confermata da Alin e da una sua collega che lavora nel team di Share Point è quello di installarlo in una virtual directory tutta sua), fatto sta che SharePoint aveva modificato il file web.config del default web site, e alcune di queste modifiche andavano ad impattare sul resto delle virtual directory.
Questo senza contare che SharePoint aveva installato un filtro ISAPI che – non ne conosco e non voglio conoscerne il funzionamento – impediva alle virtual directory sottostanti di mostrare qualsiasi pagina, contenuto e perfino di richiamare il web service stesso.
Per risolvere, è stato quindi sufficiente mettere un file web.config correttamente configurato e tutto magicamente ha iniziato a funzionare. Questo file web.config lo trovate qui sotto. Non credo sia la panacea a tutti i mali, ma a me ha risolto il problema. Attenzione a sovrascrivere il file esistente, in particolar modo se avete fatto delle modifiche. Assicuratevi di fare il backup del file esistente.

***************************

 


 


 


 


 


 



 


 


 


 


 


 


 


 



 


 


 


 


 


 


 


 


 


 


 


 


 



 


 


 


 


 


 


 


 



 


 


 


 


 


 


 


 


 



 


 


 


 


 


 


 


 


 



 


 


 


 


 


 


 


 


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Implementare una collection di elementi personalizzati per il web.config

January 18, 2006 11:13 by Admin

Premessa

 

Un altro problema con il quale mi sono scontrato in questi giorni era la possibilità di avere una collection di elementi per una mia custom section, ma qualcosa che fosse relativamente semplice, e basato su elementi personalizzati. Insomma l'esatto contrario dell'esempio fornito con MSDN, che - IMHO - non era così immediato come speravo, fors'anche perchè è stato concepito per più usi ben più complessi rispetto alla mera collection di sola lettura alla quale miravo io.

La necessità

Volevo ottenere una collection di custom elements all'interno di un file di configurazione, in modo da avere più elementi dello stesso tipo.

La soluzione

Di default, quando si crea una ConfigurationElementCollection, di base la mappatura utilizzata con la proprietà ConfigurationElementCollectionType è di tipo AddRemoveClearMap, il che significa poter interagire con gli elementi che appartengono alla collection esclusivamente con i rispettivi tag Add, Remove e Clear (guarda caso il nome).
Visto che a me non piaceva proprio quell'Add, dovevo trovare un sistema che mi desse un pò più di libertà, e guarda caso il BasicMap lascia tutta la libertà di cui hai bisogno, ivi compresa quella di gestire la ConfigurationProperty con la quale specificare il nome della proprietà che deve corrispondere al nome dell'elemento presente all'interno del file di configurazione.

Ad essere onesto ci sono ancora diverse cosette che non ho compreso del meccanismo delle collection riferito a questo contesto. Per esempio alcuni esperimenti che ho fatto cercando di far partire il tutto dalla classe collection da utilizzare immediatamente in un foreach ... next anzichè da quella section, oppure quello di aggiungere una proprietà della Section che mi restituisse un oggetto corrente (con relative proprietà MoveNext() e Reset(), ma sfortunatamente 3 volte 4 il debug mi va in errore restituendomi di fatto un oggetto collection vuoto, quando di fatto se nascondo quella proprietà dal codice e metto un breakpoint in coda all'ultima graffa, la collection count la vedo piena e perfettamente accessibile. Ma vabbè, che volete, sono ancora agli inizi e sbagliando s'impara. Se imparerò come risolvere la situazione, posterò la situazione; altrimenti come dicono a casa mia "ciccia" o "amen" o quella che preferite).

Comunque, vediamo di capire quello che ho capito io da tutto il discorso. Inizio con un estratto del file web.config e la classe che gestisce gli elements che non starò a descrivere analiticamente poichè, benchè facciano parte dell'esempio, sono in questo preciso istante fuorvianti dal concetto collection (e comunque estremamente semplici da comprendere):

 

<configSections>
   
<section name="MyUrls" 
           type="Andrea.ConfigElementCollection.UrlsSection" />
</configSections>
<MyUrls>
   
<urls>
       
<address name="Microsoft" 
                 url="http://www.microsoft.com" 
                 port="0"/
>
                 
       
<address name="Contoso" 
                 url="http://www.contoso.com/" 
                 port="8080"/>
   
</urls>
</MyUrls>


// Define the UrlConfigElement.
public class UrlConfigElement :
        ConfigurationElement
{
    
public UrlConfigElement(){}

    
public UrlConfigElement(String newName, String newUrl,
          Int16 newPort)
    {
        Name = newName;
        Url = newUrl;
        Port = newPort;
    }

    
public UrlConfigElement(String elementName)
    {
        Name = elementName;
    }

    [ConfigurationProperty("name",
            DefaultValue = "Microsoft",
            IsRequired = 
true,
            IsKey = 
true)]
    
public string Name
    {
        
get
        
{
            
return (string)this["name"];
        }
        
set
        
{
            
this["name"] = value;
        }
    }

    [ConfigurationProperty("url",
            DefaultValue = "http://www.microsoft.com",
            IsRequired = 
true)]
    [RegexStringValidator(@"\w+:\/\/[\w.]+\S*")]
    
public string Url
    {
        
get
        
{
            
return (string)this["url"];
        }
        
set
        
{
            
this["url"] = value;
        }
    }

    [ConfigurationProperty("port",
            DefaultValue = (
int)0,
            IsRequired = 
false)]
    [IntegerValidator(MinValue = 0,
            MaxValue = 8080, ExcludeRange = 
false)]
    
public int Port
    {
        
get
        
{
            
return (int)this["port"];
        }
        
set
        
{
            
this["port"] = value;
        }
    }
}

Quindi, un frammento di codice della pagina default.aspx con la quale ho fatto i tests.

Andrea.ConfigElementCollection.UrlsSection config = 
 (Andrea.ConfigElementCollection.UrlsSection)
  WebConfigurationManager.GetSection("MyUrls");

Debug.WriteLine(config.urls["Microsoft"]);

Quando si chiama la GetSection, specificando il nome della sezione che voglio andare a recuperare, la classe WebConfigurationManager, internamente sà già quale è il file di configurazion della mia applicazione e con la specifica chiamata non fa altro che andare a recuperare in una variabile interna tutto il contenuto della section indicata - in questo caso - e - e e passi ogni singolo tag che incontra alla classe UrlsSection che cercherà al suo interno un riscontro per ogni tag incontrato.

Ne consegue che il primo elemento che trova è , quindi ... bisogna che all'interno della classe Section ci sia una proprietà denominata allo stesso identico modo.
Attenzione, quello che è importante non è il nome della proprietà di per se, che può essere quello che vi pare (anche se per questioni pratiche è meglio che coincida - magari ci sarà pure una nota MS su come si programma e sul fatto che debbano invece essere uguali, ma se c'è non l'ho trovata - ancora) ma il nome che si scrive dentro ai marcatori [ConfigurationProperty("urls")].

Sicchè, nella classe Section avremo questo frammento di codice:

[ConfigurationProperty("urls", IsDefaultCollection = true)]
public UrlsCollection urls
{
    
get
    
{
        
return (UrlsCollection)base["urls"];
    }
}

Al suo interno, alla proprietà gli si chiede di ritornare un oggetto di tipo collection specificandogli che gli elementi che ne dovranno far parte sono quelli all'interno dei marcatori . Come vedete fino a qui, la nostra collection non sà ancora quali elementi saranno al suo interno.

Ma andando oltre. Il debug - visto che vi sto raccontando tutto step-by-step (o almeno ci provo), a questo punto passa nella classe UrlsCollection, per il costruttore di default, quindi immediatamente alla proprietà CollectionType per sapere di che tipo è la collezione (vedi la nota all'inizio) e poi, scoperto che è una collection di tipo BasicMap, visto che presente, andrà nella proprietà ElementName dove è specificato il tag di apertura per gli elementi presenti in , in questo caso

.

Tecnicamente tutto questo processo dovrebbe avvenire in sorta di contemporaneità tra le operazioni di lettura e confronto, il fatto di passare per ElementName è una logica conseguenza per il compilatore che trovandosi sulla prima riga
, essendo un elemento nuovo per la Collection, non potrà far altro che passare per il metodo CreateNewElement con il quale verrà generata la nuova istanza di UrlElementCollection (leggendo quindi tutti i tag che fanno parte di quell'elemento address, verificando che gli attributi corrispondano alle effettive proprietà dalla classe, che i valori siano validabili e validati, ecc. ecc.) che sarà inserita nella collezione.
Ecco il blocco di codice della classe UrlCollection appena descritto:

 

// UrlCollection class fragment
protected override String ElementName
{
  
getreturn "address"; }
}
      
public override ConfigurationElementCollectionType CollectionType
{
  
get
  
{
    
return ConfigurationElementCollectionType.BasicMap;
  }
}

protected override ConfigurationElement CreateNewElement()
{
  
return new UrlConfigElement();
}

Una volta creato il nuovo elemento, il codice ritorna di nuovo alla UrlsCollection e passa per la proprietà GetElementKey (che assieme alla CreateNewElement sono gli unici due metodi "must implement" della ConfigurationElementCollection) dove non si fa altro che specificare quale è la chiave dell'oggetto element che - di fatto essendo una chiave è quella che tecnicamente dovrebbe essere univoca e comunque - fornisce l'accesso diretto tramite l'implementazione dell'indexer ai singoli Element della collection (infatti il tipo restituito, molto genericamente, è un object).

protected override Object 
        GetElementKey(ConfigurationElement element)
{
  
return ((UrlConfigElement)element).Name;
}


Tutto questo processo poc'anzi descritto, viene eseguito tante volte quante sono in realtà gli elementi presenti nella nostra sezione personalizzata del web.config.
Testando con uno step-by-step, ho potuto comunque notare che il debug ha modo di passare per la proprietà ConfigurationElementCollectionType più volte di quelle che in realtà sono gli elementi, e per questo onestamente non ho ancora una risposta.

Comunque, l'ultima volta che il compilatore passa per la GetElementKey è anche quella dove di fatto la classe ha finito il suo compito, e può quindi accingersi a restituire il nostro oggetto Section, memorizzato nel mio caso nella variabile config. Da questo momento in poi, con le altre proprietà e metodi della classe si può "navigare" tra gli elementi, richiedendo una IndexOf di un preciso elemento, o un preciso elemento partendo dalla sua chiave.

Ma torniamo, prima di concludere, all'ultima riga del codice della pagina aspx, quella con la Debug.WriteLine(config.urls["Microsoft"]); il nostro oggetto config essendo ora popolato con i dati presenti nel file di configurazione, mi consente di accedere tramite un indexer a disposizione ad un singolo elemento della collezione. In questo caso gli indexer sono due, uno per indice numerico e l'altro per chiave di tipo stringa.
L'indexer, al suo interno richiamando la BaseGet (che non fa altro che fare un ciclo tra gli elementi della collezione recuperata) confronterà il valore passato con la proprietà del ConfigurationElement il cui attributo IsKey è stato impostato su true. In caso positivo restituirà l'oggetto ConfigurationElement, diversamente un oggetto di tipo null.

Concludo con le due classi UrlsCollection e UrlsSection complete:

//Define the UrlsCollection that contains 
// UrlsConfigElement elements.
public class UrlsCollection : ConfigurationElementCollection
{
  
public UrlsCollection()
  {
  }
    
  
protected override String ElementName
  {
    
getreturn "address"; }
  }
      
  
public override ConfigurationElementCollectionType CollectionType
  {
    
get
    
{
      
return ConfigurationElementCollectionType.BasicMap;
    }
  }

  
protected override ConfigurationElement CreateNewElement()
  {
    
return new UrlConfigElement();
  }

  
protected override Object GetElementKey
            (ConfigurationElement element)
  {
    
return ((UrlConfigElement)element).Name;
  }
      
  
public new int Count
  {
    
get return base.Count; }
  }

  
public UrlConfigElement this[int index]
  {
    
get
    
{
      
if (index >= base.Count)
        
return null;
                    
      
return (UrlConfigElement)BaseGet(index);
    }
  }

  
new public UrlConfigElement this[string Name]
  {
    
get
    
{
      
return (UrlConfigElement)BaseGet(Name);
    }
  }

  
public int IndexOf(UrlConfigElement url)
  {
    
return BaseIndexOf(url);
  }
}

// Define a custom section containing 
// a simple element and a collection of 
// the same element. It uses two custom 
// types: UrlsCollection and 
// UrlsConfigElement.
public class UrlsSection : ConfigurationSection
{
  
public UrlsSection() 
  {
  }

  [ConfigurationProperty("urls", IsDefaultCollection = 
true)]
  
public UrlsCollection urls
  {
    
get
    
{
      
return (UrlsCollection)base["urls"];
    }
  }
}

Technorati Tags: , , ,


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Uno schema certo per i file di configurazione

January 18, 2006 10:46 by Blog Author

Cosa fare se si ha bisogno di avere uno schema certo che il nostro file di configurazione deve seguire? Che magari ci aiuti con il supporto dell'intellisense (gran bella invenzione davvero!) per mostrarci anche una lista di enumerati?

Semplice, associato al custom element della nostra custom section il parametro xmlns, passandogli un URI contenente lo schema XSD che vogliamo sia interpretato e utilizzato come linea guida. Così:

<UserSection xmlns="http://tempuri.org/PersoneSchema.xsd">

Generare uno schema XSD è semplice con il tool visuale messo a disposizione nell'IDE, basta solo sapere cosa scriverci dentro.

Il nostro pattern deve essere una cosa di questo tipo:

NomeSezione -> NomeElemento -> Attributi [-> Eventuali enumerati]

Che tradotto in xml, per un esempio sul quale stavo lavorando, diventa:

<xs:element name="Utente">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="Persona">
        <xs:complexType>
          <xs:attribute name="nome">
            <xs:simpleType>
              <xs:restriction 
base="xs:string">
                <xs:enumeration 
value="Andrea"/>
                <xs:enumeration 
value="Giuseppe"/>
              </xs:restriction>
            </xs:simpleType>
          </xs:attribute>
          <xs:attribute name="cognome" type="xs:string"/>
          <xs:attribute name="sposato" type="xs:boolean"/>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>
</xs:element>

Currently rated 1.0 by 1 people

  • Currently 1/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

I named parameters, questi benedetti

January 17, 2006 23:28 by Blog Author

In questo caso mi sono ritrovato a cercare di capire cosa potessero essere i named parameters, o meglio quello lo avevo capito, ma come, invece, li potevo creare.

Sulle prime pensavo che la descrizione che compariva al di sotto del tooltip box fosse una questione di tag per la commentazione del codice (Recommended Tags for Documentation Comments), però i conti non mi tornavano.

Gira che ti rigira, dopo un pò di analisi di alcune classi che esponevano questi named parameters, finalmente comprendo che altro non sono che delle banali proprietà (get, set), ma applicate a classi che ereditano da Attribute.

Quindi per intenderci


public class 
MyNewAttribute: Attribute {   

public 
MyNewAttribute(string Nome) {      // Positional parameter      
...   
}

public string Cognome {  // Named parameter
get {...}
set {...}
}
   

public string 
Nome {
get {...}
}
Per poter ereditare da Attribute, bisogna ricordarsi di referenziare la System.Configuration.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5