Jason Zander on the WinFX to .NET FX 3.0 rename | Duncan Mackenzie

davida242

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?

davida242

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 Smiley

davida242

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

AlphaKahuna
Customers, THE valuable asset.

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

Chadk
excuse me - do you has a flavor?

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

Ang3lFir3
Codito Ergo Sum

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.

Duncanma
Just Coding for Fun...

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 Smiley

JasonZ

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

davida242

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.