Jason Zander on the WinFX to .NET FX 3.0 rename
- Posted: Jul 19, 2006 at 1:39 AM
- 74,902 Views
- 24 Comments
Download
How do I download the videos?
- To download, right click the file type you would like and pick “Save target as…” or “Save link as…”
Why should I download videos from Channel9?
- It's an easy way to save the videos you like locally.
- You can save the videos in order to watch them offline.
- If all you want is to hear the audio, you can download the MP3!
Which version should I choose?
- If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available).
- If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file.
- If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file.
- If you just want to hear the audio of the video, choose the MP3 file.
Right click “Save as…”
- Mid Quality WMV (Lo-band, Mobile)
- WMV (WMV Video)
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.
Comments Closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums,
or
Contact Us and let us know.
Follow the Discussion
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
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).
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.
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
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.
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.
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: http://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).
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 (http://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.
What you describe should work fine. You can detect whether 3.0 is loaded or not at runtime as well (http://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.
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.
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
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]
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.
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).
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.
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.
I can tell you however that Sparkle (et al) is written on top of NETFX 3.0 and does not require a newer version.
LINQ has never been a feature of NETFX 3.0. LINQ will ship with NETFX 3.5 and will have Visual Studio support.
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:
http://www.microsoft.com/products/expression/en/interactive_designer/id_free_trial.aspx
Graphic Designer:
http://www.microsoft.com/products/expression/en/graphic_designer/gd_free_trial.aspx
Web Designer:
http://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
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]
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.
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 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.
Remove this comment
Remove this thread
close