Vi segnalo questo simpatico video che narra una vicenda "poco simpatica" avvenuta in Pixar.

Enjoy!

Per coloro che hanno la necessità di accedere ai dati SAP dal mondo .NET, potrebbe risultare utile utilizzare tutta la semplicità di LINQ, utilizzando LINQ TO SAP. La libreria è a pagamento ma in alcuni casi può semplificare notevolmente la fase di sviluppo e di manutenzione.

È indubbio che la libreria Ajax Control Toolkit sia molto utile per velocizzare lo sviluppo di applicazioni web con ASP.NET. In questa libreria troviamo anche il controllo AutoCompleteExtender, che permette di fornire la funzionalità di "suggest" con poco sforzo.

Questo controllo richiede la presenza di un servizio web che fornisca la lista delle voci che devono essere visualizzate dal controllo. Nella documentazione ufficiale si trova tutto il necessario per una corretta creazione e configurazione di questo servizio che, dati due parametri (tra la stringa indicata nella textbox a cui l'extender fa riferimento) restituisce un array di stringhe, che poi sono le voci che saranno mostrate dal controllo per la selezione.

Nella documentazione però non viene riportata la possibilità di poter far gestire dal controllo delle coppie di tipo chiave-valore che, in molti casi, risultano essere molto utili.

Supponendo ad esempio di utilizzare questo controllo per la ricerca di un cliente all'interno di una anagrafica, ricercandolo per nome, il servizio web configurato secondo la documentazione ufficiale fornirebbe una lista di nomi cliente ottenuti filtrando l'anagrafica. Potrebbe risultare invece più comodo poter ricevere una lista di coppie chiave-valore, dove la chiave è l'ID univoco del cliente e il valore il nome del cliente. In questo modo, quando l'utente seleziona una voce dalla lista suggerita dal controllo possiamo ricavare facilmente l'ID del cliente selezionato.

Come accedere a questa comoda funzionalità è illustrato in questo post.

Microsoft ha rilasciato la versione 1.0 del SDK per lo sviluppo di applicazioni con supporto a Kinet.

Su Channel 9 trovate tutte le informazioni del caso.

Il 9 dicembre 2011 è stata rilasciata la versione 5 di Silverlight.

Qua potete trovare la lista delle nuove features. Il runtime è disponibile per il download a questa pagina, mentre per i Silverlight 5 Tools per Visual Studio 2010 sono scaricabili qui.

E' stata rilasciata la nuova versione (4.0) di Monodroid, la libreria per poter sviluppare applicazioni per OS Android utilizzando l'ambiente .NET.

Qua potete trovare tutte le informazioni, con inclusi tutorial e documentazione.

Oggi mi sono imbattuto in uno strano errore generato da Entity Framework 4, di cui non sono riuscito a trovare sufficienti informazioni in rete e che quindi vi segnalo, nella speranza che vi possa tornare utile.

Nel progetto a cui attualmente sto lavorando ho un semplice metodo che va a salvare nel data store i dati di una entity. Il metodo in questione ha la seguente struttura:

public void Save(Veicolo v)
{
    var _ctx = new MyObjectContext();
    _ctx.Veicoli.Attach(v);
    _ctx.ObjectStateManager.ChangeObjectState(v, System.Data.EntityState.Modified);
    _ctx.SaveChanges();
 }

niente di più semplice: il metodo riceve la entity, la collega all'ObjectContext, la marca come modified e salva invia le modifiche al database.

Al momento della chiamata al metodo SaveChanges() veniva lanciata la seguente eccezione:

"System.InvalidOperationException: More than one item in the metadata collection match the identity 'annuncio'."

dove annuncio è una property della entity di tipo Annuncio. Questo post su MSDN mi ha indirizzato nella giusta direzione per scoprire la causa del problema.
Dall'immagine qua sotto, potete vedere che la mia entity Veicolo presenta una proprietà annuncio ed una navigation property Annuncio.

Anche se per il C# le due proprietà sono distinte (poichè C# è case sensitive) e quindi il codice viene compilato correttamente, per Entity Framework questo non è vero. Entity Framework per determinare il valore di una proprietà una case insensitive reflection, causando l'errore indicato. La soluzione? Cambiare il nome della proprietà annuncio in TestAnnuncio e l'eccezione è scomparsa.

Supponiamo che si debba scrivere una query Linq To Entities in cui si vogliano filtrare le entitites imponendo una condizione sulla sola parte Date di una proprietà DateTime, come nel caso seguente:

var query = _objectContext.Ordini.Where(r.DataRegistrazione.Date >= DateTime.Now.Date);

eseguendo questa query si ottiene la seguente eccezione

"System.NotSupportedException: The specified type member 'Date' is not supported in LINQ to Entities. Only initializers, entity members, and entity navigation properties are supported."

Il problema può essere riassunto nel fatto che Entity Framework non riesce a tradurre in TSQL l'operatore Date. Per risolvere questo problema possiamo utilizzare la funzione di utilità System.Data.Objects.EntityFunctions.TruncateTime(), come indicato qua di seguito

var query = _objectContext.Ordini.Where(EntityFunctions.TruncateTime(r.DataRegistrazione) >= DateTime.Now.Date);

Per poter utilizzare questa funzione è necessario referenziare l'assembly System.Data.Objects

Molto spesso, non appena si parla della tecnologia Silverlight, si finisce con la solita affermazione "Con HTML 5 non ci sarà più bisogno di Silverlight".

Sinceramente non sono d'accordo, per diversi motivi. Sia i miei motivi, che altri, sono illustrati chiaramente in questo post del blog del Team Silverlight di Microsoft.

Personalmente continuo a pensare che Silverlight sia attualmente la tecnologia web vincente per sviluppare applicazioni orientate al business.

Mi sono imbattuto in uno strano malfunzionamento di un servizio WCF che fornisce dati ad un client Silverlight.

Il malfunzionamento si manifestava al momento della deserializzazione da parte del servizio di un grafo di entità di tipo Self-Tracking Entity (STE) di Entity Framework. L'errore che veniva ritornato al client era un anonimo "Not found" ma andando ad analizzare il file di trace del servizio WCF, l'errore che veniva rilevato era il seguente:

The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter DocumentiFiscaliService:documento. The InnerException message was 'There was an error deserializing the object of type FarmaSpadEntities.DocumentoFiscale. The maximum read depth (32) has been exceeded because XML data being read has more levels of nesting than is allowed by the quota. This quota may be increased by changing the MaxDepth property on the XmlDictionaryReaderQuotas object used when creating the XML reader.

In pratica, il servizio riceveva un grafo di entity che come profondità superava la soglia di default, impostata al valore 32. Per poter aumentare questo valore si deve modificare il web.config del servizio WCF, aggiungendo il tag readerQuota con l'attributo maxDepth come indicato qua sotto:

<bindings>
    <basicHttpBinding>
        <binding name="httpBinding">
            <readerQuotas maxDepth="2000"/>
        </binding>
    </basicHttpBinding>
</bindings>

Il problema però era che l'errore continuava a presentarsi, come se la modifica alla configurazione del binding non venisse caricata al momento della costruzione del servizio WCF.

Analizzando il file di trace del servizio, mi imbattevo in questo strano messaggio di warning:

Dopo qualche test ho scoperto che c'era un errore nella definizione dei service nel file web.config che però non veniva rilevato nè da Visual Studio, nè notificato al momento dell'esecuzione. L'errore era dovuto al fatto che il nome che si assegna al tag SERVICES deve coincidere con il nome completo della classe che implementa il servizio WCF.

<services>
    <service name="FarmaciWcfService.FarmaciWcfService">
        <endpoint address="" binding="basicHttpBinding" bindingConfiguration="httpBinding" contract="FarmaciWcfService.IArticoliService"></endpoint>
        ........
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"></endpoint>
    </service>
</services>

Nel mio caso, il servizio WCF è implementato dalla classe seguente:

namespace FarmaciWcfService
{
    public class FarmaciWcfService : IArticoliService, .......
    {
        // codice....
    }
}

e quindi è necessario che il tag SERVICE abbia lo stesso nome nel valore dell'attributo name.

Con quest'ultima modifica, il problema iniziale è scomparso (indicando che ora la nuova configurazione del binding viene effettivamente utilizzata) ed è scomparso anche il messaggio di warning nel file di traccia del servizio.