agosto 2006 - Posts
Articolo week.it che riporto per intero:
Come abbiamo avuto modo di accennare nell’articolo su week.it numero xxx, SSIS è il nuovo strumento nella suite Business Intelligence di SQL Server 2005 che rappresenta l’evuluzione (e non semplicemente una nuova versione) dei DTS (Data Transformation Services) di SQL Server 2000: all’interno di un package è possibile definire il flusso che i dati devono seguire dalla sogente alla destinazione attraverso container, task e regole di trasformazione.
Esiste un altro tipo di container denominato Event Handler e viene eseguito quando si scatena un evento: ad esempio si può creare un event handler che viene eseguito quando si scatena un errore su una task specifica o sull’intero package.
Il motore di SSIS supporta transazioni, logging e checkpoint da cui far ripartire l’esecuzione in caso di fallimento di alcune operazioni.
Le configurazioni necessarie all’esecuzione di un package possono essere memorizzate separatamente (in file XML) rispetto al package stesso consentendo diverse configurazioni sullo stesso package: il runtime, all’escuzione del package, leggerà i valori di configurazione e li applica al package stesso. La configurazione può contenere costanti applicative come ad esempio le connection string verso le sorgenti o le destinazioni dei dati oppure variabili modificabili dal flusso definito. Nel secondo caso i valori iniziali delle variabili vengono letti dal file di configurazione e portati in memoria per l’esecuzione del package; tramite le cosiddette property expression è possibile accedere in lettura/scrittura a tali variabili; si utilizza una sintassi C-like per l’accesso alle variabili.
Le variabili possono essere definite a diversi livelli: in generale una variabile vive all’interno del container che la definisce: ad esempio, se una variabile è definita all’interno di un sequence container, sarà possibile utilizzarla solo dalle task interne al sequence container, viceversa, se una task è defiita a livello di package sarà disponibile a tutti i container e task del package stesso.
Durante una fase di debug, dal designer SSIS (all’interno di Visual Studio 2005), è possibile controllare il flusso dei dati, ispezionare o modificare il contenuto delle variabili. Il designer non è altro che un client particolare che chiede al runtime di SSIS di eseguire le operazioni.
SSIS installa un servizio denominato appunto SSIS Service che consente di gestire i package durante il runtime: consente di monitorare i package in esecuzione, importare e esportare package fra SQL Server e il file system, e gestire l’organizzazione delle directory. Il servizio è disabilitato per default al termine dell’installazione di SQL Server, è necessario farlo partire a mano se vogliamo utilizzarlo: il motivo per cui il servizio viene montato in stato di disabled è semplice: in realtà il servizio non esegue i package, serve solamente a monitorarne l’esecuzione. Chi esegue i package è il runtime engine di SSIS.
Ho pubblicato fra gli articoli DevLeap questo pezzo sui componenti di replica di SQL 2005 Mobile (valido anche per SQLCE 2.0 a parte qualche nome di DLL). E' un articolo pubblicato su Computer Programming n 152.
Ecco il link. Buona lettura: http://blogs.devleap.com/articolidevleap/archive/2006/08/20/13266.aspx
Domenica parto per una settimana di completo relax che implica staccare completamente PC, portatile, palmari vari, cellulare.
Articolo week.it di introduzione al DataFlow di SSIS.
Come abbiamo avuto modo di accennare in altri articoli su questa rivista, SSIS ha come obiettivo primario quello di fornire uno strumento per “muovere” i dati da una sorgente a una destinazione.
Un Data Flow può contenere tre tipologie di componenti: sorgenti, destinazioni e trasformazioni.
Una sorgente è un componente senza nessun input che serve a definire l’output verso il flusso di dati: in pratica una sorgente estrae i dati da un fonte esterna (file xml, file di testo, tabelle SQL e così via) e le mette a disposizione del flusso dei dati. E’possibile definire una sorgente custom utilizzando gli strumenti di scripting basati su Visual Basic.NET.
Una destinazione accoglie come input il risultato dell’eseguzione di task all’interno del package e invia le informazioni all’esterno del package: la destinazione reale può essere una tabella SQL Server, un file di testo, un file xml e così via. Una destinazione può anche non agire su risorse fisiche come file o tabelle, ma creare in memoria una struttura dati come ad esempio un recordset ADO oppure fornire informazioni ai servizi di Data Mining. E’ possibile definire destinazioni custom utilizzando, come per le sorgenti, gli strumenti di scripting basati su Visual Basic.NET.
Il package più banale da progettare contiene semplicemente una sorgente e una destinazione e consente di “muovere” i dati in modo simmetrico. Molto spesso però occorre eseguire una qualunque forma di mapping o aggregazione o semplicemente concatenazione di campi dalla sorgente verso la destinazione: per effettuare queste operazioni, è possibile, in prima battuta, appoggiarsi ai componenti di trasformazione: questi componenti accettano un input e producono un output e al loro interno, contengono le regole (da semplice a complesse) per trasformare questi dati; ancora una volta il caso può semplice può essere una conversione di tipo fra un dato di tipo numerico della sorgente a un dato di tipo stringa nella destinazione, oppure eseguire dei calcoli e inserire nella destinazione il risultato. E’ possibile eseguire operazioni anche di tipo merge fra più sorgenti dati verso un'unica destinazione oppure scriversi le proprie logiche di trasformazione ricorrendo al linguaggio Visual Basic.NET.
In questi esempi abbiamo banalizzato il più possibile il flusso dei dati partendo da una sorgente, applicando semplici trasformazioni per ottenere dati da inserire nella destinazione. Combinando questi elementi nel Data Flow è possibile costruire package molto complessi che prelevano dati da più sorgenti, passano da una serie numerosa di trasformazioni e aggregazioni in sequenza o in parallelo per produrre diversi documenti di output.
Articolo week.it pubblicato in maggio:
Il 6 Aprile scorso Microsoft ha annunciato un “nuovo” prodotto denominato Sql Everywhere che vedrà la luce nel corso del 2006. Questo annuncio ha creato molta confusione nel mondo delle applicazioni smart client: che database usare per la mia applicazione desktop ? SQL Express o SQL Everywhere ? In cosa differiscono? Obiettivo dell’articolo e far luce su questi punti.
Ad oggi esiste una versione ridotta (notevolmente ridotta) di SQL Server per l'ambiente Windows CE denominata SQL 2005 Mobile. L'obiettivo del prodotto è avere una struttura dati identica a SQL Server sui dispositivi Pocket PC (o comunque basati su Windows CE) e un motore di accesso ai dati utilizzabile nativamente con ADO o ADO.NET (con la stessa filosofia del desktop); SQL Mobile fornisce due metodologie di replica dei dati con il database centralizzato: Merge Replication come anonymous subscriber verso SQL Server oppure una tecnica meno automatizzata denominata Remote Data Access. SQL 2005 Mobile gira in-process rispetto all’applicativo che la utilizza: non è quindi un servizio come il fratello maggiore. Inoltre, espone due tecniche di accesso ai dati non esistenti su SQL Server: Base Table Cursor che consente di aprire un cursore su una tabella in base a indici e range e consente di eseguire Seek dirette sul record in base ad un indice; SqlCeResultSet è invece una classe del .NET Compact Framework 2.0 che consente di ottenere un cursore aggiornabile e/o sensitive su una query: questa classe è agganciabile (binding) direttamente come DataSource ai controlli della user interface. SQL 2005 Mobile non supporta stored procedure, non supporta trigger, non supporta User Defined Type e tecnologie legate a XML e infine non ha i meccanismi di security basati su Login, User e Role.
SQL 2005 Mobile può essere utilizzato gratuitamente su ambiente Windows CE, sul Tablet PC e sui nuovi Ultra-Mobile PC; una limitazione sulla licenza non ne consente l’utilizzo su macchine XP tradizionali se non ai fini di test.
L’annuncio del 6 Aprile di Sql Everywhere fa pensare ad un nuovo prodotto: in realtà SQL Everywhere è SQL 2005 Mobile senza la limitazione sull’utilizzo su piattaforma XP tradizionale; non è quindi un nuovo prodotto e verrà utilizzato con il provider nativo System.Data.SqlServerCe; espone tutte le funzionalità accennate in questo articolo e di cui abbiamo avuto modo di parlare in articoli precedenti e sul sito www.thinkmobile.it.
Si sovrappone in parte a SQL Express, la versione gratuita del motore di SQL Server, se pensato come soluzione per piattaforma XP e Tablet PC (e anche UMPC); SQL Express però non gira su dispositivi basati su Windows CE. SQL Express quindi non si adatta a scenari mobile multi-device dove gli utenti possono essere dotati di Tablet PC, portatili e/o Pocket PC e SmartPhone. SQL Everywhere, invece, gira su tutte queste piattaforme ed è pensato per un utilizzo locale da parte delle applicazioni. Torneremo sull’argomento, magari con un test sulle performance, non appena verrà rilasciata una CTP.
Una demo dettagliata su tutte le metodologie di accesso ai dati e relative performance è disponibile su www.thinkmobile.it/files/default.aspx.
Esistono due versioni del .NET CF 2.0 SP1 (oltre a quelle destinate al Platform Builder):
1) Web download: monta sopra al .NET CF 2.0 nel senso che disinstalla il precedente e successivamente installa il tutto da zero. Si può installare anche senza avere il .NET CF 2.0.
2) VS 2005 Patch: necessita del .NET CF 2.0 installato sulla macchina e esegue solo un aggiornamento.
Se avete montato (visto che è uscito prima) il web download, per installare la VS 2005 patch occorre rimuovere da Control Panel il .NET CF 2.0 SP1, reinstallare dal CD originale di VS 2005 (sotto vs\wcu\NetCF trovate il .MSI) e poi applicare la patch.
In entrambi i casi:
Hanno deciso di spostare la directory di installazione da C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0 a C:\Program Files\Microsoft.NET\SDK\CompactFramework\v2.0.
Questo spostamento fa si che il .NET CF 1.0 (comunque utilizzabile da VS 2005 per creare applicazioni 1.0) rimanga nelle sua directory sotto Visual Studio 8, mentre il 2.0 sia andato a finire da tutt'altra parte.
Molti SDK esterni (vedi InTheHand) e in particolare Symbol SDK 1.3 rimangono purtroppo nella directory iniziale e da quì il casino: ad esempio il Symbol SDK 1.3 non funziona più in quanto VS 2005 quando cerca di fare il deploy del CAB non trova più niente.
Il workaround generale è copiare a mano tutti (tutti significa tutte le dll e i .xml:-) nella nuova location. Al termine potete cancellare i file dalle directory di Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0.
Mi direte: pirla...potevi fare una move, no ?
Purtroppo Si e No. Occorre che nella directory iniziale rimanga la struttura delle directory compresi i cab, mentre i file dll e xml possono essere tranquillamente spostati. Per questo consiglio di non far move dell'albero da Windows Explorer, altrimenti saltano i riferimenti interni al SDK.
Quindi in pratica copia di tutta la struttura e se volete, cancellazione dei file interni.
Hope useful
Articolo da me pubblicato su week.it che riporto:
Il servizio, nativo in SQL Server 2005, consente di gestire messaggi asincroni all’interno di un database, fra istanze diverse di database o fra SQL Server diversi su macchine separate. Il modello di funzionamento è simile a altri prodotti di gestione messaggi basata su code (Microsoft Message Queue ad esempio). L’obiettivo è semplice: aumentare il livello di scalabilità delle applicazioni front-end rimandando al back-end il grosso del lavoro. Proviamo a spiegarci con un esempio classico: su un sito di commercio elettronico, a fronte di un acquisto, deve partire un processo di generazione dell’ordine che sicuramente comporta operazioni sul magazzino, la generazione delle informazioni sulla spedizione, il controllo della disponibilità finanziaria del cliente e probabilmente varie altre operazioni. Se queste operazioni sono eseguite dalla pagina di check-out viene bloccato un thread dell’applicazione ASP.NET per tutta la durata del processo e vengono eseguiti dei lock sulle varie tabelle che possono rallentare altri ordini da processare; inoltre, tutte le risorse coinvolte devono essere disponibili al momento dell’acquisto; non ultimo la comunicazione fra l’applicazione e le risorse deve essere molto efficiente per non rallentare appunto l’intero front-end. In ASP.NET 2.0, tramite l’attributo Async è possibile semplicare il lavoro da fare (nel codice per la versione 1.x) per liberare il thread e renderlo disponibile per le successive richieste. Per una panoramica sulla problematica relativa a thread e thread pool si veda http://blogs.devleap.com/articolidevleap/archive/2006/01/12/6505.aspx. Attributo Async a parte, spostare il lavoro sul back-end libera il front-end dall’onere di processare un acquisto. L’idea è molto semplice: quando si deve processare un acquisto, il front-end esegue il minor lavoro possibile inserendo le informazioni inerenti in un database; il front-end analizzerà queste informazioni e procederà con il processo di generazione “vero” dell’ordine. Dove sta la novità? Da sempre possiamo creare strutture (tabelle) che accolgano queste informazioni e applicazioni che leggono tali tabelle per eseguire dietro le quinte il processo relativo.
L’obiettivo di SQL 2005 Service Broker è fornire tutta l’infrastruttura necessaria per gestire questo flusso. Il prodotto mette a disposizione, direttamente nel database, i servizi necessari e le instruzioni T-SQL per creare i messaggi che contengono le informazioni per il processo da eseguire, le code che accettano tali messaggi, i servizi per garantire l’arrivo e l’ordine di arrivo dei messaggi, i servizi per garantire la transazionalità delle operazioni fra code e tabelle tradizionali. In pratica il prodotto elimina la necessità di creare le strutture e soprattutto i processi che garantiscono affidabilità alla soluzione. Il prodotto può essere visto come rivale di MSMQ (che fornisce le stesse funzionalità come servizio Windows): quale scegliere ? Dipende dall’applicazione e dal contesto: avere il supporto interno al database rende più semplice l’amministrazione, il backup e restore (i messaggi e le strutture fanno parte del db quindi rientrano nel backup), la manutenzione in quanto tutto è residente in un database e sicuramente non implica la conoscenza di prodotti esterni. D’altro canto MSMQ è utilizzabile in contesti dove non viene impiegato SQL Server 2005, è integrabile con prodotti di terze parti come MQSeries di IBM, è utilizzabile da client Windows CE dove per adesso SQL 2005 Mobile Edition non offre tali servizi.
Dopo il post di Marco che annuncia una prima uscita pubblica, per chi volesse iniziare a usare SandCastle (July CTP 2006) senza impazzire lanciando tutti i comandi a manina (ovviamente pià avanti nello sviluppo il tutto verrà integrato con VS 2005) ho creato un .bat da lanciare come Post-Build Event (occhio ai parametri da passare) che appunto automatizza il processo. Ecco i passi da seguire:
Dopo l'installazione di SandCastle troverete una directory c:\program files\sandcastle al cui interno sono presenti i vari tools per la generazione dei file .chm, diversi .xsl per le trasformazioni dei vari file xml che devono essere generati duranti il processo. Creare il .bat che automatizza i 10 passi per creare l'help è abbastanza semplice. Quello che volevo ottenere però è la parametrizzazione del .bat per evitare di dover creare a mano un .bat per ogni progetto.
1) Installare SandCastle: download http://www.microsoft.com/downloads/details.aspx?familyid=E82EA71D-DA89-42EE-A715-696E3A4873B2&displaylang=en
2) Installare HTML Workshop: download http://msdn.microsoft.com/library/default.asp?url=/library/en-us/htmlhelp/html/hwMicrosoftHTMLHelpDownloads.asp
N.B.Per prima cosa occorre copiare la directory di SandCastle fuori dalla Program Files in quanto sviluppando come non-admin (vero che lo siete tutti !!!) non si può accedere a tale directory. Per creare l'help occorre anche il HtmlWorkshop versione 1.4 e anch'esso si installa in Program Files. Nel mio caso ho spostato entrambi i tool il tutto sotto: c:\applications\download. Ovviamente mettete il tutto dove volete sul vostro pc: se cambiate questa dir fate un find/replace sia nel .bat allegato che nel .config allegato.
3) All'interno del progetto Visual Studio create un file sandcastle.config il cui contenuto è allegato in fondo a questo post.
4) All'interno del progetto Visual Studio create un file SandCastleJuly2006.bat (ho creato la versione perchè sicuramente cambierà qualcosa). Il file accetta alcuni parametri da inserire come Post-Build Event nelle proprietà del progetto: questo consente di avere un bat comune a tutti i progetti. Ecco il contenuto del file .bat
cd %1
MRefBuilder %2.dll /out:reflection.org
pause
XslTransform "c:\applications\downloaded\Sandcastle\ProductionTransforms\AddOverloads.xsl" reflection.org | XslTransform "c:\applications\downloaded\Sandcastle\ProductionTransforms\AddGuidFilenames.xsl" /out:reflection.xml
pause
XslTransform "c:\applications\downloaded\Sandcastle\ProductionTransforms\ReflectionToManifest.xsl" reflection.xml /out:manifest.xml
pause
if not exist Output mkdir Output
if not exist Output\html mkdir Output\html
if not exist Output\art mkdir Output\art
if not exist Output\scripts mkdir Output\scripts
if not exist Output\styles mkdir Output\styles
copy "c:\applications\downloaded\Sandcastle\Presentation\art\*" Output\art
copy "c:\applications\downloaded\Sandcastle\Presentation\scripts\*" Output\scripts
copy "c:\applications\downloaded\Sandcastle\Presentation\styles\*" Output\styles
pause
copy %3sandcastle.config .
pause
BuildAssembler /config:sandcastle.config manifest.xml
pause
XslTransform "c:\applications\downloaded\Sandcastle\ProductionTransforms\ReflectionToChmContents.xsl" reflection.xml /arg:html=Output\html /out:%2.hhc
pause
move *.hhc Output
copy %3%2.hhp Output\.
cd Output
pause
"c:\applications\downloaded\HTML Help Workshop\hhc" %2.hhp
cd %3
I vari "pause" servono come controllo per verificare l'output dei vari step.
Come si nota al file .bat vegono passati alcuni parametri. Se volete lanciare il bat a mano occorre passare DirectoryTarget (la bin\debug o bin\release), il Nome della dll o exe da utilizzare, la directory del progetto VS.
Per automatizzare questi parametri e soprattutto ottenere la creazione automatica ho utilizzato un post-build event sul progetto VS 2005: il comando per lanciare il .bat dal post build event è:
$(ProjectDir)SandCastleJuly2006.bat $(TargetDir) $(TargetName) $(ProjectDir)
In questo modo vengono passati i parametri corretti senza doverli impostare a mano: soprattutto spostando il progetto VS, rinominandolo oppure modificando qualunque parametro in VS non occorre diventare pazzi ad aggiornare i .bat.
5) Creare un file (purtroppo a mano) nomeprogetto.hhp all'interno del progetto Visual Studio. Questo file server per il lancio di hhc.exe e contiene il path del file .chm da creare e il path al file .hhc da utilizzare come riferimento (questo file viene creato durante il processo dal file .bat). Ecco il contenuto del file .hhp (è un normalissimo file di testo):
[OPTIONS]
Compatibility=1.1 or later
Compiled file=DevLeap.Library.Mobile.Dal.Sql2005Mobile.chm
Contents file=DevLeap.Library.Mobile.Dal.Sql2005Mobile.hhc
Display compile progress=No
Language=0x409 English (United States)
[FILES]
art\*.gif
html\*.htm
scripts\*.js
styles\*.css
[INFOTYPES]
6) Abilitare nelle proprietà del progetto la generazione dei commenti: per default VS crea un file nomeprogetto.xml. Il mio bat utilizza questo nome: se preferite modificare la sezione del file sandcastle.config evidenziata in giallo (il cui contenuto per intero è allegato più avanti):
<!--
Copy in comments -->
<component type="Microsoft.Ddue.Tools.CopyFromIndexComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<index name="comments" value="/doc/members/member" key="@name" cache="100">
<data files="DevLeap.Library.Mobile.Dal.Sql2005Mobile.XML" />
<data files="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\*.xml" />
</index>
<copy name="comments" source="*" target="/document/comments" />
</component>
Infine, ecco il contenuto del file sandcastle.config con i riferimenti alla mia directory c:\applications\downloaded dove ho copiato SandCastle:
<
configuration>
<
dduetools>
<
builder>
<
components>
<!--
Create skeleton document -->
<
component type="Microsoft.Ddue.Tools.CopyFromFileComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
data file="c:\applications\downloaded\Sandcastle\Presentation\transforms\skeleton.xml" />
<
copy source="/*" target="/" />
</
component>
<!--
Copy in reflection data -->
<
component type="Microsoft.Ddue.Tools.CopyFromIndexComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
index name="reflection" value="/reflection/apis/api" key="@id" cache="10">
<
data files="reflection.xml" />
<
data files="c:\applications\downloaded\Sandcastle\Examples\Cpref_reflection\*.xml" />
</
index>
<
copy name="reflection" source="*" target="/document/reference" />
</
component>
<!--
Copy in container data -->
<
component type="Microsoft.Ddue.Tools.CopyFromIndexComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
copy name="reflection" key="string(/document/reference/containers/namespace/@api)" source="*[not(local-name()='elements')]" target="/document/reference/containers/namespace" />
</
component>
<
component type="Microsoft.Ddue.Tools.CopyFromIndexComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
copy name="reflection" key="string(/document/reference/containers/type/@api)" source="*[not(local-name()='elements')]" target="/document/reference/containers/type" />
</
component>
<!--
Generate syntax -->
<
component type="Microsoft.Ddue.Tools.IfThenComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
if condition="not(starts-with($key,'Overload:') or starts-with($key,'R:'))" />
<
then>
<
component type="Microsoft.Ddue.Tools.SyntaxComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
syntax input="/document/reference" output="/document/syntax" />
<
generators>
<
generator type="Microsoft.Ddue.Tools.CSharpDeclarationSyntaxGenerator" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\SyntaxGenerators.dll" />
<
generator type="Microsoft.Ddue.Tools.VisualBasicDeclarationSyntaxGenerator" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\SyntaxGenerators.dll" />
<
generator type="Microsoft.Ddue.Tools.CPlusPlusDeclarationSyntaxGenerator" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\SyntaxGenerators.dll" />
</
generators>
</
component>
</
then>
</
component>
<!--
Copy in comments -->
<
component type="Microsoft.Ddue.Tools.CopyFromIndexComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
index name="comments" value="/doc/members/member" key="@name" cache="100">
<
data files="DevLeap.Library.Mobile.Dal.Sql2005Mobile.XML" />
<
data files="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\*.xml" />
</
index>
<
copy name="comments" source="*" target="/document/comments" />
</
component>
<!--
Copy in reflection data and comments for members -->
<
component type="Microsoft.Ddue.Tools.ForEachComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
variable expression="/document/reference/elements/element/@api" />
<
components>
<
component type="Microsoft.Ddue.Tools.CopyFromIndexComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
copy name="reflection" source="*[not(local-name()='elements')]" target="/document/reference/elements/element[@api=$key]" />
</
component>
<
component type="Microsoft.Ddue.Tools.CopyFromIndexComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
copy name="comments" source="summary" target="/document/reference/elements/element[@api=$key]" />
</
component>
</
components>
</
component>
<!--
transform -->
<
component type="Microsoft.Ddue.Tools.TransformComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
transform file="c:\applications\downloaded\Sandcastle\Presentation\transforms\main_sandcastle.xsl" />
</
component>
<!--
resolve shared content -->
<
component type="Microsoft.Ddue.Tools.SharedContentComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
content file="c:\applications\downloaded\Sandcastle\Presentation\content\shared_content.xml" />
<
content file="c:\applications\downloaded\Sandcastle\Presentation\content\reference_content.xml" />
</
component>
<!--
resolve reference links -->
<
component type="Microsoft.Ddue.Tools.ResolveReferenceLinksComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
targets files="reflection.xml" type="local" />
<
targets files="c:\applications\downloaded\Sandcastle\Examples\Cpref_reflection\*.xml" type="none" />
</
component>
<!--
save the result -->
<
component type="Microsoft.Ddue.Tools.SaveComponent" assembly="c:\applications\downloaded\Sandcastle\ProductionTools\BuildComponents\BuildComponents.dll">
<
save path="concat('Output\html\',/html/head/meta[@name='guid']/@content,'.htm')" indent="false" omit-xml-declaration="true" />
</
component>
</
components>
</
builder>
</
dduetools>
</
configuration>
Scusate l'impaginazione di questo file, ma non avevo veramente tempo di riallineare il tutto sull'editor html.
Spero utile a tutti coloro che vogliono iniziare senza impazzire con i 10 passi manuali in cui spesso si commettono errori.
Ieri è uscita una nuova versione di VMWare. Ho appena eseguito l'aggiornamento.
Le novità riguardano il supporto al nuovi sistemi operativi host e guest.
Riporto dal sito:
New in Version 5.5.2
Updated Support for Host Operating Systems
Workstation 5.5.2 adds support for the following host operating systems:
- Windows Server 2003 R2, 32-bit, 64-bit
- Mandriva Linux 2006, 32-bit, 64-bit
- SUSE Linux Enterprise Server 10, 32-bit, 64-bit
- SUSE Linux Enterprise Server 9 SP3, 32-bit, 64-bit
- SUSE Linux 10.1, 32-bit, 64-bit
- Red Hat Enterprise Linux 3.0 update 7, 32-bit, 64-bit
- Experimental support for Red Hat Enterprise Linux 3.0 Update 8, 32-bit, 64-bit
- Red Hat Enterprise Linux 4.0 Update 3, 32-bit, 64-bit
- Experimental support for Red Hat Enterprise Linux 4.0 Update 4, 32-bit, 64-bit
- Ubuntu Linux 6.06, 32-bit, 64-bit
- Ubuntu Linux 5.10, 32-bit, 64-bit
- Ubuntu Linux 5.04, 32-bit, 64-bit
Updated Support for Guest Operating Systems
Workstation 5.5.2 adds support for the following guest operating systems:
- Windows Server 2003 R2, 32-bit, 64-bit
- Mandriva Linux 2006, 32-bit, 64-bit
- SUSE Linux Enterprise Server 10, 32-bit, 64-bit
- SUSE Linux Enterprise Server 9 SP3, 32-bit, 64-bit
- SUSE Linux 10.1, 32-bit, 64-bit
- Red Hat Enterprise Linux 3.0 update 7, 32-bit, 64-bit
- Experimental support for Red Hat Enterprise Linux 3.0 Update 8, 32-bit, 64-bit
- Red Hat Enterprise Linux 4.0 Update 3, 32-bit, 64-bit
- Experimental support for Red Hat Enterprise Linux 4.0 Update 4, 32-bit, 64-bit
- Novell NetWare 6.5 SP5, 32-bit
- Experimental support for FreeBSD 6.1, 32-bit, 64-bit
- Experimental support for FreeBSD 6.0, 32-bit, 64-bit
- Solaris x86 10, 10 Update 1, 32-bit, 64-bit
- Ubuntu Linux 6.06, 32-bit, 64-bit
- Ubuntu Linux 5.10, 32-bit, 64-bit
- Ubuntu Linux 5.04, 32-bit, 64-bit
Change in End User License Agreement (EULA) Display
Workstation 5.5.2 no longer displays the End User License Agreement (EULA) at installation. The EULA is now displayed when you launch Workstation.
Ripubblico parte di un articolo week.it:
Un workflow in Windows Workflow Foundation viene definito come un'organizzazione gerarchica di componenti chiamati Activity: rappresentano l'unità di lavoro e di esecuzione all'interno del flusso. Possiamo pensare a una Activity come uno dei passi del flusso operativo definito dal workflow.
Esistono due caterorie di attività riutilizzabili in vari workflow: basic e composite. Le attività di tipo Basic contengono una "cosa da fare" e espongono proprietà, metodi e eventi utilizzabili per configurare e far lavorare l'attività. Le attività composite sono attività basic estese per contenere altre attività; in pratica un'attività composità è insieme di altre attività, Basic o Composite, per formare un insieme definito e configurabile di alcune attività che devono lavorare insieme per compiere appunto l'attività stessa. Il prodotto contiene una serie di attivtà basic predefinite come ad esempio Start, Suspend, Terminate, Code (Code consente di eseguire una serie di righe di codice .NET) e attività composite come IfElse, Parallel per eseguire attività in parallelo e Sequence per eseguire attività in sequenza. Lo sviluppatore può utilizzare le API (Public Activity Component Model API) che consentono di costruire nuove attività senza nessun limite sulle funzionalità da includere all'interno. Per costruire nuove attività si può agire direttamente da codice implementando classi proprietarie o derivando alcune classi base oppure appoggiarsi al desginer fornito per creare attività composite basate su codice. Implementando le classi occorre definire almeno l'Activity Definition ovvero la definizione della classe e le modalità con cui il designer e/o il run-time farà uso delle proprietà esposte. In aggiunta è possibile definire l'Executor, il Validator per validare i valori delle proprietà impostabili, il Designer con cui Visual Studio 2005 visualizzarerà l'attività custom nel designer del workflow e volendo l'item per la toolbox che consente di visualizzare l'attività custom nella toolbox delle attività disponibili per i vari workflow. La classe base da cui derivare attività custom si trova nel namespace System.Workflow.ComponentModel: per attività basic si deriva la classe Activity, mentre per le attività composite la classe da derivare è CompositeActivity. Il codice di esempio per la creazione di una attività basic è presente all'indirizzo: http://blogs.devleap.com/rob/archive/2006/01/07/6480.aspx.
La classe indicata nel codice utilizza la classe DependencyProperty che consente di memorizzare le proprietà esposte dalla classe custom nel repository che gestisce (e serializza) lo stato del workflow.
Mini articolo pubblicato su thinkmobile (
http://thinkmobile.it/blogs/rob/archive/2006/08/11/5701.aspx) sui vari livelli di security e protezione dei device con Windows Mobile 5.0 a bordo.
Mini articolo introduttivo da me pubblicato su Week.it in gennaio. Riporto pubblicamente:
WinFX (.NET 3.0), come sappiamo da tempo, è la prossima generazione di API Managed .NET Framework e comprende tecnologie quali Windows Presentation Foundation (nome in codice Avalon) e Windows Communication Foundation (nome in codice Indigo). In realtà WinFx comprende anche altre tecnologie meno sbandierate e conosciute. La prima di queste è sicuramente Windows Workflow Foundation: prodotto che girerà su Windows XP, Windows Server 2003, Windows Vista e ovviamente Longhorn, consente di gestire diverse tipologie workflow integrandosi con Visual Studio 2005 e più in generale con il framework .NET. Gli obiettivi sono i seguenti: fornire un motore di esecuzione di flussi per tutte le applicazioni sulla piattaforma windows, supportare diversi tipologie di workflow, da people-centric a application-centric e una serie di regole basate su scenari condizionali, fornire il modello di lavoro (basato appunto su workflow) per tutti gli sviluppatori di applicazioni .NET. Il prodotto è comunque, in prima battuta, un motore di esecuzione di flussi operativi siano essi gestioni documentali, monitoraggio di attività, o più semplicemente flussi logici all'interno di quello che oggi scriviamo sotto forma di righe di codice.
L'approccio è singolare: il modello è completamente estendibile, non è legato a un linguaggio specifico e si basa sull'esecuzione di una serie di step preconfezionati e estendibili a cura dell'utente. Il motore è in-process e gira all'interno di un host che attualmente può essere un'applicazione console, un'applicazione Windows, un'applicazione ASP.NET (anche di tipo web service ovviamente), un site di SharePoint o un servizio Windows. L'Hosting Layer fornisce l'interfaccia fra l'host e il workflow tramite servizi di persistenza, comunicazione, tracking, timer, transazioni. Su questo layer gira il Runtime Layer, il cuore del prodotto, che fornisce servizi di esecuzione, tracking, gestione dello stato delle informazioni, uno scheduler e una serie di policy per l'esecuzione di regole applicative.
L'ultimo layer (Workflow Model Layer) fornisce invece gli strumenti per definire, gestire e coordinare il flusso; sono supportate le due classiche tipologie di workflow: sequenziali e basati su state machine al cui interno possono essere utilizzate una serie di attività che vanno da controllo del flusso alla gestione delle transazioni, dall'esecuzione di operazioni sui dati alla comunicazione verso componenti esterne come web service o componenti. Tutto questo si integra con Visual Studio 2005 che viene esteso per supportare nuove tipologie di progetti, nuovi strumenti nella toolbox per supportare lo sviluppatore nella creazione visuale del flusso.
Dopo aver annunciato il nuovo prodotto il 20 giugno...ecco una CTP. Buon divertimento. Download per MSDN a partire da questo link: http://msdn.microsoft.com/robotics/