Comments

These look great, good work!

 

Couple of points:

 

- I think it is just the right move to merge Office Live Workspace and Skydrive, never made much sense to have to different places. At the same time, I fear that some cool features of OLW will be lost in the transition, at least they aren't present in the current preview bits. Namley, a) versioning and b) pdf preview. On a), OLW always kept different versions saved, so you could go back to old versions of a document. That was quite handy, so I hope something similiar will be added to Skydrive at some point. On b), OLW had a web preview of pdf files in the Workspace. The quality was actually quite poor, but this was still a VERY usefull feature, because one could essentially surf around and have a quick look at all files in the workspace.

 

- Rich client access. Right now this works via some WebDAV like thing. Little side tip for those in the CTP: click the link in the web app to open one of the files in the desktop version, then pick "save as" and copy the URL from there. Just use the part that refers to the folder path. Then you can add a new network location (in explorer at the computer level, parallel to your drives) to this URL. And bang, you have explorer access to your Skydrive folder. You can drag and drop files to Skydrive now REALLY easily and quickly. The real question is whether this is going to be the main access route for rich clients, or whether we will see some sync solution, hopefully based on Mesh technology to Skydrive. If that is the case, I'm wondering whether this will be "super smart": lets say I have a Skydrive folder synched to my local disc. I then open the file from local disc with Word. Will Word then recognise that this is a Skydrive/Mesh folder, and if I'm online will go into multiple author mode so that multiple authors can simultanisouly work on the document?

This all sounds excellently. Here is where I hope this is going: Please offer hosted TFS. It seems that you are doing a lot of the groundwork for enabling this. Ideally this would be done under the same group that does offer this for Sharepoint and Exchange already, given that you would have the Sharepoint part covered already then, plus all the identity stuff would also already be covered.

I love TFS, but really I don't want to bother with the admin of it at all, and so a hosted version would be fantastic, in particular also for smaller shops for either TFS 2008 or the new stuff is simply too much overhead.

Dan wrote:



DCMonkey wrote: Um, it's playing a "This Week" video.

My error, the streaming and large download links were pointing to the wrong video...copy/paste bug in-between two browser tabs when posting, sorry!

So, are you going to fix the link? The download link is still wrong.

Cheers,
David

Pablo [MSFT] wrote:



5. While you can re-factor the model (and we'll propagate the changes to your object model in CLR classes), we won't automatically propagate the changes through the mapping, at least not this time...

Not propagating a rename into the DB (that is what you mean by "through the mapping", right?) seems perfectly fine! Database refactorings are a complicated class of things by themself, as you have to take care of the change scripts that need to deployed etc.

What would be nice is if a rename of a database object in the new VS Team Database role would propagate into the mapping file Just into it, not through it, actually.

Also, when you say that renames will propagate into the CLR objects. Does that mean you will use the rename refactoring code that is in VS to do that? That would be incredibly cool! If  I change the name of a property in my entity, and all C# code that references that property in code (i.e. not the class that represents the entity, but the code that uses that class) would update automatically.

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

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.

Am I mistaken that XBAP apps will not be indexable by search engines? Essentially you will hide any content from search when you use this technology, right?

Loose XAML would probably a way to make it indexable, right?

Best,
David

staceyw wrote:



But that is all databinding does.  It takes that strongly typed List and put the elements in the proper textbox (in simple terms).  So iterating over the list manually would not really show much more IMO. 

But unless you have used databinding and are familiar with it, you can't possibly know that. All I saw in these demo was that some object was given back from the query and then shown in the UI. I know that the object is a strongly typed list, but if you are not familiar with databinding, it might as well have been some weakly typed dataset sort of thing. Pablo just dropped some preconfigured thing onto the form, how is the innocent viewer supposed to know what it is? I just believe it is better to be minimalistic with these things. The great demos by Don Box and alike try to avoid these "and now I combine this with this other [insert some complex technology that not everyone is familiar with]" moments.

Let me also add: Don't worry about the accent! Or that you are excited about the stuff. That is Channel9, right? Professional videos can appear somewhere else!

Another thing I really didn't like about the video was that data binding in WinForms was used. We never really saw what came back from these queries! We saw the queries, and we saw that the result of the queries (whatever it was) was assigned to the datasource. And some sentence along "now databinding does all the magic". That was just terrible and added to the "wow, we show you lots of magic". It would have been much better to go with a command line app, and then just loop through the results, and show how you get back strongly typed objects. And type that during the interview! It is great that you prepare some super magic code that shows stuff, but the viewer of the show will have no chance to really understand what you are doing with that sort of thing.

Still way cool technology!

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.