This is part of a series of questions which focuses on the Abstraction Project, which aims to abstract the concepts used in language design in the form of a framework. There is a sister project to Abstraction called OILexer, which aims to construct a parser from grammar files, without the use of code injection on matches.
Some other pages associated to these questions, related to structural typing, can be viewed here, and ease of use, found here, a question on writing the compiler compiler can be found here. The meta-topic associated to an inquiry about the framework and the proper place to post can be found here.
One of the steps into this process was building my own ECMA-335 Metadata parser. Since I tend to build tools to build tools, I recently decided to do an analytical top-down on the .NET Base Class Libraries. The future goal will be utilizing it to construct libraries which represent the BCL to aid in rapid code generation (more on that later if someone cares.)
Volevo avere un'idea di base delle versioni generali delle librerie all'interno del BCL .NET, quindi analizzai la cartella Framework memorizzata localmente. Fare questo per versione del framework dovrebbe riflettere il sistema dell'utente finale: ora mi sto prendendo di mira.
Il primo passo in questo obiettivo è costruire una classe che concettualizza una libreria multi-versione e tira in ogni iterazione secondo necessità. Il prossimo passo è tirare dentro tutti i tipi da ciascuna versione e confrontare i singoli elenchi di tipi (più stranamente di quanto dovrebbe essere.)
Il risultato è una visualizzazione abbastanza diretta del BCL che interrompe la versione di una libreria introdotto e mostra quale versione sono stati introdotti nuovi tipi, raggruppati per namespace.
Questo dovrebbe essere un elenco completo che esclude i tipi che sono stati introdotti con la libreria stessa. Si può presumere che se non è elencato, era lì dall'inizio della biblioteca. La visualizzazione è molto semplice: +Type significa che è stato aggiunto, -Type significa che è stato rimosso Type->Assembly significa che è stato spostato in quella versione.
Il lato obiettivo di questo è: se è accurato, ti dà una descrizione di base di quando è stato introdotto un tipo, utile per determinare la versione più bassa di .NET necessaria per una determinata funzionalità. Il passo successivo è l'analisi dei membri, che renderà il primo passo semplice (principalmente grazie al confronto delle firme dei metodi, poiché ogni tipo di parametro dovrà essere invertito e controllato).
Sono curioso di sapere se questa analisi potrebbe essere successivamente utilizzata per uno strumento automatico che potrebbe determinare la versione di framework comune più bassa per un assembly nel suo insieme (software che viene scritto dal framework del compilatore che sto scrivendo, cioè)?
Insight benvenuto.
PS: To those wondering why I don't use Reflection, attempt using Type.GetType(string) on any of these:
Microsoft.Win32.Registry, mscorlib, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Microsoft.Win32.Registry, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Microsoft.Win32.Registry, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089It won't fail, but you also won't get what you would expect, even trying to load the 2.0 mscorlib by filename yields the 4.0 assembly.
Modifica : dovrei aggiungere che questa analisi si concentra esclusivamente sugli elementi esposti pubblicamente. La logica di questo è che non dovresti mai concentrarti sulle dipendenze della struttura interna del BCL poiché può cambiare senza preavviso. Se stai scrivendo un generatore di codice e le espressioni sintetizzate si basano su questi tipi, è probabile che il tuo sistema sia fragile come vetro se qualcosa cambia nel framework, come una patch che aggiorna la struttura interna della versione 2.0. A causa di come .NET lega i suoi membri in Common Intermediate Language, questa è una possibilità molto verosimile.