Code and fun - Il blog di Matteo Casati

L'ordine dei parametri in alcune classi del framework

Matteo Casati — Thu, 21 Aug 2008 16:47:14 GMT

...è deciso in modo casuale???

Qualcuno mi spiega perché ArgumentException(string, string) vuole prima il messaggio e poi il nome del parametro mentre, ad esempio, ArgumentNullException(string, string) e ArgumentOutOfRangeException(string, string) funzionano al contrario (prima il nome del parametro e poi il messaggio?

Certe cose proprio non le capisco.

The Developer Highway Code

Matteo Casati — Tue, 19 Aug 2008 12:19:18 GMT

A corollario dei miei due articoli sulla sicurezza delle applicazioni ASP.NET pubblicati in gennaio ("Realizzare applicazioni ASP.NET sicure - Prima parte" e "Realizzare applicazioni ASP.NET sicure - Seconda parte") segnalo la possibilità di scaricare gratuitamente da MSDN UK la versione digitale - e-book - dell'ottimo (seppur datato) "The Developer Highway Code" di Paul Maher and Alex Mackman.

L'ebook è disponibile all'indirizzo http://msdn.microsoft.com/en-gb/security/aa473878.aspx (sia in formato PDF che XPS) ed è un aggiornamento della copia edita da Microsft Press nel 2006.

È possibile scegliere di scaricare la versione completa (circa 7 MB per il PDF) oppure ogni singola sezione:

Part 1 – Security Engineering
Part 2 – Checklists and Question Lists
Part 3 – What’s New for Security in the .NET Framework v2.0
Part 4 – Microsoft Patterns & Practices Security Resources

Buona lettura a tutti.

Tags: ASP.NET

RollingList<T>

Matteo Casati — Thu, 07 Aug 2008 08:22:00 GMT

Nel post precedente ho parlato di come utilizzare le classi di base del framework per realizzare una collection con le seguenti caratteristiche:

all'inserimento di un nuovo elemento questo viene posizionato all'inizio della lista (i più recenti verranno visualizzati per primi)
la lista deve contenere al massimo n elementi: l'inserimento di un nuovo elemento, raggiunto il limite n, deve prevedere la rimozione dell'elemento più vecchio presente nella lista (ovvero quello inserito da più tempo)
garantire ottime performance

Il commento di rsaccav mi ha fatto convinto ad implementare una collezione generica "from scratch", così da colmare il vuoto lasciato in System.Collection.Generic.

Con estrema fantasia l'ho battezzata RollingList<T>

Il principio è piuttosto semplice: la lista si basa su un array con dimensione fissa pari al limite di elementi da conservare (Capacity; la proprietà deve essere impostata nel costruttore o comunque *prima* dell'inserimento del primo elemento) associato ad un cursore (backward) che definisce la posizione di inserimento/sostituzione e che consente di enumerare gli elementi nell'ordine corretto.

Il codice completo della classe:

using System; using System.Collections; using System.Threading; public class RollingList<T> : ICollection { private int _cursor; private int _size; private int _capacity; private T[] _items; private object _syncRoot; public RollingList(int capacity) { Capacity = capacity; } public int Capacity { get { return _capacity; } set { if (value <= 0) throw new ArgumentOutOfRangeException("value", "Capacity must be greater than zero"); if (_capacity > 0) throw new ArgumentException("Capacity has just been defined", "value"); _capacity = value; _items = new T[_capacity]; _cursor = (_capacity - 1); } } public void Add(T item) { if (_capacity <= 0) throw new NotSupportedException("Capacity is not greater than zero"); _items[_cursor--] = item; if (_size < _capacity) _size++; if (_cursor < 0) _cursor = (_capacity - 1); } public void Clear() { Array.Clear(_items, 0, _size); _size = 0; _cursor = (_capacity - 1); } public T[] ToArray() { T[] destinationArray = new T[_size]; if (_size == 0) return destinationArray; int cursorPosition = (_cursor + 1 == _capacity) ? 0 : _cursor + 1; Array.Copy(_items, cursorPosition, destinationArray, 0, (_capacity - cursorPosition)); if (_size == _capacity && cursorPosition > 0) Array.Copy(_items, 0, destinationArray, (_capacity - cursorPosition), cursorPosition); return destinationArray; } public void CopyTo(Array array, int index) { Array.Copy(ToArray(), 0, array, index, _size); } public int Count { get { return _size; } } public bool IsSynchronized { get { return false; } } public object SyncRoot { get { if (_syncRoot == null) { Interlocked.CompareExchange(ref _syncRoot, new object(), null); } return _syncRoot; } } public IEnumerator GetEnumerator() { return ToArray().GetEnumerator(); } }

Questa implementazione è sicuramente migliorabile (ad esempio, oltre a ICollection potrebbe essere utile implementare l'interfaccia ICollection<T>, supportare la serializzazione, ecc.) ma è decisamente preferibile rispetto all'uso di Stack<T>, Queue<T> o LinkedList<T> in quanto:

semplifica il codice di inserimento di elementi (le operazioni di IN/OUT al raggiungimento della capacità massima definita sono gestite dalla collection stessa, quindi non richiedono codice di controllo aggiuntivo)
semplifica la lettura grazie ad una corretta enumerazione nativa degli elementi
permette di avere performance notevolmente più elevate:

// 
  
// RollingList performance test 

  
// 

  
int capacity = 10000; 

  
int max = 1000000000; 

  
DateTime start = DateTime.Now; 

  
RollingList<int> list = new RollingList<int>(capacity); 

  
for (int i = 1; i <= max; i++) 

  
{ 

  
    list.Add(i); 

  
} 

  
foreach (int item in list) 

  
{ 

  
    // do something with "item" 

  
} 

  
Console.WriteLine("RollingList: max={0} -> {1}", 

  
    max.ToString("#,###"), 

  
    DateTime.Now.Subtract(start));

Produce:

RollingList: max=1.000.000.000 -> 00:00:11.5610000

Ovvero un tempo di esecuzione che è circa un terzo rispetto a Queue<T>!!!

HTH

Una semplice (ma solo in apparenza) collection generica

Matteo Casati — Thu, 31 Jul 2008 13:34:55 GMT

Nel progetto (Web) a cui sto lavorando è stata richiesta la visualizzazione di una lista di elementi con le seguenti caratteristiche:

i nuovi elementi devono essere inseriti all'inizio dell'elenco (i più recenti verranno visualizzati per primi)
la lista deve contenere al massimo n elementi: l'inserimento di un nuovo elemento, raggiunto il limite n, deve prevedere la rimozione dell'elemento più vecchio presente nella lista (ovvero quello inserito da più tempo)
l'aggiunta di nuovi elementi è corposa (centinaia di insert al secondo per tutto il ciclo di vita dell'applicazione)
il limite del numero massimo di elementi che devono essere mantenuti nella lista (n) è relativamente basso (< 10.000)

In pratica, definito un limite di 3 elementi e immaginando l'accodamento dei primi 5 interi in ordine crescente (1, 2, 3, 4 e 5) il risultato atteso è:

1
2 1
3 2 1
4 3 2
5 4 3

Ho pensato che sia una cosa semplicissima da realizzare in .NET sfruttando le classi in System.Collection.Generic ma... quale usare? Il framework prevede infatti:

List<T>

Lista generica, non utilizzabile allo scopo in quanto non è possibile inserire elementi in posizioni specifiche ma solo "to the end of the List(T)".

In realtà sarebbe possibile effettuare l'inserimento all'inizio della lista effettuando uno shift di tutti gli elementi ma le performance sarebbero improponibili!

Stack<T>

È letteralmente un insieme di elementi "impilati"; possiamo vederlo come una vaschetta portadocumenti sulla scrivania in cui vengono aggiunte delle pratiche (Push) semplicemente appoggiandole sopra e con l'impiegato che le processa che prende (Pop) il primo foglio che trova in cima alla pigna. Non assolve dunque allo scopo in quanto rimuove gli elementi più "nuovi" anziché quelli più "vecchi".

In pratica il seguente codice:

int capacity = 3; 
  
int max = 5; 

  
Stack<int> list = new Stack<int>(capacity); 

  
for (int i = 1; i <= max; i++) 

  
{ 

  
    if (list.Count >= capacity) 

  
        list.Pop(); 

  
    list.Push(i); 

  
    foreach (var item in list) 

  
        Console.Write("{0} ", item); 

  
    Console.WriteLine(); 

  
}

Produce:

1
2 1
3 2 1
4 2 1
5 2 1

Non ci siamo.

Queue<T>

È appunto una "coda" dove il primo elemento inserito (Enqueue) è anche il primo a venire rimosso (Dequeue); l'analogia che mi viene in mente è quella delle macchine ferme al casello dell'autostrada: il primo arrivato sarà anche il primo a superare la barriera. Questa collection assolve per metà allo scopo garantendo il corretto meccanismo di in/out ma ha il contro di presentare l'enumerazione degli elementi in ordine inverso rispetto a quanto richiesto (scorrendo la collection ottengo prima gli elementi più "vecchi" e poi quelli più "nuovi")

In pratica il seguente codice:

int capacity = 3; 
  
int max = 5; 

  
Queue<int> list = new Queue<int>(capacity); 

  
for (int i = 1; i <= max; i++) 

  
{ 

  
    if (list.Count >= capacity) 

  
        list.Dequeue(); 

  
    list.Enqueue(i); 

  
    foreach (var item in list) 

  
        Console.Write("{0} ", item); 

  
    Console.WriteLine(); 

  
}

Produce:

1
1 2
1 2 3
2 3 4
3 4 5

Non ci siamo ancora ma manca poco :-)

LinkedList<T>

Si tratta di un elenco con doppio collegamento; espone metodi per l'inserimento di nuovi elementi sia all'inizio dell'elenco (AddFirst) che alla fine (AddLast) che in posizioni intermedie (AddAfter e AddBefore), sia per la rimozione (RemoveFirst, RemoveLast, Remove), dandoci la massima flessibilità possibile. In pratica possiamo immaginare questa collection come un trenino giocattolo: possiamo aggiungere o togliere vagoni da entrambe le estremità del convoglio in modo del tutto indifferente.

In pratica il seguente codice:

int capacity = 3; 
  
int max = 5; 

  
LinkedList<int> list = new LinkedList<int>(); 

  
for (int i = 1; i <= max; i++) 

  
{ 

  
    if (list.Count >= capacity) 

  
        list.RemoveLast(); 

  
    list.AddFirst(i); 

  
    foreach (var item in list) 

  
        Console.Write("{0} ", item); 

  
    Console.WriteLine(); 

  
}

Produce:

1
2 1
3 2 1
4 3 2
5 4 3

Missione compiuta? Sembrerebbe di sì.

Per scrupolo ho fatto un piccolo test di performance, aspettandomi prestazioni simili per Queue e LinkedList:

// 
  
// Performance test configuration 

  
// 

  
DateTime start; 

  
int[] results; 

  
int capacity = 10000; 

  
int max = 1000000000; 

  


  
// 

  
// LinkedList performance test 

  
// 

  
start = DateTime.Now; 

  
LinkedList<int> list = new LinkedList<int>(); 

  
for (int i = 1; i <= max; i++) 

  
{ 

  
    if (list.Count >= capacity) 

  
        list.RemoveLast(); 

  
    list.AddFirst(i); 

  
} 

  
results = new int[list.Count]; 

  
list.CopyTo(results, 0); 

  
foreach (int item in results) 

  
{ 

  
    // do something with "item" 

  
} 

  
Console.WriteLine("LinkedList: max={0} -> {1}", 

  
    max.ToString("#,###"), 

  
    DateTime.Now.Subtract(start)); 

  


  
// 

  
// Queue performance test 

  
// 

  
start = DateTime.Now; 

  
results = null; 

  
Queue<int> queue = new Queue<int>(capacity); 

  
for (int i = 1; i <= max; i++) 

  
{ 

  
    if (queue.Count >= capacity) 

  
        queue.Dequeue(); 

  
    queue.Enqueue(i); 

  
} 

  
results = queue.ToArray(); 

  
foreach (int item in results) 

  
{ 

  
    // do something with "item" 

  
} 

  
Console.WriteLine("Queue: max={0} -> {1}", 

  
    max.ToString("#,###"), 

  
    DateTime.Now.Subtract(start));

Sebbene questo tipo di misurazione sia piuttosto "spannometrico", il risultato (per un miliardo di inserimenti a fronte di una lista con al più 10.000 items) mi ha lasciato basito:

LinkedList: max=1.000.000.000 -> 00:01:17.6770000
Queue: max=1.000.000.000 -> 00:00:30.4030000

Ovvero LinkedList richiede circa 2.5 volte il tempo necessario a Queue!

Conclusioni

Sebbene LinkedList<T> faccia il suo "sporco lavoro" lo fa... troppo lentamente!

Alla fine ho dunque optato per l'utilizzo di Queue<T> con l'aggiunta di poche righe di codice per leggere in modo inverso il contenuto enumerato della lista:

Queue<int> queue = new Queue<int>(capacity); 
  
// (codice omesso) 

  
List<int> temp = new List<int>(queue.ToArray()); 

  
temp.Reverse(); 

  
results = temp.ToArray(); 

  
foreach (int item in results) 

  
{ 

  
    // do something with "item" 

  
}

Infatti il numero di elementi mantenuti nella coda è decisamente troppo basso - meno di 10.000 - per risultare influenti le operazioni di copia in una List e di reverse della lista, anche se molto probabilmente questa porzione di codice potrebbe essere migliorata :-)

