We talked about this at the summit. We definitely need to handle this-I suspect that we will have small set of special cases in the short run (.NET framework, C++ redist libraries).
In the longer run, I'd we had talked about an 'alien-abduction' tool that consumes & repackages existing installers to adapt them to the CoApp model. Still, I can see some cases that don't really fit well into either model (I'm thinking about Sql Server, off the top of my head). Short run: no answer. G From: coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net [mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] On Behalf Of Eric Schultz Sent: Monday, June 28, 2010 11:05 PM To: coapp-developers Subject: [Coapp-developers] Requiring non-CoApp MSI's I haven't seen this come up in the mailing lists or the wiki but I'm wondering what thought has been put into the usage scenario where a package requires software non-CoApp. The main example in my mind would be a package that requires the newest version of the .NET Framework but the user doesn't currently have that. Will CoApp quietly figure out what to do like all other packages or will CoApp notify the user and provide an easy mechanism for getting the required software or is this something outside the purview of CoApp even? Eric
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
