Problemi a ricevere parametri double e decimal con ASP.NET WebAPI

Dopo aver perso una MAREA di tempo su questo problema, mi sembra giusto condividerlo col resto del mondo.

Stavamo cercando di passare un semplice campo double a WebAPI Beta, ma ogni volta il valore nel controller era 0… Abbiamo provato di tutto e alla fine cos’era?

Le Regional Options devono essere English!!! Altrimenti WebAPI usa la virgola come separatore decimale

VS 2010: Aggiungere Work Item ai Model Diagram

Domanda: “Posso aggiungere dei work item ai modelli generati con Visual Studio, tipo Sequence Diagram? Perché mi hanno detto che è possibile, ma non capisco come.”

Risposta: “Sì, ma va installato il Feature Pack 2 da qui: http://msdn.microsoft.com/en-us/vstudio/ff655021.aspx

Una volta installato vengono aggiunte delle voci nel menù contestuale degli elementi come da screenshot sotto:

image_thumb[1]

Spero serva a qualcuno,

Ivan

System.Decimal non si sposa bene coi NoSQL

Eccoci ad un altro problemino da tener presente quando si va sul cloud o più in general su vari motori NoSQL: System.Decimal non si sposa molto bene.

I 3 motori scelti per il test drive sono:

  • Azure Table Storage
  • Amazon SimpleDB
  • MongoDB

Tutti e tre non supportano il tipo System.Decimal, quindi se volete salvare valute, cambi, grandi valori con virgola, dovrete ingegnarvi un po’. Noi per ora abbiamo usato il tipo double per le prove, durante le comunicazioni con terminali di pagamento reali solitamente si usa il protocollo ISO8583 dove il numero è diviso in due parti:

  • Amount: l’ammontare completo parte intera e mantissa senza virgola (esempio 100,91 è 10091)
  • MinorUnit: numero di cifre decimali (esempio su 100,91 è 2)

Di seguito i tipi supportati dai vari sistemi:

Tipo Azure Table Storage Amazon SimpleDB MongoDB
byte[] X   X
bool X   X
DateTime X   X
double X   X
Guid X   X
Int32 o int X   X
Int64 o long X   X
String X X (max 1024 bytes) X
regex     X

 

Da notare che Amazon ha scelto un’implementazione tecnica semplice per il suo NoSQL, che però comporta il fatto che tutti I valori vengano salvati come stringhe con una dimensione massima limitata e la ricerca è lessicografica il che significa che per SimpleDB 10 viene prima di 2, quindi bisogna porre un po’ di attenzione in più: http://aws.amazon.com/articles/1232

Nota: è sempre possibile utilizzare un handler per gestire l’evento di Reading/Writing durante l’interazione con i NoSQL sopra. Magari ne parleremo in un post futuro.

Alla prossima!

Azure Queue Service: la dimensione massima di un messaggio è 8KB o 64KB?

Eccoci con un altro piccolo incidente di percorso: la dimensione massima delle Azure Queue è stata portata da 8KB a 64KB dalla versione 2011-08-18 in poi. Fantastico! Un po’ più di spazio disponibile va benone, specialmente su messaggi con molti metadati da inviare.

Se però come me provate a creare un messaggio con una dimensione di 10KB usando l’SDK 1.5 (Ottobre 2011) riceverete un bell’errore.

A questo punto per capire esattamente dove fosse il problema mi sono armato di JustDecompile (visto che il buon vecchio Reflector non è più free, proviamo quello di Telerik) e ho decompilato il CloudQueueMessage da Microsoft.WindowsAzure.StorageClient.dll e… sorpresa! Nel costruttore c’è un bel limite massimo hardcoded a 8192 byte:

CloudQueueMessage.MaxMessageSize = (long)8192;

Come risolvere il problema? Scaricando la versione 1.6 dell’SDK di Azure dove le librerie client sono state aggiornate coi nuovi limiti e decompilando la stessa dll adesso si ha:

CloudQueueMessage.MaxMessageSize = (long)65536;

Azure Table Storage e l’operatore FirstOrDefault

