Carillon .NET

Best practice Path.Combine

Adrian Florea — Mon, 05 May 2008 09:44:32 GMT

Se vogliamo che il nostro codice giri anche su Mono, dobbiamo utilizzare:

Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "aaa.bbb")

al posto di:

AppDomain.CurrentDomain.BaseDirectory + "aaa.bbb"

perche' su Mono, BaseDirectory ritorna una stringa che non finisce in Path.DirectorySeparatorChar, mentre su CLR si'. E questo va anche in generale, quando costruiamo il path da piu' pezzi, non solo nel caso della BaseDirectory. Per esempio, chi utilizza fyiReporting RDL Project su Mono, dovrebbe modificare la riga 81 nel file Runtime/RdlEngineConfig.cs nei sorgenti del progetto e ricompilare, da:

file = dir + "RdlEngineConfig.xml";

file = Path.Combine(dir, "RdlEngineConfig.xml");

perche' la stringa dir, per come e' stata costruita, su CLR finisce in Path.DirectorySeparatorChar, mentre su Mono no. In SLAR 1 alla pagina 360, Joel Marcey aggiunge questa nota sulla storia del metodo Combine:

The Combine method had an interesting ride in the standardization process. It was originally part of the Path class, then removed because it was thought to be too platform-specific, then added back because it was decided it was not any more platform-specific than any of the other methods in this class.

Un'API generico a provider per i metadata dei vari ORM

Adrian Florea — Sat, 03 May 2008 13:53:11 GMT

Via questo post di Frans Bouma ho scoperto sotto il namespace System.Web.DynamicData.ModelProviders dell'assembly System.Web.DynamicData.dll che arriva con l'ultima release della preview di ASP.NET Dynamic Data, un'API generico composto da 4 provider per i metadata dei vari ORM (non solo Microsoft): DataModelProvider, TableProvider, ColumnProvider ed AssociationProvider. Questo unifica in buona misura le varie API che espongono i metadata degli ORM, per esempio MetaTable, MetaDataMember, MetaAssociation nel caso di LINQ to SQL, oppure quella piu' complessa dell'Entity Framework: EntitySet, EdmMember, NavigationProperty, etc. Frans ha gia' scritto un model provider per il suo LLBLGen Pro, sarebbe bellissimo averne uno anche per NHibernate. E poi mi piacerebbe in futuro vedere questa API staccata dal ASP.NET Dynamics Data con cui non dovrebbe avere tanto in comune.

Brian Grunkemeyer sulla storia del TypeCode e dell'interfaccia IConvertible

Adrian Florea — Tue, 18 Mar 2008 06:24:33 GMT

Visto l'interesse che ha suscitato l'ultimo post, ho scritto a Brad Abrams chiedendo conferma per la mia supposizione e dettagli sulla storia dell'interfaccia IValue, lui mi risponde subito indirizzandomi a Brian Grunkemeyer e stamattina trovo nella mia casella email, scritto da Brian, questo splendido pezzo della storia di .NET:

This is a good question. I was digging through the history of this file to see if I could figure out what happened, and it’s not clear. We’ve had this “hole” in the TypeCode enum since October of 2000, and I can’t find an older set of bits. But, I’m sure that comment in IConvertible is right – this used to be TimeSpan. For TimeSpan, it’s possible we thought it would be interesting for a while, then we realized that frankly not that many people need to convert a Decimal to a TimeSpan, then removed it.

You might ask why we didn’t “fix” the enum when we removed whichever of these values we had originally added. It turns out that whenever we have a breaking change internally, we need to recompile all the code that might possibly depend on the removed or changed public surface area. For us, that would mean rebuilding everything that might have referred to TypeCode.String, whose value would have changed from 18 to 17. While we do go through that process internally in DevDiv, it is costly & painful for us. Back then with some underdeveloped internal processes, it usually took 2 weeks, then even longer if your change requires a rebuilt compiler to be checked in as a new “safe” build of a compiler. Back in 2000, we were racing to ship as soon as possible (even though we didn’t ship for another year or two), so we wanted to limit churn like this. It’s sometimes easier to not deal with that level of churn in the product.

For your other question about IValue, that was the original name for IConvertible. We exposed a Variant type to match OLE Automation’s VARIANT type on the native side, for COM Interop reasons. The VB team actually was thinking that Variant should be conceptually the root of their object hierarchy (at least in terms of how types were exposed in VB 7), but that seemed a little silly. Fortunately, Anders Hejlsberg convinced them to use Object instead and we’d expose IConvertible on the base data types to allow VB users to easily change from one data type to another. So we marked Variant internal & we only use it in a handful of places internally for COM-related functionality.

