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 <remove name="Documentation"/>.
Questa <remove name ... dovrebbe trovarsi all'interno della coppia di tag element <protocols></protocols>. 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:
<protocols>
<!-- This disables the service help and generated WSDL pages. -->
<remove name="Documentation"/>
</protocols>
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.
***************************
<configuration>
<configSections>
<sectionGroup name="SharePoint">
<section name="SafeControls" type="Microsoft.SharePoint.ApplicationRuntime.SafeControlsConfigurationHandler, Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<section name="RuntimeFilter" type="System.Configuration.SingleTagSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<section name="WebPartLimits" type="System.Configuration.SingleTagSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<section name="WebPartCache" type="System.Configuration.SingleTagSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<section name="WebPartWorkItem" type="System.Configuration.SingleTagSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<section name="WebPartControls" type="System.Configuration.SingleTagSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<section name="SafeMode" type="System.Configuration.SingleTagSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<section name="OnlineLibrary" type="System.Configuration.SingleTagSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</sectionGroup>
</configSections>
<SharePoint>
<SafeMode MaxControls="50" CallStack="false" />
<WebPartLimits MaxZoneParts="50" PropertySize="1048576" />
<WebPartCache Storage="CacheObject" />
<WebPartWorkItem Timeout="7000" />
<WebPartControls DatasheetControlGuid="65BCBEE4-7728-41a0-97BE-14E1CAE36AAE" />
<!--
SafeControl Attributes:
Assembly="[Assembly]" - The .NET assembly in which the control is contained. This attribute can also contain version, culture, and public key token information.
Namespace="[Namespace]" - The .NET namespace in which the control is defined.
TypeName="[Typename]" - The .NET class name of the control. You can type an asterisk (*) wildcard character to indicate all TypeNames in a Namespace.
Safe="[True|False]" - Specifies whether a Web Part or Web Form Control is safe and can be displayed on a Web Parts Page. This attribute is True by default.
-->
<SafeControls>
<SafeControl Assembly="System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.WebControls" TypeName="*" Safe="True" />
<SafeControl Assembly="System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.HtmlControls" TypeName="*" Safe="True" />
<SafeControl Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint" TypeName="*" Safe="True" />
<SafeControl Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WebPartPages" TypeName="*" Safe="True" />
<SafeControl Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WebControls" TypeName="*" Safe="True" />
<SafeControl Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.ApplicationPages" TypeName="*" Safe="True" />
<SafeControl Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.SoapServer" TypeName="*" Safe="True" />
<SafeControl Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Meetings" TypeName="*" Safe="True" />
</SafeControls>
<OnlineLibrary Url="http://r.office.microsoft.com/r/hlidAwsGallery" />
</SharePoint>
<system.web>
<securityPolicy>
<trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\config\wss_mediumtrust.config" />
<trustLevel name="WSS_Minimal" policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\config\wss_minimaltrust.config" />
</securityPolicy>
<httpHandlers>
<add verb="*" path="/_vti_bin/*.aspx" type="System.Web.UI.PageHandlerFactory, System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<add verb="*" path="*.aspx" type="Microsoft.SharePoint.ApplicationRuntime.SharePointHandlerFactory, Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</httpHandlers>
<customErrors mode="On" />
<httpRuntime maxRequestLength="51200" />
<authentication mode="Windows" />
<authorization>
<allow users="*" />
</authorization>
<identity impersonate="true" />
<httpModules>
<clear />
<add name="OutputCache" type="System.Web.Caching.OutputCacheModule" />
<add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule" />
<!-- <add name="Session" type="System.Web.SessionState.SessionStateModule"/>-->
</httpModules>
<globalization fileEncoding="utf-8" />
<compilation batch="false" debug="false" />
<pages enableSessionState="false" enableViewState="true" enableViewStateMac="true" validateRequest="false" />
<trust level="WSS_Minimal" originUrl="" />
<machineKey validationKey="798AE146642B43D263665652E9F2FA50878F536ACE3A2F14" decryptionKey="4646E5212B66ED41E013099DC04DCB77351BAF45E0B1E424" validation="SHA1" />
</system.web>
</configuration>