martedì 27 luglio 2010

Entity Framework e il ProviderManifestToken

Quando si usa Entity Framework (sicuramente la versione 4, la prima immagino ma non ho mai provato) il modello si “lega” alla versione del database che si è indicato in fase iniziale. Tale legame viene scritto nel modello, precisamente nel ssdl, nella proprietà ProviderManifestToken e tale proprietà non è editabile dal designer. Ovviamente da tale proprietà dipende il tipo di codice SQL generato per le varie interrogazioni.
Questo può portare a problemi/fastidi se nell’ambiente di sviluppo si usa una versione di SQL Server differente da quella che si ha in ambiente di test/produzione. Se ad esempio si sviluppa su SQL Server 2008 ma sull’ambiente di produzione del cliente si ha SQL Server 2005 il nostro progetto rischia di non funzionare, soprattutto se usiamo dei campi data: la versione per SQL 2008 sfrutta il tipo datetime2 che in SQL 2005 non esiste.
La soluzione che ho adottato e che funziona correttamente in un sistema già rilasciato presso un cliente prevede i seguenti passi:

  1. Impostare il modello affinché non “embeddi” i file, tra cui l’ssdl, nella dll ma li copi nella cartella di output – in altre parole nelle proprietà del modello impostare Metadata Artifact Processing a “Copy to Output Directory” invece di “Embed in Output Assembly”
  2. Creare una semplice console application che prenda il file ssdl e vada a sostituire il valore del ProviderManifestToken (in fondo riporto un semplice codice d’esempio), e “linkarla” nel progetto che contiene il modello
  3. Impostare il post-buil event del progetto contenente il nostro modello affinché chiami la console application appena creata e successivamente copi i file del modello (csdl, msl ed ssdl) nel “bin” del nostro startup project (istruzione xcopy)
  4. Impostare il file di configurazione (nel mio caso il web.config) affinché la stringa di connessione punti correttamente ai file copiati con la post-build operation

Il semplice codice della console application che ho preparato è il seguente:

   1: static void Main(string[] args)
   2: {
   3:     string modelName = args[0];
   4:     string filePath = string.Format("./{0}.ssdl", modelName);
   5:  
   6:     var edmx = new XmlDocument();
   7:     edmx.Load(filePath);
   8:     var nsm = new XmlNamespaceManager(edmx.NameTable);
   9:     nsm.AddNamespace("a", "http://schemas.microsoft.com/ado/2009/02/edm/ssdl");
  10:     var x = edmx.SelectSingleNode("/a:Schema", nsm);
  11:     x.Attributes["ProviderManifestToken"].Value = "2005";
  12:     edmx.Save(filePath);
  13: }

In questo caso vuole il nome del modello in input così da dedurre il nome del file ssdl, e imposta di default il ProviderManifestToken a 2005. Ovviamente la modifica per prendere in input anche il valore da impostare al ProviderManifestToken è banale.

Alcuni link utili:

P.S. L’errore dato dall’applicativo dal quale è emerso questo comportamento legato al ProviderManifestToken è stato “SQL Server in use does not support datatype datetime2”.

venerdì 23 luglio 2010

Choosing the right WCF binding

Me lo segno perchè estremamente interessante: Choosing the right WCF binding.

Il post riepiloga i 9 binding built-in per WCF e indica quando è il caso di usare ciascuno di essi.

Estremamente chiaro e intuitivo il grafico fornito, che riporto, ripreso da un capitolo di "Programming WCF Services" di Juval Lowy:

Problemi di installazione KB970892 su SQL 2005

Su un server l’aggiornamento “Security Update for SQL Server 2005 Service Pack 3 (KB970892)” non veniva installato. Windows update dava errore ma senza particolari dettagli.

Motivo? Sul server, oltre a SQL Server 2005 versione Standard 32bit con SP3, era installata ma non avviata (anzi disabilitata) anche una versione di SQL Express. Avviando SQL Express l’aggiornamento si è installato correttamente.

giovedì 22 luglio 2010

Reporting Services e font embedding

Problema: mettere a disposizione su un portale web dei bollettini di pagamento personalizzati per utente. Tali bollettini devono essere scritti con un carattere particolare così da essere facilmente leggibili in banca dagli appositi lettori. Nella fattispecie si tratta del font OCR-B.

La soluzione adottata si basa su SQL Server Reporting Services, per la precisione, per questioni di licenza, la versione 2005 con SP3 installata.

Dalla pagina web, in base all’utente loggato, si passano i parametri opportuni al report creato e si da in output all’utente direttamente il file pdf, senza passare per la preview con il controllo reportviewer.

In altre parole nulla di strano o articolato se non fosse per il carattere OCR-B. Se il carattere non è installato sul client il pdf viene mostrato con un carattere standard. Per ovviare bisogna far “embeddare” il carattere nel pdf.

Cosa dice Microsoft al riguardo:

Font embedding privileges are granted by the font author. Installed fonts include a property that indicates whether the font author intends to allow embedding a font in a document. If the property value is EMBED_NOEMBEDDING, the font is not embedded in the PDF file. For more information, see "TTGetEmbeddingType" on msdn.microsoft.com.

The Font is TrueType.

The characters in the string that has the Font property set are Unicode, not ANSI. No font embedding occurs for ANSI characters.

Fonts are referenced by visible items in a report. If a font is referenced by an item that has the Hidden property set to True, the font is not needed to display rendered data and will not be included in the file. Fonts are embedded only when they are needed to display the rendered report data.

Stando a quanto letto in giro per la rete il supporto per l’”automatic full font embedding” è garantito solo da Reporting Services 2008 con installato il Cumulative Update #1 for SQL Server 2008.

Tuttavia è possibile cavarsela anche utilizzando Reporting Services 2005 e SQL Server 2005 SP3.

In questa situazione se il testo all’interno del report contiene soltanto caratteri “latin” l’embedding del font non sarà possibile.

Occorrerà aggiungere caratteri non ANSI (ad esempio: ޝ) per ogni testo nel report scritto con il font che si vuole “embeddare”.

Naturalmente occorrerà anche che il font sia True Type ed embeddable.

Per controllare le caratteristiche dei vari font può essere utile Font property extension, un tool Microsoft (http://www.microsoft.com/typography/TrueTypeProperty21.mspx).

Serviranno entrambi i file con estensione pfm e ttf.

Per l’installazione del carattere da effettuare sul server di Reporting si può fare riferimento alla guida Microsoft presente online (http://support.microsoft.com/kb/314960).

Nel nostro caso occorre prestare attenzione ad installare per primo il carattere Type 1 (file con estensione pfm) e successivamente il True Type (estensione ttf), anche se ci sfugge il perché.

Dopo aver installato i caratteri è necessario un riavvio della macchina.

A questo punto il pdf generato attraverso Reporting ha il carattere embeddato e quindi qualunque client può stampare correttamente il bollettino di pagamento.

 

Ricapitolando:

  • RS2005 + SQL2005 SP3
  • Carattere True Type e con Embed allowed
  • Preparare il report aggiungendo caratteri non ANSI nelle textbox in cui si utilizza il carattere di cui si vuol fare l’embed
  • Installare il carattere (partendo dal file con estensione pfm (Type1) e continuando con il ttf (True Type))
  • Riavviare la macchina
  • Sistemare il report e farne il deploy