Grazie ragazzi!

Sull'enum TypeCode e sull'interfaccia fantoma IValue

Adrian Florea — Wed, 12 Mar 2008 17:49:00 GMT

Oggi Raf sul messenger mi chiede se conosco un modo piu' diretto per capire se un tipo sia primitivo oppure String o DateTime (questo per evitare degli if...). Pensandoci un po', arrivo a questa soluzione:

(int)Type.GetTypeCode(type) > 2

dove type e' il tipo in causa. Lui prova e mi dice che va benissimo mentre io gia' sto pensando di bloggare questa riga di codice :-) L'enum TypeCode infatti, contiene nella sua lista di valori maggiori a 2 tutti i 12 tipi primitivi piu' il DateTime e lo String, proprio quello che voleva Raf. A questo punto gli chiedo come denominare questa categoria di tipi? Primitivi non sono, built-in (ECMA-335, Partition I, 8.2.2) nemmeno, boh... fondamentali? Qui Raf si ricorda che "in una alpha erano refclass adesso non piu'". E poi fa questa osservazione giusta:

Raffaele MVP says (4:45 PM):
io comunque metterei >2 e <18
non si sa mai che aggiungano altre enum in futuro
<drian says (4:46 PM):
hai visto che manca 17?
Raffaele MVP says (4:46 PM):
non ci ho fatto caso
<drian says (4:47 PM):
in questo caso, dovrei fare anche != 17, perche' il 17 per adesso manca
e diventa un po' una schifezza
Raffaele MVP says (4:48 PM):
a questo punto puoi legarlo ad una versione specifica di quell'assembly ma poi non funziona più automaticamente
Raffaele MVP says (4:49 PM):
o ancora metterlo typesafe
>=boolean <=string
ma c'è sempre il 17 a rompere

Spulciando poi i sorgenti di Rotor, trovo questo commento nel file dell'interfaccia System.IConvertible

// The IValue interface represents an object that contains a value. This
// interface is implemented by the following types in the System namespace:
// Boolean, Char, SByte, Byte, Int16, UInt16, Int32, UInt32, Int64, UInt64,
// Single, Double, Decimal, DateTime, TimeSpan, and String. The interface may
// be implemented by other types that are to be considered values.

Cosa notate? Esattamente l'elenco di tipi che interessava Raf, nell'ordine di TypeCode e... in piu' il TimeSpan tra il DateTime = 16 e lo String = 18, cioe' corrispondente proprio al 17 che mancava! Questa interfaccia, IValue, non esiste piu' nel framework ma alcuni commenti su varie implementazioni del metodo GetTypeCode() sono rimasti come:

// IValue implementation

perche', probabilmente, conteneva questo metodo GetTypeCode. Questa ormai e' "archeologia" di .NET! :-) E non e' tutto. Guardate nei commenti dell'enum System.TypeCode:

// Note that when an object has a given TypeCode, there is no guarantee that
// the object is an instance of the corresponding System.XXX value class. For
// example, an object with the type code TypeCode.Int32 might actually be an
// instance of a nullable 32-bit integer type

Questo comportamento non e' piu' vero, perche' il valore di Type.GetTypeCode(typeof(int?)) e' TypeCode.Object, mentre il valore di Type.GetTypeCode(typeof(int)) e' TypeCode.Int32!

Dopo una discussione tecnica con Raf, direi che sia impossibile non cliccare "New Post"! :-)

L'OR Designer e' stato scritto con DSL Tools

Adrian Florea — Mon, 21 Jan 2008 14:29:06 GMT

Lo sapevate che l'Object Relational Designer e la parte di generazione di codice per le classi LINQ to SQL in VS2008 sono state scritte utilizzando Microsoft DSL Tools che fa parte di VS SDK? - l'ho scoperto tramite il Reflector mentre studiavo l'API di questo potentissimo framework che e' DSL Tools: tra le classi che derivano da Microsoft.VisualStudio.Modeling.ModelElement, classe fondamentale per la rappresentazione degli elementi di un domain model, si trovano anche le classi internal dell'OR Designer. Questo dovrebbe dare piu' fiduccia a chi inizia o valuta di estendere Visual Studio per un certo DSL utilizzando DSL Tools! - parti complesse del VS stesso iniziano ad essere sviluppate con questo framework.

raise accessor in C++/CLI

Adrian Florea — Tue, 09 Oct 2007 09:37:28 GMT