PS 1: qualcuno avrà notato l'assenza di acronimi come FIFO (first-in, first-out), LIFO (last-in, first-out), ecc.
Sono stati volutamente omessi perché il significato di "primo" e "ultimo" mi è risultato, leggendo qua e là sul Web, interpretato in modo non del tutto univoco (si riferisce all'ordine di inserimento? alla posizione che assume l'elemento nella collection? ad altro?)

PS 2: un doveroso grazie a Cristian e a Marco che mi hanno ~~supportato~~ sopportato in questa ricerca

IDictionary e la serializzazione in XML

Matteo Casati — Thu, 17 Jul 2008 12:26:00 GMT

Chi lavora con i Web Service si sar� accorto che le strutture chiave/valore (Hashtable, Dictionary generici o specializzati, ecc.), non implementando l'interfaccia IXmlSerializable risultano "intrasportabili".

Qualcuno ci ha anche provato a chiedere a Microsoft di modificare questo comportamento ma la risposta � stata "Won't fix"... La motivazione? Semplice: "Unfortunately, we cannot change Dictionary<K,V> to implement IXmlSerializable since it is located in the mscorlib assembly that cannot reference System.Xml.dll."

In realt� creare un Dictionary generico serializzabile in XML � piuttosto semplice: basta creare una classe "SerializableDictionary" che derivi da Dictionary<TKey, TValue> e implementi IXmlSerializable, serializzando - per ogni KeyValuePair contenuto nella collection di base - sia la chiave che il valore.

