Macro vs Visual Source Safe

Recentemente ho avuto la “necessità” di creare una macro in Visual Studio che eseguisse delle operazioni di Replace in diversi file del progetto.
Come in genere accade in questi casi è sufficiente registrare la macro tramite:
Tools > Macros > Record TemporaryMacro
ed il gioco è fatto.

Anche se può sembrare assurdo, lanciando la macro non ottenevo il risultato sperato, bensì la seguente eccezione:
"The server threw an exception. (Exception from HRESULT: 0X80010105 (RPS_E_SERVERFAULT))"

A dir la verità ho subito pensato ad un bug nella macro - tale eventualità non è stata esclusa immediatamente anche se in realtà non avevo scritto neanche una riga di codice - o addirittura nell'IDE.
Il problema è causato, come mi è stato fatto notare da un mio collega, dalla mancata gestione in automatico del check out (il progetto è gestito tramite Visual SourceSafe) del file da modificare.
Sostanzialmente se i file sono preventivamente messi in check out allora la macro fa il suo lavoro - giustamente -.
A questo punto, è diventata una questione di principio, riuscire a risolvere il problema, nonostante la scarsa utilità della macro.
Nello caso specifico ho convertito, per semplicità, il tutto in tre macro distinte:

1. eseguire una ricerca nei file del progetto tramite regular expression;
2. eseguire il check out dei file in base ai risultati mostrati nella finestra Find Results 1, prodotti dal punto 1;
3. eseguire la funzione di Replace per ogni file in check out.

Forse la cosa più interessante da mostrare è il codice che ho scritto per svolgere il secondo punto:

   1: DTE.Windows.Item(Constants.vsWindowKindFindResults1).Activate()

   2: Dim resultsWin As Window = DTE.Windows.Item(Constants.vsWindowKindFindResults1)

   3: Dim sel As TextSelection = resultsWin.Selection

   4: If Not sel Is Nothing Then

   5:   sel.EndOfDocument(True)

   6:   Dim countLine = sel.CurrentLine

   7:   sel.StartOfDocument()

   8:   Dim lineStr As String

   9:   While (sel.CurrentLine < countLine)

  10:    sel.StartOfLine(False)

  11:    sel.EndOfLine(True)

  12:    lineStr = sel.Text

  13:    Dim reg As Regex = New Regex("c:.*(?=\(\d)", RegexOptions.IgnoreCase)

  14:    Dim line As String = reg.Match(lineStr).Value

  15:    If line.Length > 0 And DTE.SourceControl.IsItemCheckedOut(line) = False Then

  16:      DTE.SourceControl.CheckOutItem(line)

  17:    End If

  18:    sel.LineDown(True)

  19:  End While

  20: End If

  21: Dim win As Window = DTE.Windows.Item(Constants.vsWindowKindOutput)

  22: Dim ow As OutputWindow = win.Object

  23: ow.ActivePane.Activate()

  24: ow.ActivePane.OutputString("Completo!!!")

Anche se il codice parla abbastanza da solo, alcune righe meritano di essere un minimo commentate.
In particolare le prime tre righe consentono di poter analizzare il testo presente nella finestra dei risultati: Find Results 1 frutto della ricerca precedentemente eseguita.
Dopo aver calcolato il numero di righe presenti (riga 5 e 6) eseguo un ciclo estrapolando per ognuna l'eventuale path tramite una regular expression costruita ad hoc per il mio caso(riga 13).
In caso di match eseguo il check out del file richiamando il metodo CheckOutItem (riga 16).
Per concludere nella finestra di Output mostro un messaggio di fine operazione (riga 21, 22, 23, 24).

Read More »»

Vicessitudini sul deployment web

Chi sviluppa in Asp.Net 2.0 sa che è possibile lanciare una web application senza effettuare nessuna compilazione, in quanto di default ogni pagina viene compilata al "volo".
Premetto che in questo post non scriverò dei diversi svantaggi (di reali vantaggi sinceramente non sono ancora riuscito a trovarne) che presenta questa "metodologia" bensì di alcuni problemi con cui mi sono dovuto scontrare ultimamente.
Lo scenario è un grosso progetto web basato sull'architettura di DNN.
Per precompilare la parte web ho utilizzato l'add-in Web Deployment Project, il quale consente di compilare un sito web in uno ( alla Visual Studio .NET 2003) o più assembly.
Per avere una completa descrizione delle opzioni che offre questo add-in vi rimando al seguente articolo: Using Web Deployment Projects with Visual Studio 2005.
Inoltre per completezza è bene anche una lettura a VS 2005 Web Deployment Projects di Scott Guthrie.

