Re: [Coapp-developers] Another kind of package

Yeah, there is some things that need to be careful, and in reality, *Most* of the time, we want to shut down the first app, but there are a handful of situations where this is really handy, and perhaps we'll make that the default, and provide some mechanism for exploiting the nearly-instantaneou

Re: [Coapp-developers] Another kind of package

Sorry, I was too quick to reply. I understand you can run both side by side, which is cool. Just wanted to add some tiny print that said "reparse aware" next to your use of "application". Swapping of links creates a disaster for normal applications that load bits from their directory at runtime.

Re: [Coapp-developers] Another kind of package

Hmm, do you have a scenario that benefits from this? I'd still have to kill the old application to launch the updated one... /rafael On 4/7/2010 2:36 PM, Garrett Serack wrote: > So it turns out that option #1 has another benefit. > > ** You can delete and recreate the symlink without having to s

Re: [Coapp-developers] Another kind of package

So it turns out that option #1 has another benefit. ** You can delete and recreate the symlink without having to stop the application running from that symlink'd folder. ** This will let you install side-by-side a new version of the application, remove the old symlink, and create a new one, wit

Re: [Coapp-developers] Another kind of package

Yep yep. Option 1 has definitely grown on me now, sorry Elizabeth. :) /rafael On 4/7/2010 12:21 PM, Garrett Serack wrote: > Arg! > > We're absolutely trying to avoid relying on LUAFS (the component that > silently virtualizes writes out of [\Program Files]). The purpose of that is > for backwa

Re: [Coapp-developers] Another kind of package

Well, I wouldn't worry about inheriting limitations. I'm well aware of several limitations in XP and 2k3 that would otherwise cause issues, but I'm confident at this point and time that we can design *for* Windows 7 & Server 2k8 and still provide an acceptable down-level experience. If there is

Re: [Coapp-developers] Another kind of package

I understand legacy OSes are still in play, our product is actually still hosted on Windows Server 2003, for various bureaucratic reasons. But from my experience, these legacy servers/desktops are set up in very specific, static configurations that won't be a candidate for CoApp use. I'm just a li

Re: [Coapp-developers] Another kind of package

Yes, my plan is to fall back to junctions on XP/2k3. (I mentioned that somewhere in the wiki too...) No Worries. I'm not discounting XP SP3 & 2k3 at all. They are required platforms in my opinion. From: coapp-developers-bounces+garretts=microsoft@lists.launchpad.net [mailto:coapp-develop

Re: [Coapp-developers] Another kind of package

XP/2003 don't support symbolic links at all. Will junctions (hard links) be good enough? Don't discount XP and 2003 as old operating systems. Coming from the corporate world (EDS and now HP), we have 60%+ desktops still on XP SP2/SP3 and probably 90%+ on Windows 2003. Some servers still on

Re: [Coapp-developers] Another kind of package

Arg! We're absolutely trying to avoid relying on LUAFS (the component that silently virtualizes writes out of [\Program Files]). The purpose of that is for backward app compatibility -future work should definitely avoid the use of that. Anyway I'm pretty sure that Windows Server 2003 R2 is in

[Coapp-developers] CoApp Wiki offline. Static mirror only

We're moving the Wiki's hosting stuff around today. DNS is now pointing to a static mirror. No updates to the wiki until Friday night. thanks [Description: fearthecowboy] Garrett Serack | Microsoft's Open Source Software Developer | Microsoft Corporation Office:(425