Ho fatto due implementazioni: la prima serializza le chiavi e i valori in Base64, la seconda in XML.

KeyValuePair in Base64

using System;
using System.IO;
using System.Xml;
using System.Xml.Schema;
using System.Xml.Serialization;
using System.Collections.Generic;
using System.Runtime.Serialization.Formatters;
using System.Runtime.Serialization.Formatters.Binary;

[Serializable]
public class SerializableDictionary<TKey, TValue> : Dictionary<TKey, TValue>, IXmlSerializable
{
�� #region IXmlSerializable Members

�� private const string NS = "";
�� private const string XML_ITEM_NODE_NAME = "item";
�� private const string XML_KEY_ATTRIBUTE_NAME = "key";
�� private const string XML_VALUE_ATTRIBUTE_NAME = "value";

�� public XmlSchema GetSchema()
�� {
�� return null;
�� }

�� public void WriteXml(XmlWriter w)
�� {
�� foreach (TKey key in Keys)
�� {
�� TValue value = this[key];
�� w.WriteStartElement(XML_ITEM_NODE_NAME, NS);
�� w.WriteElementString(XML_KEY_ATTRIBUTE_NAME, NS, ToBase64(key));
�� w.WriteElementString(XML_VALUE_ATTRIBUTE_NAME, NS, ToBase64(value));
�� w.WriteEndElement();
�� }
�� }

�� public void ReadXml(XmlReader r)
�� {
�� r.Read();
�� r.MoveToContent();
�� while (r.NodeType != XmlNodeType.EndElement)
�� {
�� r.ReadStartElement(XML_ITEM_NODE_NAME, NS);
�� TKey key = FromBase64<TKey>(r.ReadElementString(XML_KEY_ATTRIBUTE_NAME, NS));
�� TValue value = FromBase64<TValue>(r.ReadElementString(XML_VALUE_ATTRIBUTE_NAME, NS));
�� r.ReadEndElement();
�� r.MoveToContent();
�� Add(key, value);
�� }
�� }

�� #endregion

�� #region Base64 Serialization

�� private static string ToBase64(object value)
�� {
�� using (MemoryStream stream = new MemoryStream())
�� {
�� BinaryFormatter formatter = new BinaryFormatter();
�� formatter.AssemblyFormat = FormatterAssemblyStyle.Simple;
�� formatter.Serialize(stream, value);
�� byte[] buffer = stream.ToArray();
�� return Convert.ToBase64String(buffer, 0, buffer.Length, Base64FormattingOptions.None);
�� }
�� }

�� public static T FromBase64<T>(string base64)
�� {
�� byte[] buffer = Convert.FromBase64String(base64);
�� using (MemoryStream stream = new MemoryStream(buffer))
�� {
�� BinaryFormatter formatter = new BinaryFormatter();
�� formatter.AssemblyFormat = FormatterAssemblyStyle.Simple;
�� return (T)formatter.Deserialize(stream);
�� }
�� }

�� #endregion
}