Oggi ho perso l'intero pomeriggio a lottare contro questo problema, quindi voglio condividere la cosa in modo da evitare ad altri di spaccarsi la testa sulla stessa cosa.
Stavo eseguendo una query semplice sul Table Storage di Azure utilizzando PartitionKey e RowKey per recuperare una specifica entità in una tabella specifica (es.: http://127.0.0.1:10002/devstoreaccount1/Spaceship (PartitionKey = '380 ',RowKey = '1234 ')).
Durante i test, il primo scenario era dove non esisteva entità con PK e RK date e ho usato una semplice query che termina con l'operatore FirstOrDefault tipo:

TableRepository.FindWhere (p => p.PartitionKey == entity.Spaceship.CountryCode.ToString () & &
. p.RowKey == entity.SerialNumber) FirstOrDefault ();

e mi aspettavo u null, ma in realtà ho cominciato a ricevere errori 404 col seguente dettaglio: 

<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> 
  <code>ResourceNotFound</code> 
  <message xml:lang="en-US">The specified resource does not exist.</message> 
</error>
Dopo diverse ore alle prese con vari test ho scoperto queste “Perle di Saggezza Azure”:
- Internet Explorer non può essere utilizzato per eseguire query direttamente su Table Storage
- È necessario impostare IgnoreResourceNotFoundException = true nel TableServiceContext per ricevere null quando un'entità non viene trovata, invece di ricevere un errore 404

Inizia l’avventura col cloud: prima Microsoft Azure e poi Amazon AWS

Finalmente siamo partiti! Un bel Proof of Concept su Azure per una bella architettura distribuita Cloud – OnPremise. Prima si prova Azure, poi AWS.

Cercherò di postare un po’ di “Appunti di viaggio” di quest’avventura con problemi, vantaggi, pregi e difetti, performance individuati in modo da poter aiutare futuri avventurieri.

Proveremo di tutto di più:

  • Azure Table Storage – SimpleDB: come NoSQL per salvare grandi quantità di dati
  • Blob Storage – S3: per salvare dati di grandi dimensioni
  • Azure Queue – SQS: per la comunicazione tra i diversi ruoli sul cloud all’interno della stessa Region
  • SQL Azure – MySql: per la parte relazione sul cloud
  • SQL Data Sync: per sincronizzare database distribuiti cloud – OnPremise
  • Service Bus – SNS+SQS: per utilizzare il pattern publish/subscribe per la distribuzione di dati tra region e OnPremise
  • Traffice Manager: per bilanciare automaticamente le chiamate dei client alla region Azure più vicina
  • MongoDB: ci saranno anche esperimenti con MongoDB per confrontare un NoSQL Document Based con I key-value offerti da Microsoft e Amazon
  • Altro: MEF, Automapper, AppFabric, Caching, TPL

Si parte!

Errore TF208002 su editing Product Planning.xlsm

Mi si era corrotto il Product Planning.xlsm del progetto. In apertura mi dava l’errore: TF208002: The name that you specified for the column header is a reserved name for this work item list. Choose a different name and try again.

Chiaramente le ho provate tutte ma il file era andato Sad smile 

Soluzione:

  • prendete il file Product Planning.xlsm direttamente dal Process Template Agile 5 di Microsoft (MSF for Agile Software Development v5.0\Windows SharePoint Services\Shared Documents\Project Management) e copiatelo sul Project Portal del vostro progetto.
  • Apritelo e premete Edit Workbook
  • Andate sul tab Team e selezionate Configure –> Server Connection
  • Premete OK sul popup
  • Selezionate il vostro progetto e premete Connect
  • Premete New List e selezionate la query Product Planning premendo su OK
  • Salvate e avete di nuovo il vostro file!!!

Sono diventato MCT!

Ce l’ho fatta! Ci ho messo un po’, ma sono riuscito a diventare Microsoft Certified Trainer! E lunedì terrò il mio primo corso da docente: MOC 50430: Administering Team Foundation Server 2010!

Team Foundation Server 2010 SP1 Finale

Non dimentichiamoci che è stato rilasciato l’SP1 finale anche per TFS 2010, che contiene un lungo elenco di bug fix.

Per maggiori info: http://support.microsoft.com/kb/2182621

Tutto pronto per gli ALM Days di Roma e Milano

Ci siamo quasi gli ALM Days di Roma (18/1) e Milano (20/1) si avvicinano. La mia sessione sarà …

 

Per registrarsi:

feature_msdn (2)