Due anni e mezzo fa, parlavo in questo post, di tre eventi all'interno delle classi del framework, tutti e tre nell'assembly Microsoft.VisualBasic.dll, provvisti non solo dei classici accessor add e remove, ma anche di raise (.fire in IL), accessor che non esiste ancora in C# e finivo il post chiedendomi in quale linguaggio sia stato scritto quell'assembly, Microsoft.VisualBasic.dll.

E oggi scopro che C++/CLI (ECMA-372, 19.6.2) mette a disposizione tre accessor anziche' due: add, remove e raise. Quindi, lo snippet del mio vecchio post, diventa in C++/CLI:

delegate void FooFiredEvent();

ref class Foo {
    FooFiredEvent^ m_FooFired;

    public: event FooFiredEvent^ FooFired {
        void add(FooFiredEvent^ value) {
            m_FooFired += value;
        }
        void remove(FooFiredEvent^ value) {
            m_FooFired -= value;
        }
        void raise() {
            if(m_FooFired) {
                m_FooFired();
            }
        }
    }
};

Un modo di marcare il valore di default di un enum

Adrian Florea — Sun, 29 Jul 2007 07:12:00 GMT

"Do provide a value of zero on simple enums" dice una linea guida del FDG (p. 95). Ma forse sarebbe ancora piu' espressivo marcare questo valore di default di un enum appunto come una default value expression (ECMA-334, 14.5.14) anziche' impostarlo a 0. Cioe', scrivere:

public enum Compression
{
    None = (int)default(Compression),
    GZip,
    Deflate
}

al posto di None = 0. In ogni caso, il compilatore genera lo stesso IL. E' solo un'idea, che ne dite?

GetCallingLanguage [la soluzione di un quiz di Claudio Brotto]

Adrian Florea — Mon, 09 Jul 2007 06:04:00 GMT

Un po' di mesi fa, Claudio Brotto, aveva proposto un simpatico quiz a cui vorrei dare adesso una soluzione (in realta' la soluzione e' per una variante leggermente modificata del quiz). Si tratta praticamente di scrivere un metodo pubblico in un assembly in tal modo che, chiamandolo da un altro assembly, questo metodo produca una stringa diversa in base al linguaggio in cui e' stato scritto l'assembly chiamante. Per esempio, questo metodo dovrebbe ritornare la stringa "C#" se chiamato da un assembly scritto in C#, oppure "Basic" se chiamato da un assembly scritto in VB.NET, etc. Piccolo vincolo della mia soluzione: l'assembly chiamante deve essere compilato in debug mode.

Tutto si basa su un metadato che il compilatore inserisce nell'assembly quando compiliamo in debug mode e che serve ai vari debugger. Cercate nel file "foo.il" ottenuto da un “foo.cs“ qualunque:

csc /debug+ foo.cs
ildasm foo.exe /linenum /out:foo.il/

la direttiva ".language" (vedi C.3, Partition VI, ECMA-335) e troverete 3 GUID che identificano rispettivamente il linguaggio, il vendor (cioe' il compilatore) e il documento. Solo il primo, cioe' il GUID del linguaggio, e' obbligatorio nella direttiva ".language". Per vedere l'elenco dei linguaggi mappati da questi GUID, andate nel file "C:\Program Files\Microsoft.NET\SDK\v2.0\include\corsym.h".

Come possiamo pero' ottenere dal codice, questa informazione? Dopo un po' di giri col Reflector, ho trovato la classe giusta, System.Diagnostics.SymbolStore.SymDocument, nell'assembly "ISymWrapper.dll" (nella cartella del framework). In questa classe notiamo la proprieta' Language di tipo Guid che ci dara' il GUID del linguaggio, incontrato sopra nel file ".il". Il costruttore di questa classe, nonostante pubblico, non ci aiuta tanto, visto il pointer bruttino che non possiamo passarglielo come argomento... Ma sempre coll'aiuto del Reflector, scopriamo chi utilizza questa interessante classe: il metodo GetDocuments della classe System.Diagnostics.SymbolStore.SymReader. E qui la stessa storia per il suo costruttore pubblico, ma indagando che altra classe utilizza la SymReader, arriviamo alla System.Diagnostics.SymbolStore.SymBinder, che finalmente ha un costruttore pubblico senza parametri!

Bene, in questa classe SymBinder, andiamo a vedere un po' il metodo GetReader con il quale potremo ottenere un'istanza di SymReader, e da qui ottenere un'istanza di SymDocument, per arrivare poi al GUID del linguaggio.

In questo metodo GetReader, incontriamo un parametro chiamato "importer", di tipo IntPtr, che punta (dice la documentazione) sulla "metadata import interface". Questa interfaccia, IMetadataImport, si trova, insieme alle altre interfacce unmanaged per i metadati, documentata nel MSDN a questa pagina probabilmente poco visitata. Il giro non e' finito perche', per ottenere un'istanza importer di IMetadataImport, abbiamo bisogno di un "dispenser" a cui chiedere di aprire il file dell'assembly (tramite il metodo OpenState) e trovare l'istanza dell'importer in un parametro out. L'istanza del "dispenser" la otteniamo conoscendo il CLSID_CorMetaDataDispenser (vedi il file "cor.h" - l'header generale del runtime se avete downloadato il SSCLI (Rotor)).