KeyValuePair in XML

using System;
using System.Xml;
using System.Xml.Schema;
using System.Xml.Serialization;
using System.Collections.Generic;

[Serializable]
public class SerializableDictionary<TKey, TValue> : Dictionary<TKey, TValue>, IXmlSerializable
{
�� #region IXmlSerializable Members

�� private const string NS = "";
�� private const string XML_ITEM_NODE_NAME = "item";
�� private const string XML_KEY_NODE_NAME = "key";
�� private const string XML_VALUE_NODE_NAME = "value";

�� public XmlSchema GetSchema()
�� {
�� return null;
�� }
�� public void ReadXml(XmlReader reader)
�� {
�� XmlSerializer ks = new XmlSerializer(typeof(TKey));
�� XmlSerializer vs = new XmlSerializer(typeof(TValue));
�� bool wasEmpty = reader.IsEmptyElement;
�� reader.Read();
�� if (wasEmpty)
�� return;
�� while (reader.NodeType != XmlNodeType.EndElement)
�� {
�� reader.ReadStartElement(XML_ITEM_NODE_NAME, NS);
�� reader.ReadStartElement(XML_KEY_NODE_NAME, NS);
�� TKey key = (TKey)ks.Deserialize(reader);
�� reader.ReadEndElement();
�� reader.ReadStartElement(XML_VALUE_NODE_NAME, NS);
�� TValue value = (TValue)vs.Deserialize(reader);
�� reader.ReadEndElement();
�� Add(key, value);
�� reader.ReadEndElement();
�� reader.MoveToContent();
�� }
�� reader.ReadEndElement();
�� }

�� public void WriteXml(XmlWriter writer)
�� {
�� XmlSerializer ks = new XmlSerializer(typeof(TKey));
�� XmlSerializer vs = new XmlSerializer(typeof(TValue));
�� foreach (TKey key in Keys)
�� {
�� writer.WriteStartElement(XML_ITEM_NODE_NAME, NS);
�� writer.WriteStartElement(XML_KEY_NODE_NAME, NS);
�� ks.Serialize(writer, key);
�� writer.WriteEndElement();
�� writer.WriteStartElement(XML_VALUE_NODE_NAME, NS);
�� TValue value = this[key];
�� vs.Serialize(writer, value);
�� writer.WriteEndElement();
�� writer.WriteEndElement();
�� }
�� }

�� #endregion
}

