An interview with Jamie

Ok, just when we all had the WinFX name firmly stuck in our heads, they went and changed it! Why? What does this mean for you? What folders will you end up with in your Microsoft .NET directory? All these answers and more in this interview Duncan did with
Jason Zander from the .NET Framework team.
Did I understand it correctly that .Net 3.5 will have red bit changes for all components, although in small numbers? You mentioned that .Net 3.5 will require some servicing on the .Net 2.0 stuff, especially for the compiler integration in case of Asp.Net
etc. You also mentioned that it will probably require some red bit changes to the .Net 3.0 stuff, i.e. the WPF stuff.
If I understood this correclty, this is a case where your decision is not a marketing decision any more. While you can be as careful as you want with those red bit changes (and I do appreciate this a lot!), this still means that we might end up in a situation
where my app requires DLINQ stuff, therefore I have to install .Net 3.5, and then one of the red bit changes to WPF breaks some third app. Had you not bundled things, I could have installed the stuff needed for DLINQ without a need to apply the red bit changes
to WPF. And, I would have preferred that
See now it all makes sense.... hopefully now this means that in the future this kind of stuff will be made clearer upfront....good job explaining the differences.
Chadk wrote:Was this interview edited? At 26:23 and 26:40(That is estimates), there are either small "jumps", or it was edited.
David – some answers to your questions:
1. The May CTP of LINQ is using simple copy only because setup was not prepared for that release. Our setup team is working on the net .NET Framework now so some future build will have it integrated.
2. OS support: we are not planning to have the NETFX partially installed on operating systems that cannot support the entire system. There are a couple of reasons for this including simplicity and our desire to reduce the overall test matrix. For this reason,
“NETFX 3.5” will not support W2K as pieces of NETFX 3.0 do not support this sytem.
3. Red Bits: red bits are simply servicing changes (bug fixes in general) to components that have already been installed. When “NETFX 3.5” ships, we’ll know what the final set of red bits changes are. It will be any rolled up bug fixes and a small set of
changes required to help enable the green bits.
4. Packaging. I understand the benefits that come from packaging small pieces of a framework. This is not the overall design the NETFX has taken historically. We believe it is very important to be able to do central servicing of assemblies in the case of
a security issue. It is also easier for a developer to write code that says “do you have NETFX 3.0 on the machine” instead of testing on a much smaller granularity. The trade off is the size of the overall package and the potential for impact of bug fixes
installed by other applications. There are reasonable sides to this argument. I do hear and appreciate your feedback.
5. WPF for “NETFX 3.5”. WPF is just another piece of NETFX. So just like any other component, it will have some red bits changes and will add some new green bits. The final set of features is TBD.
Jason
JasonZ wrote:
1. The May CTP of LINQ is using simple copy only because setup was not prepared for that release. Our setup team is working on the net .NET Framework now so some future build will have it integrated.
JasonZ wrote:
3. Red Bits: red bits are simply servicing changes (bug fixes in general) to components that have already been installed. When “NETFX 3.5” ships, we’ll know what the final set of red bits changes are. It will be any rolled up bug fixes and a small set of changes required to help enable the green bits.
David - You are correct that to use LINQ you will need to provision the 'NETFX 3.5' release on the machine. It was never the intent to have a long term xcopy deployment for LINQ or any other component of the .NET Framework.
There are trade offs to be made in packaging. You can break things up into very small units and try to install them separately, however that explodes the test and servicing matrix. You could try to install the FX pieces with the application itself, but this leads to other side effects (can I find all copies to service them? what is the working set hit of having many flavors of the same code running on the machine at once?). I outlined some of these kinds of issues at the extreme edge of isolation, static linking of code (some examples: https://blogs.msdn.com/jasonz/archive/2004/01/31/65653.aspx).
The other thing to consider is the relationship between pieces of code in the system. When we ship LINQ, we want to make sure it works well with the existing components. You'll see data binding for example in UI frameworks. I know its hard to believe,
but we often fine bugs or design disconnects when trying to hook up something new to something old (no no, its true ). That requires us to service the old code. Consider the spectrum of solutions people want to write:
1. Author a console app to use LINQ. No problem, this should just work by adding just LINQ to the machine.
2. Manually integrate LINQ into a UI app. This will probably work without touching the old stuff. You will be loading a new compiler runtime library (in the case of VB or other languages that add LINQ support), so that is the most likely culprit to break existing code and require a bug fix.
3. You want to do data binding with VS rather than plumbing everthing manually. Shoot, found a bug in that UI layer I shipped 1.5 yeas ago, need a fix to make it work. etc.
Given the broad spectrum of solutions people are writing, we need to balance all of the elements (simplicity, servicing, isolation/impact, security, working set).
davida242 wrote:I simply don't see how a quite high up manager will be able to evaluate how bad the impact on some little red bit change way down in WPF will be to deployed apps
In reality we aren't going to rely on any one person to vet the changes. We are following far more rigorous process (https://blogs.msdn.com/jasonz/archive/2005/04/25/411925.aspx).
Beyond that let's not paper over reality: making any change, no matter how harmless, can break an app. I have seen bugs exposed simply by making the engine perform faster. So your point on the danger of changes is valid. At this point I am not convinced,
however, that going to a point of pure isolation is the best answer on the whole.
On the comparison to Windows, we are following the same kind of guidelines they are. Windows has an even bigger compat challenge in that they really don't have a side by side solution. That means making WIN32 bug for bug compatible with the code written many,
many years ago. We added side by side into .NET precisely for this reason. But it is not a total magic bullet.
Finally let me wrap up by saying that we are evaluating new models for this kind of problem space. In particular we announced at Mix'06 the WPF/E project including managed code support. This problem space is quite interesting and allows us to look at other
models. I hear the feedback from the community, and I do want you to know we are working on ways to get the best balance out of the system.
gdesroches wrote:I would like to be able to compile once and use WPF only if it is available on the user's machine via the plug-in. As long as the user has 3.0, WPF should be available to my plug-in DLL, right?
JasonZ wrote:
Darn, looks like my pointy hair is showing too much these days. I could tell you about being a dev on the project for many years and writing a bunch of code that is in the engine today, but that's just me trying to sooth my ego![]()
David - no worries, your point is valid and well taken.davida242 wrote:Sorry, thinking about this, my wording was not very nice. I guess I just wanted to make the point that regardless of the process you choose inside MS, there is no way that you can make sure to not break some apps out in the wild when you do red bit changes.
I don't believe your scenario is new to NETFX 3.5, however. This is how things work today. For example if vendor C, authoring a 2.0 application, requests the hot fix (QFE) for the error or makes the V2.0 SP that contains the fix a pre-requisite, then installation of 2.0 application C will break application A. It no longer becomes necessary to construct the transitive case of NETFX 3.5 being involved (app B).davida242 wrote:If this is the sort of servicing you are considering, it will end really, really bad.
We actually do have a level of shimming the .NET FX as well. As an example, we implemented deterministic COM apartment initialization in the 2.0 product. We found that too often in the v1.x product the "first one in wins" semantics would break applications in random ways. We added an app compat switch (e.g. a shim) that allows you to turn this behavior back to the old ways. We have a CLR version binding shim that allows us at managed code startup to check the registry to see if this process has overrides on which version of the CLR should be loaded. We can deploy the shim to make sure a particular version of an application is not broken by deployment of a new NETFX.davida242 wrote:In Windows. It just is an elite side-by-side story called skimming.
The problem here is that the simplest red bit change is just a bug fix. I think it becomes too constraining to never fix bugs in deployed DLLs. What we do instead is try to set a very firm bar on what is acceptable, we do due diligence on reviews, we test the heck out of it, and we fall back to shimming when we are truly between a rock and a hard place.davida242 wrote:1) Never ever do red bit changes to deployed DLLs because it will break apps on customers desktops
This provides insight on another set of tension points. One of the key values of Visual Studio + NETFX is the seamless integration of the entire stack. It really makes it far easier to author your applications. We could solve this problem by releasing a new SxS NETFX frequently with the features. This is not desirable to many of our customers: enterprises don't want to take big new releases very frequently, and ISV's like to see something get out to a lot of machines so they don't have to redistribute new versions along the way. Internally we have the pressure of servicing a lot of product versions in parallel (we only have so much capacity). So we need the right kind of balance here.davida242 wrote:3) In particular, don't service deployed binaries with red bit changes in order to enable cool new stuff, like integration of DLINQ with data binding.
LINQ has never been a feature of NETFX 3.0. LINQ will ship with NETFX 3.5 and will have Visual Studio support.raymond wrote:Does this mean both the Expression Suite and/or LINQ are not fully baked or ready for prime time?
The Expression folks are literally around the corner from me so I will pass this feedback along. Thanks also for your suggestions on more content links, that is a great idea.raymond wrote:The silence around the Expression Suite in terms of followup videos is beginning to disturb me.
Raymond - I spoke with the Expression folks and they pointed out they are releasing monthly CTP's. The sites to check out for the July CTP are here:
Interactive Designer:
https://www.microsoft.com/products/expression/en/interactive_designer/id_free_trial.aspx
Graphic Designer:
https://www.microsoft.com/products/expression/en/graphic_designer/gd_free_trial.aspx
Web Designer:
https://www.microsoft.com/products/expression/en/web_designer/wd_free_trial.aspx.
The forums are also very active and a good source of information.
Jason
Another small point. My understanding was that the name WinFx was used because it was the underlying API of windows Vista which would be built on top of WinFx.
It is apparent that this didn't happen. Se la vi.
BOb