Dobbiamo definirci queste due interfacce unmanaged, decorandole con i loro GUID presi sempre dal file "cor.h", ma senza dover definire necessariamente i metodi che non ci interessano - per questo motivo ho messo dei metodi Dummy, semplicemente per occupare lo slot di un metodo che non ci interessa e per poter cosi' arrivare correttamente al metodo OpenState che e' il secondo metodo dell'interfaccia.

Quello che ho detto sopra, viene implementato cosi' (sicuramente non e' perfetto come codice ma serve solo per illustrare il concetto):

// foo.cs
// csc /t:library /r:ISymWrapper.dll foo.cs
using System;
using System.Reflection;
using System.Collections.Generic;
using System.Runtime.InteropServices;
using System.Diagnostics.SymbolStore;
using System.Diagnostics;

[
    Guid("7DAC8207-D3AE-4c75-9B67-92801A497D44"),
    InterfaceType(ComInterfaceType.InterfaceIsIUnknown),
    ComVisible(true)
]
public interface IMetadataImport
{
    void Dummy();
}

[
    Guid("809c652e-7396-11d2-9771-00a0c9b4d50c"),
    InterfaceType(ComInterfaceType.InterfaceIsIUnknown),
    ComVisible(true)
]
interface IMetaDataDispenser
{
    void Dummy(); // DefineScope
    // https://msdn2.microsoft.com/en-us/library/ms231248.aspx
    void OpenScope
        (
            [In, MarshalAs(UnmanagedType.LPWStr)] string szScope,
            [In] int dwOpenFlags,
            [In] ref Guid riid,
            [Out, MarshalAs(UnmanagedType.IUnknown)] out object ppIUnk
        );
}

public class Metadata
{
    public static string GetCallingLanguage()
    {
        Assembly assembly = Assembly.GetCallingAssembly();
        foreach (DebuggableAttribute attribute in assembly.GetCustomAttributes(typeof(DebuggableAttribute), false))
        {
            if (!attribute.IsJITTrackingEnabled)
            {
                throw new NotSupportedException("Calling assembly not built in Debug mode");
            }
        }
        string location = assembly.Location;

        Guid CLSID_CorMetaDataDispenser = new Guid("e5cb7a31-7512-11d2-89ce-0080c792e5d8");
        Guid IID_IMetadataImport = new Guid("7DAC8207-D3AE-4c75-9B67-92801A497D44");

        object importerObj;
        IMetaDataDispenser dispenser = (IMetaDataDispenser)Activator.CreateInstance(Type.GetTypeFromCLSID(CLSID_CorMetaDataDispenser));
        dispenser.OpenScope(location, 0, ref IID_IMetadataImport, out importerObj);
        IntPtr importer = Marshal.GetComInterfaceForObject(importerObj, typeof(IMetadataImport));
        ISymbolReader reader = new SymBinder().GetReader(importer, location, string.Empty);

        // see LanguageType module in
        // C:\Program Files\Microsoft.NET\SDK\v2.0\include\corsym.h
        Dictionary languages = new Dictionary();
        languages.Add(new Guid("3f5162f8-07c6-11d3-9053-00c04fa302a1"), "C#");
        languages.Add(new Guid("3a12d0b8-c26c-11d0-b442-00a0244a1dd2"), "Basic");
        // ...

        return languages[reader.GetDocuments()[0].Language];
    }
}

Adesso, questo codice:

// bar.cs
// csc /r:foo.dll /debug+ bar.cs
class Test
{
    static void Main()
    {
        System.Console.WriteLine(Metadata.GetCallingLanguage());
    }
}

stampera' C# a console, mentre questo:

' bar.vb
' vbc /r:foo.dll /debug+ bar.vb
Class Test
    Shared Sub Main
        System.Console.WriteLine(Metadata.GetCallingLanguage())
    End Sub
End Class

che e' identico con quello C# ma scritto in VB.NET, stampera' Basic :-)

Le 19 cose impossibili delle classi statiche

