Skip to content
Fetching latest commit…
Cannot retrieve the latest commit at this time.
..
Failed to load latest commit information.
displayers
finders
formatters
.cvsignore
AssemblyInfo.cs
COPYRIGHT
ChangeLog
DESIGN
Factories.cs
IPolicy.cs
LICENSE
Makefile
Node.cs
NodeGrouper.cs
NodeInfo.cs
NodeTypes.cs
Policy.cs
ProgramOptions.cs
README
TODO
TestTypes.cs
TextFormatter.cs
TypeFactory.cs
TypeLoader.cs
TypeReflectorApp.cs
TypeReflectorOptions.cs
type-reflector
type-reflector.build
type-reflector.exe.config
type-reflector.in
unix.args

README

Overview
========
``type-reflector'' is a program similar in spirit to the .NET ``TypeFinder'' 
SDK Sample.  As is often the case with Unix-style programs, it has more
program options and more flexibility.

It allows a regular expression (as understood by 
System.Text.RegularExpressions) to be used for finding types.

It allows a specific list of assemblies to be searched to be specified,
narrowing down the list of assemblies searched for a matching type.

It also allows the types to be viewed according to three different policies.
The "finder" policy dictates how members are found.  There are currently two
such policies:

  explicit - Searches for members by name
  reflection - uses System.Reflection for member lookup

The finder policies often display different results, as "explicit" has had
more work done on it, and "reflection" is dependant upon System.Reflection,
which may or may not be complete, depending on the platform.

The second policy is the "formatter" policy, which dictates how a member is
displayed.  There are currently three such policies:

  default - typically the result of .ToString() on the member reflection object
  csharp - attempts to display the member as if it were from C# source code.
  vb - attempts to display the member as if it were from VB.NET source code.

The third policy is the "displayer" policy, which is how the members are
displayed to the user.  This is described below.

Type Reflector shows (virtually) everything about a type that is available
through the System.Reflection facility.  Everything from the actual Attributes
specified for a member, to custom attributes, the reflected type, GUID, where
it was declared...  This constitutes a great deal of information that isn't
normally present without writing test programs to view the available
information.

I prefer to think of it as the "Frankenstein" combination of ``TypeFinder''
and a debugger.  It doesn't just find types.  It doesn't just display the
members of those types.  It will also (when able to) display the result of
invoking methods on a type.  The method must fulfill some limitations:

  - There must be a valid object instance.  For arbitrary types, this
    effectively means you can only get the result of invoking static
    methods/properties, but this can be useful when looking at Reflection
    objects.

  - The invoked methods must accept 0 arguments.

Thus, for the C# class definition:

    public class Test {
        public static int Foo {get {return 42;}}
    }

we can use type-reflector to determine the value returned by Test.Foo.

This is also useful for determining the values of class constants/readonly
fields and properties, such as Enumeration values.

There is also support to invoke (and display the return value) of class
methods that accept no arguments.  However, due to "problems" [1] this is not
enabled by default; pass the -n argument to enable.

[1] Some of the mono tools do actual work in their static methods that accept
no arguments.  For example, using Type Reflector on itself to display the
member Mono.TypeReflector.TypeReflectorApp.PrintVersion would display the
version information to the console.  Other apps request user input when
invoked, halting all display until the user presses a key.  Displaying all
libraries would cause core dumps as gtk_init could be called before gdk_init
(as they were P/Invoked from the Gtk# assemblies) during this process.

I thought this would be cool, but unless you're careful, things can get weird.


Displayers
==========
Type Reflector has three displayers, the "console" displayer, which sends
output to the console, and two GUI front-ends, the availability of which
depends upon which platform you're on.  The front-end is specified with the 
--displayer program argument.

All front ends have their own makefile target.  For now, the "gui" target 
attempts to compiles in support for all displayers (Gtk#,
System.Windows.Forms, and Console output).

The ``--displayer'' argument is no longer required in order to use GUI output.
The displayer to be used is specified in the .config file.  (In the
<appSettings/> element, <add/> sub-element with attribute
key="displayer-order".  XPath: 
  /configuration/appSettings/add[@key='displayer-order'].)

The current order is Gtk#, followed by System.Windows.Forms, followed by
console output.  If you don't like this order, change the entry so your
preferred displayer is first.

Gtk#
----
The Gtk# front-end uses (duh!) Gtk#.  And Glade#.  And any other Gnome
technology I feel like throwing in at any given point in time.  Ahem.
To compile it, run:

  make -f makefile.gnu gtk

To run it, pass ``--displayer=gtk'' on the command line:

  type-reflector.exe --displayer=gtk --use-default-assemblies .

This will display all types in all assemblies; it takes ~25 seconds to finish
loading (PIII 700 MHz notebook).


System.Windows.Forms
--------------------
The Windows.Forms front-end is the "swf" displayer.  To compile, run:

    make swf

This must be done on a Windows box, as (at present) the Mono
System.Windows.Forms implementation will not permit compilation.

To run it, pass ``--displayer=gtk'' on the command line:

  type-reflector.exe --displayer=swf -S --use-default-assemblies .

Something went wrong with that request. Please try again.