Jason Zander on the WinFX to .NET FX 3.0 rename

The Discussion

• 

  With the May CTP the LINQ stuff can be xcopy deployed, i.e. I can include all needed DLLs as private copies within my own app directory and don't need to run any installer on client computers. This allows for example for ClickOnce deployment on machines that have only .Net 2.0 installed. Will this also be possible with the final release?
  
  If not: Will the .Net 3.5 bootstrapper install on W2K, but just not install the WPF stuff? Because in principle there is no technical reason why the LINQ stuff can't run on W2k, right?

• 

  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

• 

  In general, what is the WPF story for .Net 3.5? As far as I see it there is not much of a side by side story for WPF, right? So, that leaves three possibilities for WPF for the .Net 3.5 release:
  
  1. No changes
  2. Only green bit changes
  3. Red bit changes
  
  Which is it for WPF?
  
  Quite frankly, if it is anything but 1), I believe the decision to bundle things would have been wrong. Because we would be back in old DLL hell days, when installation of a new compiler (in this case LINQ) could break something unrelated, like GDI (in this case WPF).

• 

  Very informative...we can't wait for 3.5!

• 

  Was this interview edited? At 26:23 and 26:40(That is estimates), there are either small "jumps", or it was edited.

• 

  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.

  
  
  No, it wasn't... those are probably issues with my encoding from tape... my machine doesn't do always do a great job of that. Normally, if I notice the jumps, I re-rip from tape, but I didn't see them this time.
  
  No secret info removed though, so no worries

• 

  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
  

• 

  Jason, thanks for the answers. Some follow ups:
  
  

  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.

  
  

  
  
  So no ClickOnce deployment of apps that use LINQ on computers that only have .Net 2.0 installed? The bootstrapper option from ClickOnce doesn't count, because clients need admin rights for that to work. That this is possible with the May CTP is a nice thing, too bad that it seems this is going to get lost in later versions.
  
  

  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.

  
  

  
  
  I simply don't believe in this "a small, controlled number of red bit changes constitutes an additive release." Any single red bit change means that devs will have to do extensive testing on whether something breaks. And if I have an app that has a deployment dependency on something that has red bit changes in areas that my app doesn't even use (like, I have an app that needs LINQ, but doesn't even use WPF, but by requirering NETFX 3.5 for my app, customers of mine need to deploy red bit changes to WPF as well), there is a deployment barrier to my app that was not really needed. I just think any model where we have a situation that I need LINQ, but by installing that on client computers I might break WPF (which I don't use in my app) is broken. And when I look at the public information on what the engeneering group in the Windows division is doing, I get the impression they are working very, very hard to eliminiate things like that. I just wish the same would be true for .Net. But with this latest decision, I get the impression you are more moving away from such a desirable state.
  
  I also appreciate that you will hand review any red bit change. But at the same time I am scared to death seeing that you seem to believe that will solve the problem. 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. And just keep in mind: It WILL have a bad impact and break some apps, there is just no denying of that.