�

A voi la scelta :-)

Tags: .NET Framework, Web Service, XML

3-Tier, 3-Layer e MVC: ma sono la stessa cosa?

Matteo Casati — Thu, 10 Jul 2008 15:46:00 GMT

Questa riflessione parte dalla domanda di un utente nel forum:

"Domanda: Analogie tra MVC e Three-tier - Sono troppe e a me sembra che l'uno possa sostituire l'altro.. ma quanto sbaglio?"

Ho l'impressione che questa perplessit� sia parecchio diffusa e che, pi� in generale, ci sia parecchia confusione quando si parla di software architecture: spero che questo post possa chiarire un po' meglio alcuni concetti.

Iniziamo definendo, in termini strettamente lessicali, cosa si intende per "3-Tier", dato che la stessa Wikipedia non � affatto chiara n� precisa (sia in italiano che in inglese) contribuendo ad aumentare la confusione.

Architettura 3-Tier (o n-Tier)

Letteralmente si parla di "architetture a 3 o pi� livelli" per definire un modello che fornisca una separazione fisica dell'applicazione; in pratica si dice che un'applicazione pu� essere erogata usando un'infrastruttura complessa e diversificata, tipicamente usando pi� server, ciascuno dedicato ad una funzionalit� specifica (fron-end, middleware, back-end, ecc.)
Una spiegazione pi� dettagliata di questo modello distributivo � disponibile sul sito "Microsoft patterns & practices Developer Center": Three-Tiered Distribution

