Reso disponibile da Microsoft un interessante set di estensioni per Visual Studio 2005, inizialmente presenti solo nell’SDK, sicuramente utili a rendere più agevole la vita dello sviluppatore. Sto parlando di Microsoft Visual Studio 2005 IDE Enhancements, disponibile per il download da qualche giorno, che comprende: a) una serie di snippet code per il linguaggio C++; b) Indexer Find, un tool basato su Index Service per migliorare le ricerche nell’IDE; c) Super Diff Utility, utility per confrontare il contenuto di 2 files evidenziando le differenze (stile Visual Source Safe); d) Event Toaster Utility, per aggiungere eventi di notifica legati all’IDE, es. notifica nella tray area dopo ogni build eseguita con successo (molto carina); e) Source Code Outliner, un tool che visualizza una lista ad albero dei tipi e relativi membri. Tutto troppo bello ed utile, se non fosse che: a) il Source Code Outliner si blocca indefinitivamente nel tentativo di aggiornare il proprio contenuto; b) l’IDE si blocca imprevedibilemente (ho l’impressione che l’Indexer Find blocchi la CPU per troppo tempo nel tentativo di aggiornare l’indice delle ricerche; c) non è possibile abilitare/disabilitare selettivamente ogni estensione, quindi o tutto o niente. Morale della favola: ho dovuto disinstallare il tutto con la stessa velocità con cui lo avevo installato, a causa dei blocchi frequenti dell’IDE e del Source Code Outliner. Mi piacerebbe conoscere l’eventuale esperienza di altri sviluppatori sull’argomento. I commenti sono aperti e graditi.
Month: October 2006
GUISA – Nuovo user group per architect
Finalmente uno user Group di architetti dove si parla solo esclusivamente di architetture, pattern, ecc. ecc.
Io ne sentivo sinceramente la mancanza, e, non c’è da dubitarne, lo terrò costantemente sotto osservazione.
Sto parlando di GUISA (Gruppo Utenti Italiani Solution Architect)
File "refresh" e compilazione lenta in Visual Studio 2005
Aggiungendo una semplice reference binaria ad un progetto in VS 2005 (es. un Web Site Project), vale a dire selezionando direttamente una class library (file *.dll) da Add Reference\Browse, viene automaticamente creato nella directory bin del progetto un file con lo stesso nome del componente (la dll) e l’estensione refresh, es. mydll.refresh se aggiungo la reference mydll.dll. Questo è un semplice file di testo; infatti aprendolo con Notepad è possibile leggerne il contenuto, ovvero il path relativo in cui è contenuta la dll che abbiamo referenziato. A cosa serve esattamente questo file ? Serve a tener aggiornata la bin del progetto con l’ultima versione della dll disponibile al path indicato. Infatti, ad ogni compilazione VS verifica che al percorso indicato nel file refresh non sia disponibile una versione più aggiornata della dll, e, in caso affermativo, la copia nella directory bin del progetto, sollevando lo sviluppatore dall’onere di copiare manualmente la dll referenziata E’ possibile che più progetti nella stessa solution referenzino la stessa dll (ad es. una dll condivisa della ns. applicazione). In questo caso, è necessario assicurarsi che la dll referenziata dai vari progetti (la dll shared) abbia lo stesso numero di versione in tutti i punti in cui è referenziata. In caso negativo, VS “perderà tempo” durante la compilazione assumendo che della stessa dll sia disponibile una versione più aggiornata, provocando un notevole rallentamento della compilazione; per intenderci, può trascorrere anche qualche minuto prima che i risultati della compilazione inizino ad apparire nella finestra Output. Per maggior approfondimento è utile questo dettagliatissimo post di ScottGu
xp_cmdshell, appunti di utilizzo
Non è un semplice tip, infatti sottintende parecchio di più. Sto parlando di come impedire ad una istanza di Sql Server di avviarsi utilizzando…..sql stesso, reperibile sul sito della community .netSide, e scritto da Francesco Quaratino, disponibile qui Per quanto possa sembrare a prima vista strano voler impedire ad una istanza di Sql di avviarsi, ritengo tuttavia plausibile uno scenario reale in cui questa situazione possa verificarsi. Ad esempio, potremmo utilizzare una istanza di Sql solo per motivi amministrativi, e quindi solo un DBA può usufruire del servizio, ma è comunque necessario garantire agli utenti un accesso amministrativo al PC per altri motivi; infatti, in questo scenario è necessario assicurarsi che l’utente amministratore, ma non DBA, non possa avviare l’istanza.
L’utilizzo della store xp_cmdshell, tuttavia, è disabilitato di default in Sql Server 2005 per motivi di sicurezza, come spiegato esaurientemente in questo post di Tara Kizer (un blog assolutamente da leggere per tutti gli aficionados di Sql); occorre quindi abilitarne prima l’uso attraverso “sp_configure” oppure utilizzando il tool Surface Area Configuration.
Ottimo tip e ottimo blog.
Articolo sui servizi "provider based"
E’ disponibile il mio primo articolo per il nuovo user group del sud Italia dotnetSide, dedicato alle tecnologie Microsoft con particolare attenzione al .NET Framework. L’articolo è una panoramica sul Provider Model di ASP .NET 2.0, e focalizza l’attenzione soprattutto su come creare un proprio servizio applicativo ed agganciarvi i providers di implementazione degli algoritmi. Qualsiasi feedback sull’argomento è gradito.
BizTalk o Workflow Foundation ?
Mi è capitato spesso di assistere a dialoghi tecnici del tipo: ‘ma conviene usare Workflow Foundation oppure BizTalk per quel particolare progetto ?’. A prima vista questi 2 prodotti sembra che si sovrappongano; infatti, semplificando parecchio, ambedue forniscono funzionalità per costruire un processo basato su workflow. Ma è solo una impressione poichè sono profondamente diversi. Un utilissima check-list che aiuta a capire quale strumento si adatta meglio allo specifico progetto è disponibile attraverso questo post di Irena Kennedy. La checklist inquadra i requisiti che giustificano l’uso di BizTalk, oppure in loro assenza di Workflow Foundation.
Molto interessante questo estratto:
……. Biztalk is product that provides scalable deploying and hosting model, built-in integration with many applications and protocols, a runtime configurable instrumentation framework, central management, monitoring and tracking, message mapping and transformation services, batch processing, publish/subscribe mechanism, engine throttling, scale out support, reliability, fail over, deployment tools, business rules engine, etc.
WinWF is a set of class libraries, it’s a developer framework used to build workflow into custom applications.
So, are you creating an intra-application workflow (page flow wizard, control flow, a business logic implementation that has multiple activities, state machine, etc)? Will your application host the workflows itself? If yes, WinWF will likely satisfy your needs.
Mi piacerebbe conoscere il pensiero dell’amico Mighell sull’argomento, che di Workflow Foundation sicuramente ne sa parecchio, visto l’evento del maggio scorso, l’ultimo webcast, e soprattutto il prossimo workshop “.NET Present & Future” che si terrà a Bari il prossimo 26 Ottobre.
Single Sign On & sezione <machineKey>
Girovagando tra la rete mi sono imbattuto in questo utilissimo tool utilizzabile on-line per la generazione della sezione <machineKey> del web.config, nel caso, molto concreto oggigiorno, si voglia implementare il meccanismo di SSO (Single Sign On) per le proprie applicazioni. In sostanza si tratta di effettuare il login una sola volta ed essere riconosciuto da n applicazioni che condividono in questo modo il contesto di sicurezza dell’utente, con indubbi benefici.
Delete Subdirectory & AppDomain recycle
Tra le cause che provocano lo scaricamento immediato dell’AppDomain di una applicazione ASP .NET 2.0 è presente anche la cancellazione di una sub-directory della applicaizione principale, operata attraverso Windows Explorer. Infatti, dopo tale operazione nell’Event Viewer del server appare un messaggio di tipo informativo.
Questo comportamento è differente rispetto a ad ASP.NET 1.0/1.1, dove la stessa operazione non produceva assolutamente nulla nè l’engine veniva notificato dell’evento; quindi il contenuto della directory cancellata continuava ad essere considerato valido con il potenziale rischio di errore a run-time.
Il team di sviluppo di ASP .NET 2.0 ha considerato un bug il comportamento delle versioni precedenti (a mio avviso giustamente) ed ha modificato il comportamento come fosse un bug-fixing, cioè piuttosto di rischiare di servire una pagina non più esistente viene ora scaricato l’intero AppDomain. L’unica nota stonata è che nel messaggio scritto nell’ Event Viewer l’applicazione risulta scaricata a causa di “reason unknown” che non permette di capire immediatamente la causa, invece di un bel “reason:directory xyz deleted”