• 

  Let's say I write an application which targets 2.0 and uses Windows Forms, and I want to add some WPF stuff, but I don't want to force all of my users to XP and 3.0 (Most people in my organization are running Windows 2000 and I don't see a migration coming any time soon. Some power users have XP which came with their new machines, and I want to take advantage of these new 3.0 APIs if they are available.). So, I create a "plug-in" DLL which has some of my own custom interfaces and some implementations of them which reference WPF. Then I add logic in my 2.0 app to load this DLL through reflection if a switch is set in my configuration file, and I only access my own custom interfaces from this DLL. I'll probably get an exception if the user only has 2.0, and I can handle that. Is this correct? Also, what if the user has 3.0? The application itself was written against 2.0, but this other DLL was written against 3.0 and is only referenced through reflection. 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?

• 

  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

  
  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  

  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?

  
  
  What you describe should work fine.  You can detect whether 3.0 is loaded or not at runtime as well (https://blogs.msdn.com/jasonz/archive/2006/06/28/650470.aspx) and avoid trying to resolve any 3.0 references on a machine that does not have 3.0 installed.
  
  Note that NETFX 3.0 ships with a Windows Forms/WPF interop feature that allows you to create this kind of hybrid application.

• 

  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  

  
  
  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.

• 

  Jason, also thanks for the data binding example. Lets make a scenario out of that and see what happens.
  
  So, you find a bug in the data binding code in WinForms 2.0 during the LINQ dev cycle that prevents some nice integration of LINQ code with data binding in WinForms. Consequently, you fix that bug in FX 3.5, i.e. you make a red bit change to the WinForms 2.0 DLLs that gets deployed whenever someone installs FX 3.5 (whether that is then packaged as FX 2.0 SP1 or some other way is not really important for my example).
  
  Now, vendor A has a nice little WinForms 2.0 app, developed long before he ever heard anything about LINQ. He discovered the bug in the data binding code as well, and programmed around it. Because that is what happens all the time. So app A (that is vendor A's app) depends on the bug being there to run.
  
  Now, vendor B comes out with app B that uses LINQ, all shiny, all new. He of course integrates the FX 3.5 bootstrapper into his setup, as a silent part of his installation. Some innocent customer installs B, but had A installed previously. The red bit change in the data binding code breaks app A.
  
  Now, the user is fairly sophisticated and recognises that A stopped working after installing B. So, he uninstalls B. But, I suspect this will not uninstall FX 3.5, right? So, it doesn't solve his problem. A is still broken.
  
  To me, this does not look like an unlikely scenario at all, but rather the norm. At the same time, it is an absolute nightmare scenario. It is pre-Windows 2000 system file protection (or however that technology that prevents replacement of system files is called) DLL hell. Third party apps can replace system files silently in their setup that break other apps.
  
  Quite frankly, I am scared to death. If this is the sort of servicing you are considering, it will end really, really bad.
  
  Now, I do see your point that you want a nice integrated experience between WinForms data binding (again, just an example) and LINQ, and lets assume the only way to get this is to fix the bug in the data binding code. What to do?
  
  I believe it is quite helpful to have a look how the Windows group would handle this. First, I doubt that if a team that develops a new feature (like DLINQ) comes to a group with an old feature (data binding) and requests a bug fix that could break old apps that they would do it. The bug is part of the platform, apps rely on it, so the new feature has to live with it. Platform stability in terms of not breaking deployed binaries should always trump nice integration of new features. But, lets assume they agree. They would certainly NOT allow third party apps to silently deploy this with their setup. They might include that fix in some larger package, like a new OS revision, when people expect app problems anyways. So, maybe the team with the new feature will not get the nice integration in their first release, but only once the underlying platform has one of its official "something might break" points.
  
  And then, even when they make a breaking change like that, they have a side-by-side story! In Windows. It just is an elite side-by-side story called skimming. If such a fix would break a popular app, they would supply a skim with the fix that makes sure the old app continues to run. Never ever would they dare to break Photoshop in order to enable nice integration of the new desktop search with explorer, eve with a major OS revision.
  
  This is getting too long, so what would I suggest? I know this is terribly complicated and I probably missed things, but here we go anyways
  
  1) Never ever do red bit changes to deployed DLLs because it will break apps on customers desktops
  
  2) In case of security vulnerabilites, break rule 1
  
  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. The new stuff has to wait for the next side-by-side revision of the base component for the nice integration to happen. This doesn't have to mean that DLINQ has to ship later, it just means one particular integration scenario doesn't work with FX 3.5, but will only be enabled with the next full revision of the framework
  
  4) Maybe, maybe, maybe allow red bit changes to deployed binaries sometimes. But IF that has to happen (and I have not thought much about what would justify this, but make the bar super high), NEVER allow these changes to be silently deployed by third party apps as part of their setup. Do not, ever, provide a bootstrapper that third party ISVs can integrate into their setup experience. Otherwise we will go back to pre Windows 2000 days, when people were afraid to install anything, because it could break their already installed apps. Windows does this in the forms of Service Packs: Everyone knows that they might be problematic and they are never silently integrated into third party apps (at least I hope). But if there is any way you can avoid that at all, I would much prefer that.
  
  Alright, enough
  
  Best,
  David

• 

  I am looking forward to Visual Studio 2007 provided it fully supports both the Expression Suite, mainly Sparkle or Expression Interactive Designer, and LINQ. However, I would have thought this would mean a .NET Framework 4.0.  I am concerned Jason called it .NET Framework 3.5.:O
  
  Does this mean both the Expression Suite and/or LINQ are not fully baked or ready for prime time?
  
  The silence around the Expression Suite in terms of followup videos is beginning to disturb me. If the Expression Suite does not come out in 2007 I am going back to Flash. I will not wait any longer.
  
  Suggestion: have a resources section with links to blogs, books, podcasts, webcasts, etc. pertaining to each video.  I liked the ending where you edited the video and overlaid his blog url address in bold text. Nice touch, keep this up.
  
  Thanks[H]
  
  

