Raja Krishnaswamy and Vance Morrison: CLR 4 - Inside Type Equivalence

Play Raja Krishnaswamy and Vance Morrison: CLR 4 - Inside Type Equivalence

The Discussion

  • User profile image

    Nice guys.  Lots of info about how everything works.  You know alot of diffrence pieces of the .NET framework core depend on each other fairly tightly.  I would think this would be a great feature to use to break up all the different parts  Where each "section" of the .NET core framework would interact with the other parts through an interface.  Then you could even have diffrnet parts of the framework "upgrade" without having to recompile.  Every .NET assembly has inside it all the links that are attached when that DLL is loaded.  I would think it might be possible to then figure out which sections (and versions of those sections) that were needed and then download just that small little piece of the .NET framework.  Like say you had a WPF app.  On running it finds the client doesnt have the "whole" .NET framework and that it needs to load the new pieces, it could only download the WPF stuff (and the stuff that requires), and nothing to do with ASP.NET or winforms or debugging etc.  Lots of intresting ideas on how to build my own frameworks using this.

  • User profile image

    I'm glad this has given you some ideas! Your thinking is solid.

    Indeed, as we discussed towards the end of this conversation, this is only the beginning of the potential for .NET framework modularity (using type equivalence as well as other core capabilities). In terms of designing your own frameworks, composability should be front and center in your design, as you clearly understand. The design and implementation problems to solve will increase with the degree of functional generality afforded by your framework. It's a very good thing for .NET that folks like Raja and Vance spend lots of time working on these problems. The future is bright.


  • User profile image
    Stone Cedar

    Raja and Vance: you guys rock. I'm thinking, when being first exposed to these new concepts, if I should be approaching from the point of WF and WCF. Any suggestions? I'm an old time developer going back to 1975 with Unix and since then, always with Microsoft. Given a recent sabatical (7 years out of the loop based on a hardship disability), it's a gift that you share freely your perceptions. Thank you.

    Jesse (Rich McGlynn) [a stone]

    P.S. I've been busy though, those 7 years, shown by musical composition mine found at http://www.myspace.com/stoneCedar. I bet that quite a few members of the Mircosoft team are musicians. Set up a web site: The Microsoft Musicians Perform (MMP a new model). Cool!

  • User profile image

    Wow. This sounds really great. Common embeded interface definitions is something I have often wished for this kind of thing in the past and this sounds like a really excellent implementation.

    On a related note I have another "problem" that I guess this tyep of approach might one day be able to solve?

    Like I suspect many people I now have a large library of extension methods which i commonly use embeded in a dll. Most of these are extermely simplistic but just make the code easier to read. Currently every app I write has to be shipped with a copy of the dll that implements these extension methods. However many small apps only use a very small number of these extension methods. In addittion new extension methods are often added. This results in lots of versions of this libary dll being distributed. In practice however these extenstions are really about cleaning up code syntax and the code will in effect evetualy be inlined. They are in effect a bit like code snippets. It would seem much better if these exensions were simply embbeded by the complier when used so i didnt need to ship a seperate big dll. Perhaps one day this technology might make that possible.



Add Your 2 Cents