Software Geek

Also see: Sliced Bananas On Opaque Data

Also see: Applied Metamodelling: A Foundation for Language Driven Development

Also see: From C# to Java: Part 4

Also see: ASP.NET MVC in CodePlex and Extensible Unit Testing

Also see: Uniqueness Typing Simplified

Also see: Silverlight 2 Developer Poster

Also see: LINQ - The Uber FindControl

Also see: The obligatory Halo 2 partial review and thumbs up.

Also see: Versioning/Deploying Unmanaged Files

Also see: A first stab at BaseN encoding with a focus on general alphabet encoding.

Also see: Parallels adds “Express Windows Installation”

Also see: Infrequent blogging

Also see: VS.NET Macro To Group and Sort Your Using Statements

Also see: Stand alone FXCop download

Also see: AppDomains (”application domains”)

Also see: LoadFrom’s Second Bind

Also see: Generating WPF Content with LINQ

Also see: Solving big business problems in our little toolbox application. A use case for Project Distributor.

Also see: A first stab at BaseN encoding with a focus on general alphabet encoding.

Also see: Access to old blogs

Also see: Language parsing and compiler design doesn’t have to be hard, but boy this book really sucks!

Also see: Generating WPF Content with LINQ

By “Frameworks assemblies,” I mean the assemblies that ship with the CLR. But, I’m not counting mscorlib.dll , since it’s special in a different way.

With v1.0 SP3 or later, Frameworks assemblies are unified. That means that the version of those assemblies that you request is ignored - you get the version that matches the loaded CLR. This only applies when the assembly is loaded by version - that is, by assembly display name or static reference (AssemblyRef in the CLR metadata).

For example, if the v1.1 CLR is loaded and you request v1.0’s system.dll, then you’ll get the v1.1 system.dll back. If you load it by path from c:\foo\system.dll, however, then you’ll get c:\foo\system.dll back, not the v1.1 system.dll.

Those assemblies are unified because the owners of the code feel that they are so closely tied to the CLR/mscorlib.dll that they should not be loaded with a different version than they were built against. Additionally, there are some cases where they expect that only one copy of the Frameworks assemblies be loaded in a given process.

If the v1.0 (pre-SP3) CLR is loaded, though, you will get the assembly that you ask for. Unification isn’t done for Frameworks assemblies in that version.

Do not rely on this behavior. You should still fully-specify assembly references with the correct version. That’s just good practice, in general. Besides, if your assembly is loaded in a CLR later than v2.0, those references may not be unified,

Also see: Parsing things you don’t understand

Also see: Bloggers in the Mavs Locker Room ?

Also see: Cool Silverlight Momentum Video Posted