In pratica ritengo che si dovrebbe parlare di "tier" in riferimento a qualcosa di "sistemistico", e non per architettura software in senso stretto.

Architettura 3-Layer (o n-Layer)

Le architetture a 3 strati (o pi�: il "3" � entrato nella concezione comune in quanto rappresenta la stratificazione pi� semplice ed utilizzata) sono un modello di organizzazione del codice applicativo basato sulla separazione delle funzionalit� logiche. Tipicamente avremo:

Presentation (PL): la visualizzazione dei dati e, pi� in generale, la rappresentazione dei controlli (forms, controlli di input, labels, ecc.) necessari per l'interfaccia utente
Business Logic (BLL): rappresenta la parte principale dell'applicazione, definendo il domain model dell'applicazione, ovvero le entit� (ad esempio: fattura, cliente, ecc.), le loro relazioni e le logiche applicative. Non deve contenere contenere alcun riferimento a come i dati saranno presentati all'utente o a come verranno salvati
Data Access (DAL): contiene tutto quello che concerne la persistenza dei dati (database, tabelle, record, file system, ecc.)

Questo tipo di architettura ha principalmente il vantaggio di fornire una separazione logica cos� da aumentarne la manutenibilit�, la scalabilit� ed il riutilizzo.
Una spiegazione pi� dettagliata di questo tipo di architettura � disponibile sul sito "Microsoft patterns & practices Developer Center": Three-Layered Services Application

Model-View-Controller (MVC)

Questo pattern, introdotto solo di recente nel mondo .NET ma diffuso da tempo in altri ambienti, fornisce un modello per strutturare in modo organizzato le funzionalit� relative alla UI e orchestrare l'accesso agli altri strati applicativi (BLL e DAL):