Ho optato per un unico assembly, quindi ho lanciando il build.
Ho subito ottenuto un errore che di per sè non vuol dire praticamente nulla:
"aspnet_merge.exe" exited with code 1
Per avere un'informazione più utile bisogna modificare il livello di verbosity dell'output del MS-Build:
Tools > Options > Project and Solution > Build and Run
Dalla tendina MSBuild project build ouptut verbosity selezionate la voce Diagnostic o Detailed.
Ricordatevi di attivare la finestra di output:
View > Output
A questo punto è stato necessario modificare una serie di classi che presentavano namespace identici.
Questo provoca "collisioni" quando il tool cerca di generare un unico assembly. 
Primo consiglio quindi, è quello di definire sempre per le pagine un namespace in modo esplicito non facendo ricorso alla "tecnica" del copy & paste.

Il secondo passo è stato quello di copiare il progetto compilato nella web folder e lanciarlo, pensando di aver svolto il grosso del lavoro, ma invece ecco che spunta un altro errore:
Could not find a part of the Path XXX\App_GlogalResources\Locales.xml
Dopo una breve ricerca con "san google" trovo che una possibile soluzione consiste nel cancellare dalla root del progetto il file PrecompiledApp.config.
Erroneamente, senza pormi troppe domande, ho cancellato il suddetto file.

In effetti dopo questa semplice modifica si presenta un altro errore:
Could not find file 'c:\DotNetNuke.config'.
Debuggando è saltato fuori che alcune property dichiarate nell'assembly DotNetNuke non venivano settate.
Preciso che nel progetto queste property vengono settate nel file Global.asax, quindi mi sono chiesto perchè quest'ultimo non veniva in fase di esecuzione "analizzato".
Credo che il motivo sia collegato alla cancellazione del file PrecompiledApp.config.
Il file contiene il numero di versione del tool di precompilation ( 2 per Asp.Net 3.5) e se il sito è in grado di essere aggiornato:

   1: <precompiledApp version="2" updatable="true"/>

Tiene traccia delle opzioni di deploy dell'applicazione ed indica ad Asp.Net se deve compilare ogni file ad ogni richiesta:

L'attributo updatable impostato a true è applicabile alle pagine .aspx, agli user control ( .ascx), master file ma non al file Global.asax che viene compilato ( bin\App_global.asax.compiled).

L'ultima cosa che mi rimaneva da risolvere era quella di consentire alla cartella App_GlobalResources di risiedere nella directory di distribuzione.
L'unico workaround che sono riuscito ad adottare è stato quello di modificare nel file Localization.vb dell'assembly DotNetNuke, situato in:
\Library\Components\Localization
la costante ApplicationResourceDirectory come segue:

   1: Public Const ApplicationResourceDirectory As String = "~/DNN_GlobalResources"

Come sempre la curiosità è la stessa, conoscere altre eventuali soluzioni da quelle appena descritte.

Read More »»

Visual Studio Theme Generator

Un tool veramente carico che permette di creare in pochissimo tempo uno schema per Visual Studio.

Read More »»

Esplora Server

Esplora server ci consente, direttamente da Visual Studio, di conneterci a SQL Server o ad altri database. Per poter esaminare lo schema il primo passo è quello di creare una connessione al db.
In molti sanno che la connessione che viene creata in Esplora Server non necessita di essere salvata, in quanto ci pensa Visual Studio ma dove viene salvata?
Per rispondere a questa domanda, possiamo armarci di FileMon, utility free di Mark Russinovich e scoprirlo.
Filemon ci permette di monitorare le attività del sistema operativo in tempo reale, di conseguenza possiamo intercettare e visualizzare tutte le operazioni eseguite da Visual Studio quando generiamo una connessione attraverso Esplora Server.
Il filtro in FileMon:
Come si può notare dall'immagine, ho indicato di includere solo le operazioni di scrittura eseguite dal processo devenv.*(Visual Studio).
Una volta terminata la configurazione di Filemon, possiamo inserire una connessione attraverso Esplora Server
(Strumenti>Connetti al Database).

Ed ecco che FileMon ci mostra il path in cui vengono memorizzate la connessione appena creata:




Per Visual Studio 2005 il path è il seguente:
C:\Documents and Settings\utente\Dati applicazioni\Microsoft\VisualStudio\8.0\ServerExplorer
mentre nel caso di Visual Studio 2003:
C:\Documents and Settings\utente\Dati applicazioni\Microsoft\VisualStudio\7.1\ServerExplorer
Il file è DefaultView.SEView in cui Visual Studio crittografa le stringhe di connessione proprio per non essere facilmente disponibili a chi possiede i diritti di accedere alle directory appena indicate.