• 

  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.
  

  David - no worries, your point is valid and well taken.
  

  davida242 wrote:

  If this is the sort of servicing you are considering, it will end really, really bad.

  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).
  
  Our choice here is to either try to push for some kind of application isolation (each app gets its own copy of the runtime), or to push our compatibility bar high and move things forward.  The blog posts I have linked to above provide some background on the pro's and con's of these two scenarios.  I believe the con's of app local install outweigh the benefits.
  
  

  davida242 wrote:

  In Windows. It just is an elite side-by-side story called skimming.

  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.
  
  I will argue that shims are a necessary evil but not a silver bullet.  Windows fixes a high number of QFE's and do not always catch/shim behavior.  The easiest example to consider is the line of business application inside of a corporation (say the WinForms app you use to fill out employee performance review data, as I just did last week).  There is no way for us to ever test that application directly before shipping a bug fix.  We all do our best based on coverage and vendor reporting.  Some things require a work around.
  
  So I agree there is a healthy tension here between breaking old apps vs the down sides of pure isolation (as outlined in my other blog entries).
  
  

  davida242 wrote:

  1) Never ever do red bit changes to deployed DLLs because it will break apps on customers desktops

  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:

  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.

  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.
  
  This is an excellent debate with hard trade offs to make.  I can tell you that we wrestled with all the same kinds of questions ourselves before arriving at the plan we have in place now.  Later this year we will have out CTP's of the NETFX 3.5 stack.  I'm looking forward to having people try it out and tell us how things are going.

• 

  Raymond - I won't work directly on the Expression Suite so I can't comment on their official ship dates (I'm sure they have posted them some place).
  
  I can tell you however that Sparkle (et al) is written on top of NETFX 3.0 and does not require a newer version.
  
  

  raymond wrote:

  Does this mean both the Expression Suite and/or LINQ are not fully baked or ready for prime time?

  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:

  The silence around the Expression Suite in terms of followup videos is beginning to disturb me.

  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.
  
  Jason

• 

  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

• 

  Jason,
  
  Thank you for the information.
  
  I bet Microsoft marketing is going call the .Net Framework supporting LINQ and Visual Studio 2007, 4.0.
  
  Enjoyed your video interview.
  
  Raymond[H]
  
  

• 

  I thought this was a very helpful video. 
  
  With the complexity of all the different platforms, it was nice to pull it all together and promote some unity amoung them.  I see this as the biggest reason for the name change, and consider it a benefit.
  
  I couldnt help it, I had to blog about this!
  
  http://www.hexanes.com/
  
  Props to Jason.

• 

  Jason,
  
  Something that wasn't addressed that I kept expecting the intervier to ask is how the Visual Studio version relates to the NetFx version?
  
  Currently, correct me if I am wrong, but if you want to target .NetFx1.0 app you MUST use VS.Net. If you want to target .NetFx 1.1 you MUST use VS.Net 2003.
  
  Now that VS 2005 is out, it seems to allow you to target .NetFx 2.0 and 3.0. But, you can't target .NetFx 1.1 with VS 2005. (Yes, I know you can use BEE to compile from VS 2005 to 1.1, but there is nothing in the IDE to ensure that you only use/reference DLL's and features of the 1.1 framework.)
  
  So, now you say NetFx 3.5 (for example) is the next "version" of the framework. Will I be able to target that with VS 2005? Or, will I be required to upgrade to VS.Next?
  
  Also, will VS.Next be able to target .NetFx 3.0 and 2.0 as well as 3.5 while still giving me the new IDE features of VS.Next?
  
  In other words, are there plans to decouple the VS (IDE) version from the framework version and allow tools in the IDE to target a specific .NetFx version?
  
  I know sometimes the new IDE requires the new Fx version to run. That was the excuse as to why you can't use VS 2005 to target .NetFx 1.1 apps. But, it didn't make sense. I have no problem installing .NetFx 2.0 in order to get the VS 2005 features while still wanting to target 1.1 NetFx.
  
  Can you tell I hate having to drop back to VS.Net 2003 to work on my .NetFx 1.1 apps. ???!
  
  BOb
  
  
   

• 

  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

   

• 

  I'm sorry this post won't be constructive but I still want to throw in my .02c...
  
  I'm a full time .NET/ASP.NET developer since beta1 and I think this versioning is horrible. It takes 33 minutes to explain this descision to label .NET 2 addons as .NET 3?
  
  Is this an attempt to pull a Netscape jedi mind trick? Lets start getting all our versions out of sync so it will be even harder for me to sell .NET to my clients.
  
  This is so stupid... Leave the platform alone, release addons, when the platform turns a version, bundle those addons. Let's not show how "innovative" we are by skipping versions.
  

• 

  I think the decision to provide no support for .NET 3.0 on Win2K is going to stop a lot of people from deploying it.  At our organisation, 60% of the organisation is not on XP (and there are no Vista boxes).  This basically means it will be very hard to deploy a .NET 3.0 here for at least another 2 or 3 years.