Model: � l'insieme dei componenti che mantengono lo "stato": i dati e i metodi per accedervi. In pratica costituisce la logica applicativa o - IMHO preferibilmente - l'accesso al layer (separato) di BL
View: deputato alla visualizzazione vera e propria dell'interfaccia utente per la presentazione dei dati
Controller: gestisce le interazioni dell'utente con l'applicazione (tipicamente intercettando e gestendo gli eventi e gli input dell'utente), mediante accesso al Model e definendo la View corrispondente da presentare

MVC non contraddice quindi il modello 3-Layer, semplicemente � una delle possibili implementazioni di questo tipo di architettura; da un certo punto di vista possiamo addirittura vedere MVC come un'estensione dell'architettura a 3 strati, in quanto porta una separazione logica ulteriore nel livello di presentation.

MVC � dunque un'alternativa ai Web Forms di ASP.NET e, come tale, ha vantaggi e svantaggi.

Per quanto mi riguarda (non ne faccio mistero: il modello a forms ASP.NET non mi � mai piaciuto per tanti motivi) MVC ha solo vantaggi :-)

Tags: .NET Framework, Architettura, ASP.NET

Anonymous Methods e collection generiche

Matteo Casati — Tue, 21 Nov 2006 17:26:06 GMT

Tutto quello che ci serve sapere per lavorare con le collection generiche usando anonymous methods; purtroppo � in lingua inglese... ma se insistiamo tutti insieme magari Simone lo traduce e lo posta anche sul suo blog italiano o su GURU4.net ;-)

L'articolo � un po' datato ma - per chi non l'avesse ancora visto - credo valga la pena spendere 10 minuti per risparmiare qualche ora al momento del bisogno :-)

Tags: .NET Framework, .NET Framework 2.0

Generare documenti Office via ASP.NET

Matteo Casati — Tue, 31 Oct 2006 11:35:56 GMT

Quasi tutti noi abbiamo (almeno una volta, confessate!) avuto la necessit� di creare nelle nostre applicazioni web funzionalit� di esportazione dei dati in formato Exel o di generazione di documenti Word, trovandoci inevitabilmente a fare i conti con le difficolt� del caso (Office sul server? E chi ce l'ha???)

Il vecchio formato binario in uso da 10 anni in Office era infatti decisamente troppo complesso per essere manipolato fuori dalla suite di Microsoft (ok, le versioni 2000 e 2003 hanno introdotto la possibilit� di creare documenti in formato XML ma � un po' un "optional" e con diverse limitazioni)

Per�...

Se tra gli importanti e sostanziosi cambiamenti introdotti con Office 2007 quello pi� evidente � la nuova interfaccia grafica, quello pi� interessante � il cambiamento del formato dei documenti: ora finalmente possiamo dire addio alle difficolt� di manipolazione dei documenti Office da codice e Ted Pattison, su MSDN Magazine di Novembre 2006 ci illustra quanto diventa semplice lavorare con Office usando .NET: Server-Side Generation of Word 2007 Docs

Happy (office documents) programming!

Internet Explorer 7 - disponibile la RC1

Matteo Casati — Fri, 25 Aug 2006 08:07:00 GMT

IE7 � finalmente giunto alla prima RC (Release Candidate), come annunciato sul blog del team: Internet Explorer 7 Release Candidate Now Available. Nel post originale sono spiegate le variazioni.

La prima cosa che salta all'occhio sono le Installation Changes in IE7 Release Candidate�per cui non sar� pi� necessario rimuovere manualmente eventuali versioni precedenti (beh, ad ogni modo un paio di reboot non ve li toglie nessuno!)

Unico problema da me riscontrato: al termine dell'installazione non era pi� visibile la "Quick Start Toolbar" nella barra di Windows; niente di grave insomma :-)

Dimenticavo il link diretto per il download (gratuito, previa autenticazione della copia di Windows) di IE7 RC1.

Enjoy!

Quanti motivi ci sono per passare a Visual Studio 2005?

Matteo Casati — Thu, 23 Mar 2006 10:41:00 GMT

Pi� di 400.

Non ci credete?
Allora guardate qua:�http://www.400plusdifferences.com/