Adrian Florea — Sat, 24 Mar 2007 01:43:00 GMT

Per ottenere l'elenco completo delle cose che NON si possono fare con le classi statiche, e' piu' facile andare nel file "errors.h" di SSCLI 2.0 e cercare gli errori che riguardano le static class. L'elenco ottenuto e' piu' dettagliato rispetto a quello del paragrafo 17.1.1.3 delle specifiche:

CS0418, AbstractSealedStatic ("una classe astratta non può essere sealed o static")
CS0441, SealedStaticClass ("una classe non può essere contemporaneamente static e sealed")
CS0708, InstanceMemberInStaticClass ("impossibile dichiarare membri di istanza in una classe statica")
CS0709, StaticBaseClass ("una classe non può derivare da una classe statica")
CS0710, ConstructorInStaticClass ("le classi statiche non possono avere costruttori di istanza")
CS0711, DestructorInStaticClass ("le classi statiche non possono contenere distruttori")
CS0712, InstantiatingStaticClass ("impossibile creare un'istanza della classe statica")
CS0713, StaticDerivedFromNonObject ("le classi statiche devono derivare da System.Object")
CS0714, StaticClassInterfaceImpl ("le classi statiche non possono implementare interfacce")
CS0715, OperatorInStaticClass ("le classi statiche non possono contenere operatori definiti dall'utente")
CS0716, ConvertToStaticClass ("impossibile convertire in un tipo statico")
CS0717, ConstraintIsStaticClass ("impossibile utilizzare le classi statiche come vincoli")
CS0718, GenericArgIsStaticClass ("impossibile utilizzare tipi statici come argomenti generici")
CS0719, ArrayOfStaticClass ("gli elementi di una matrice non possono essere di tipo statico")
CS0720, IndexerInStaticClass ("impossibile dichiarare indicizzatori in una classe statica")
CS0721, ParameterIsStaticClass ("impossibile utilizzare tipi statici come parametri")
CS0722, ReturnTypeIsStaticClass ("impossibile utilizzare tipi statici come tipi restituiti")
CS0723, VarDeclIsStaticClass ("impossibile dichiarare una variabile di un tipo statico")
CS1057, ProtectedInStatic ("le classi statiche non possono contenere membri protected o protected internal")

Magari a qualcuno serve come riferimento.

Quiz Sharp #61 [la soluzione]

Adrian Florea — Thu, 22 Mar 2007 05:36:00 GMT

La soluzione al Quiz Sharp #61 mi sembra abbastanza interessante per meritare un post a parte (nomi come Miguel de Icaza, Jon Skeet, Abhinaba Basu, hanno considerato strano il comportamento del compilatore C# 2.0 nel comparare i valori value type a null)

La risposta corretta al quiz e' che eseguendo lo snippet si ottiene un'eccezione a runtime (StackOverflowException). Vediamo di seguito il perche', con le specifiche in mano:

Per evaluare l'espressione value != null nell'implementazione dell'operatore, dove value e' un not-nullable value type, il compilatore applica alcune conversioni. Per esempio, per ogni nullable type, esiste una conversione implicita dal tipo null al tipo nullable (ECMA-334, 13.7.1). Inoltre, una volta definito l'operatore di conversione implicita da Foo a bool, in cui sia Foo che bool sono not-nullable value types, esistono automaticamente anche le conversioni nullable (ECMA-334, 13.7.2) implicite da Foo? a bool? e da Foo a bool? e la conversione esplicita da Foo? a bool. Quest'ultima non ci interessa perche' e' esplicita. Ci interessa invece quella da Foo a bool? perche', in questo modo, la comparazione a null nell'espressione si farebbe tra due nullable types (bool? entrambi). Su come si applica la nullable conversion da Foo a bool?, c'e' scritto nelle specifiche (13.7.2): "If the nullable conversion is from S to T?, the conversion is evaluated as the underlying conversion from S to T followed by a wrapping from T to T?", quindi prima si applica la conversione sottostante, da Foo a bool, seguita poi da quella da bool a bool?. Ma quella da Foo a bool e' proprio la conversione implicita che stiamo implementando, percio' siamo nella ricorsione che ci porta alla StackOverflowException... Tra l'altro, il compilatore C# ci avverte con il warning CS0472: "The result of the expression is always 'true' since a value of type 'bool' is never equal to 'null' of type 'bool?'", quindi "null of type bool?" perche' e' gia' stata identificata la conversione nullable.

Per chi vuole spulciare nel codice di SSCLI 2.0, da guardare FUNCBREC::BindNubEqOpCore nel file "operators.cpp".