Ho perso qualche ora per arrivare alla fine a questo KB del supporto di Microsoft che spiega come creare lo slipstream di installazione di Team Foundation Server 2008 SP1 se sul server c’e’ installato SQL SERVER 2008:
Questo il link all’articolo.
del.icio.us Tags:
TFS 2008
Dalla fonte:
http://blogs.msdn.com/adonet/archive/2009/06/22/feature-ctp-walkthrough-self-tracking-entities-for-entity-framework.aspx
“The first scenario we are trying to address with Self Tracking Entities is one in which a WCF service exposes a series of operations that return entity graphs, then a client application can manipulate that graph and submit the modifications to a service operation that validates and performs the updates to a database store using Entity Framework”
E finalmente stiamo arrivando a qualcosa di serio…
Leggere anche questo relativamente alla nuova generazione di POCO entities tramite T4.
PS. l’evidenziazione in grassetto della frase è mia e non della fonte.
PS2. per me che sono un promotore dell’ “autogenerazione del codice”, T4 è veramente potente e di fatto lo uso già per generarmi i miei DTO.
Qui è spiegato come passare parametri di inizializzazione all’applicazione Silverlight.
Il metodo spiegato funziona utilizzando il controllo asp.net che crea e lancia Silverlight. Se la nostra interfaccia è invece una pagina html, i parametri possono essere passati direttamente al javascript nel seguente modo:
<
object data="data:application/x-silverlight-2," type="application/x-silverlight-2"
width="100%" height="100%">
<param name="source" value="ClientBin/PlugIn.Trasparenza.UI.xap"/>
<param name="onerror" value="onSilverlightError" />
<param name="background" value="white" />
<param name="minRuntimeVersion" value="2.0.31005.0" />
<param name="autoUpgrade" value="true" />
<param name="initParams" value="myparam=value" />
<a href="http://go.microsoft.com/fwlink/?LinkID=124807" style="text-decoration: none;">
<img src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get Microsoft Silverlight"
style="border-style: none"/>
</a>
</object>
Sto affrontando da poco un primo progetto in Silverlight 2.0 e tra le tante features presenti, ho da subito notato la mancanza di un sistema che permetta la navigazione tra pagine xaml.
Infatti, a meno che non si sviluppino semplici demo e/o test case, mi sembra quanto meno una cosa importante poter organizzare la propria Silverlight-application su più xaml page che verranno più o meno caricate in base alle azioni utente.
In Silverlight 3.0 il supporto per la navigazione tra pagine(integrato anche con il sistema di navigazione del browser) ci sarà.
In Silverlight 2.0, una soluzione valida, probabilmente l’unica, viene da qui.
del.icio.us Tags:
Silverlight
Sto usando per ora con un certo “piacere” AutoMapper per mappare tutte le entities di EF nel mio layer di DTO.
Il DTO lo creo utilizzando EFPocoGenerator.
EF genera nelle entities anche le proprietà relative alle relazioni 1—Molti, quindi se per esempio User contiene una foreign key di tipo UserStatus, la entity UserStatus conterrà a sua volta una prorietà List<User>(la troveremo nelle Navigation Properties dell’ edmx).
Il problema è il seguente: se cerco di mappare con AutoMapper una query linq to entities che mi ritorni Users e UserStatus, il metodo Map di AutoMapper va in stack overflow.
Infatti cercherà di mappare in ordine: le proprietà di User, UserStatus, List<User> in UserStatus, UserStatus, etc…. in ricorsione infinita.
Per farla breve e veloce, ho optato per una scelta di questo tipo: non mi serve avere nel mio DTO la mappatura delle relazioni 1 a Molti, che eventualmente inserirò a mano quando necessario nelle partial class relativi ai DTO autogenerati.
Ho quindi fatto una piccola modifica al codice di EFPocoGenerator per impedire la generazione di tali proprietà e tutto ora funziona correttamente.
Una delle problematiche che affligge Entity Framework e di cui ci sono anche parecchi post in merito, è la totale dipendenza delle entities dalla logica di persistenza.
Insomma, se voglio come è normale utilizzare il mio model in altri strati della mia architettura multilivello, creo implicitamente una dipendenza con lo strato di accesso ai dati.
E questo, indipendentemente che voglia realizzare o meno una soluzione il più astratta e loosely coupled possibile, è male.
In particolare se pensiamo a tutta una serie di scenari SOA dove utilizzo dei servizi web che devono dialogare tramite queste entities.
La soluzione esiste, e sono i DTO. Attraverso i DTO rimappo le entity non POCO(Plain Old CLR Objects) di EF su un insieme di classi POCO.
Per semplificare questa operazione e renderla automatica, suggerisco l’uso dell’ Entity Framework POCO Generator.
Questo tool fa parte di un progetto che fornisce anche un adapter per supportare l’utilizzo delle entities POCO con l’ Entity Framework.
Una volta scaricato il progetto, di cui si hanno i sorgenti, si ricompila il tool di generazione ed è poi possibile automatizzare la creazione del nostro nuovo model inserendo sul progetto in Visual Studio una pre-build condition in modo simile a questo:
"$(SolutionDir)EFPocoClassGen\EFPocoClassGen.exe" /mode:PocoClasses /inedmx:"$(SolutionDir)MyProject.Data.Repository\Model\Entities.edmx" /outputdir:"$(ProjectDir)Model/autogenerated" /map:MyProjectModel=$(ProjectName).Model
In questi giorni sto facendo un pesante refactoring su alcune parti di un nostro applicativo di workflow basato su .net e workflow foundation.
L’applicativo non è ancora definitivo, e con l’avanzare dello sviluppo di nuove funzionalità il disegno iniziale di alcune feature si è modificato.
Avrei potuto seguire l’approccio più comodo e veloce, ossia continuare con l’aggiunta di codice al disegno iniziale.Questo avrebbe portato al rischio di trovarsi nel breve con codice difficilmente manutenzionabile, estendibile e testabile.
La strada che ho preferito percorrere è stata quella di dedicare qualche ora per operare invece un completo refactoring delle parti coinvolte dalle nuove features.
Fare refactoring per me ha significato: creare interfaccie per eliminare dipendenze e semplificare la riusabilità del codice; rinominare classi, metodi e proprietà nel modo più adeguato; eliminare il codice inutile(commenti inutili compresi).
Il risultato è stato ottimo: un disegno migliore, diminuzione delle righe di codice, codice più leggibile e diciamo quasi “parlante”, miglior testabilità.
Non abbiate paura di perdere tempo con il refactoring…non è mai tempo perso quello…
Oggi da Amazon mi sono arrivati gli ultimi due libri che ho ordinato:
quello di Dino e Andrea, Microsoft.NET:Architecting Applications for the enterprise, e quello che mi ha ispirato Luka con i suoi post, ossia Lean Software Development.
Tra lavoro e altri libri iniziati è una bella sfida cominciare questi due, ma visto quanto li attendevo penso che non ci mettero molto a finirli.
Spero di riuscire a postare anche qualcosa di interessante e utile dalla lettura di questi due libri.
Stay tuned.
Se avete una soluzione ASP.NET che utilizza e referenzia assembly firmati con certificati, vi potreste trovate nella situazione in cui il primo avvio dell’applicazione richieda molto tempo.
Il problema è dovuto al fatto che il runtime di .NET deve verificare che il certificato sia valido e se il server web non ha connettività internet, questo comporta il lungo tempo di attesa.
In questo post c’e’ spiegato molto bene il problema e come risolverlo.
Questo il post ufficiale di Microsoft sulla issues.Se avete installato il framework dal 3.0 in avanti, l’hotfix è già compresa.
Attenzione che per applicativi ASP.NET per disabilitare la verifica del certificato è necessario inserire la configurazione nel machine.config, e non nel web.config.
NB. per le applicazioni client invece è sufficiente configurare l’app.config.