I'm still undecided about the naming choice. Though they say VFL mean Verein für Longhorn (association for Longhorn), I guess it's because of Jörg's favourite soccer team 😉
Click: Help | Check for Updates | Yes.
The two features I like most are:
- Multi-proc builds: if you have multiple processors in your machine, you can build your projects in parallel. This works through utilizing project dependencies. So projects that don’t depend on one another (directly or indirectly) can build on different processors at the same time. This greatly reduces build times for large solutions that don’t have a lot of linear dependencies.
- Custom build rules: unlike custom build steps, which operate on a per-file basis, custom build rules allow you to specify how to build files of a particular type. So when you add a file of a matching extension to the project, the project system automatically associates the build rule with the file. Custom build rules are defined in XML files external to the project, so they can be applied to multiple projects easily. The best part of custom build rules is their ability to integrate into the project property pages like any of the other “built-in” tools (like the C/C++ compiler, the linker, etc). This means you can have friendly properties like “Include Directories” or “Warning Level” that gets translated into switches that appear on the command line. The look and feel of the integration into the property pages is completely configurable (from what appears in the property grid to what help the user gets when they hit F1 on each property in the property grid). I’ll go into this in more depth in my next post.
The first is great, because we have many multi-processor machines here at my company.
The second is even better. You know, we have developed our own programming language named E, which is a derivate of C. However, instead of classes we have states, i.e. each object is a state-machine. Having said that, in all our E-projects we have custom build steps to call our compiler. With the new Custom Build Rules, we are now able to configure only once how to handle the *.e files.
It has been hell keeping this to myself as Lutz has been sending me beta drops for the last coupla months for the completely reworked Reflector 4.0. Two very cool things about this release of Reflector:
- It supports any version of the .NET Framework, so it works great on Longhorn and Whidbey
- It has a replacement for the Class Viewer tools in the .NET SDK (wincv.exe) that I came to depend on in my writing and that hasn't been updated for WinFX, so Reflector 4.0 is even more important to me than it would normally be
If you're a .NET developer, you must use Reflector and if you use Reflector, you must use Reflector 4.0. Thanks, Lutz! We love you, man!
BTW, Lutz has set up a workspace for the Reflector 4.0 add-ins.
Here're the release notes:
Reflector is a class browser for .NET components. It allows browsing and searching the meta data, IL instructions, resources and XML documentation stored in a .NET assembly. Reflector was first released in October 2000 running on .NET Framework 1.0 Beta 2.
Code Model: While previous versions of Reflector partly used the CLR Reflection infrastructure, the new version 4.0 has changed to use a code model library for reading assembly files into memory. As a result Unload and Refresh operations really unload files from memory and Reflector is no longer locking files on disk.
Reflector and .NET Framework 2.0: Reflector.exe runs on all .NET Framework versions. The new code model library loads .NET Framework 2.0 assemblies with no .NET Framework 2.0 installed. However, a Reflector.exe.config file is still going to make Reflector run faster on .NET Framework 2.0.
Assembly Cache: When resolving an assembly reference, Reflector will first search the local path and then falls back to the cache directories defined in the Reflector.cfg file. Reflector doesn't search the GAC unless you add "%SystemRoot%\Assembly" to the cache directories list.
Search and Callee Graph: There is now only one search window (F3). You can click on the icon on the top-right to switch to search members (this was previously called member search). The reference search windows are replaced with a callee graph window that shows any kind of dependencies of a type or member.
Command Line: The /configuration switch allows you to specify a config file different from Reflector.cfg. The /fontsize and /fontname switches can be used to increase the font size for overhead demos.
Assembly Versioning: By default, assembly version numbers are ignored when resolving type and member references. You can enable side-by-side versioning in the options dialog but it is suggested to avoid this if possible.
WinFX Help: To view the Longhorn MSDN documentation instead of the .NET Framework MSDN documentation add a [WebSearch] section to your Reflector.cfg file with Msdn=http://longhorn.msdn.microsoft.com.
I still don't know, why you're asked for your name and email address before you can download it.
Interesting, how long it takes from making an API obsolete to finally removing it:
An API I was using is now marked obsolete, and gives me a warning. What will happen to it next?
The process for making an API obsolete is phased over time. Once an API is marked obsolete-as-warning, a full release must pass, at which point it will be marked obsolete-as-error. At this point, an attempt to recompile using the API will fail. Marking something as deprecation-as-error can only be performed during a standard release, never during a servicing release. The API will remain in this state for a minimum period of the servicing lifecycle for the release in which it was marked as an error to use. This is typically 7 years. Once that period is over, the API will be removed. At this point, applications attempting to bind or use a version of the library with the API, will fail.