Read More »»

Versione del Framework

Tra i diversi modi possibili per riconoscere quale/i Framework è/sono installato/i su di una macchina credo che il più semplice è quello di usare il tool CLRVer a riga di comando.
Quest'ultimo è presente nella cartella sdk\v2.0\bin di VS 2005:
C:\Programmi\Microsoft Visual Studio 8\SDK\v2.0\Bin (esempio)
Tra i parametri possibili  potete scegliere all che mostra la versione del Framework usata da tutti quei processi in esecuzione che ne fanno uso.

Read More »»

Breakpoints condizionali

In Visual Studio 2005 come nel 2008 è possibile inserire dei breakpoints condizionali:

• F9 per inserire il breakpoint,
• Tasto destro sul break,
• Selezionare la voce Condizione,
• A questo punto compare una dialog box in cui definire la condizione.

 

Nel caso di Visual Studio 2003 la procedura di inserimento è leggermente diversa:

• Tasto destro sulla riga di codice su cui è stato inserito il breakpoint,
• Selezionare la voce Proprietà punto di interruzione,
• Selezionare la voce Condizione.

 

 

Read More »»

Visual Studio in black

Per dare una veste "dark" a Visual Studio, i passi da seguire:
Strumenti => Opzioni => Ambiente => Tipi di carattere e colori => Testo
Indicare alla voce Primo piano elemento il colore bianco mentre alla voce Sfondo elemento il colore nero.

Read More »»

DB2: Dataset tipizzati

Sul plugin DB2 abbiamo discusso qui e qui, questa volta invece vedremo come generare Dataset tipizzati utilizzando le stored procedures.
I Dataset tipizzati sono entità logiche derivate dalla classe Dataset create attraverso il designer di Visual Studio.
Quando si genera un Dataset tipizzato viene creato un file schema XML  all'interno della directory App_Code.
A run-time il Framework si occupa di recuperare queste informazioni contenute nello schema e di generare le varie classi.
A questo punto possiamo generare una stored procedures:

Per generare un Dataset tipizzato da VS 2005 basta scegliere l'opzione Add new item e selezionare la voce DataSet:

Dopo aver aggiunto il Dataset compare il wizard TableAdapter, quest'ultimo è un contenitore di oggetti DataTable, nel caso specifico useremo la stored procedure creata precedemente:


Alla fine del wizard l'IDE mostra attravero l'oggetto TableAdapter la struttura della tabella, indicando informazioni sulle colonne, sulle chiavi, eventuali relazioni ecc:

Il codice per usare queste entità è estremamente semplice:

Public Function GetDb(ByVal valueNome As String) As DsTest.PROCEDURADSDataTable
  Dim dt As DsTest.PROCEDURADSDataTable = New DsTest.PROCEDURADSDataTable()
  Try
    Dim da As DsTestTableAdapters.PROCEDURADSTableAdapter = New DsTestTableAdapters.PROCEDURADSTableAdapter()
    dt = da.GetData(valueNome)
  Catch ex As Exception
    'Log error
  End Try
  Return dt
End Function

Di contro però, i Dataset tipizzati non sono adatti per gestire grosse quantità di dati poichè si ha un notevole calo di prestazioni.

Read More »»

Debug JScript con VS 2003 e VS 2005

Per il debug di script javascript ho sempre fatto affidamento all'estensione di Firefox: FireBug, ma è possibile farlo anche con solo VS 2003 o VS 2005.
Dopo aver attivato l'opzione su Internet Explorer: Debugging degli script( Strumenti => Opzioni Internet => Avanzate => Esplorazione), ed aver lanciato in modalità debug l'applicazione Asp.Net dall'ambiente di sviluppo VS 2003:


si può attivare Script Explorer( Ctrl+Alt+N):

e quindi poter inserire breakpoints nella sezione script:

Read More »»

DB2: Debugging stored procedures

Dopo il precedente post ho notato che è possibile tramite il wizard Aggiungi nuova procedura SQL con Designer attivare il debug su stored procedure:

Dopo aver attivato la modalità si può lanciare la stored procedure direttamente dal wizard:

Nel caso specifico accetta un parametro di tipo VarChar:

adesso si può procedere con F10 e Watch per controllare il contenuto di una determinata variabile:

Read More »»

Debugging VS 2005 con Wii

...senza parole!!

Read More »»

Cheat Sheets

Una raccolta veramente interessante di Cheat Sheets, dalla formattazione di stringhe, alle regular expression, ai css e tanto altro. Da stampare.

Read More »»