coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

Yes, XP and 2003 are in scope—with the caveat that there may be slight differences on these platforms due to their lack of NTFS symlink support; but, those changes are limited to XP & 2003—we will not build a flawed design for Vista and beyond.

MSI offers *a lot* of really useful features that would excessively difficult to replicate without using Windows installer. True—XP & 2003 have no other method for installing WinSXS assemblies, but in reality, MSI is for a few dozen other reasons, still the best idea.

Hmmm.. no matter how I say it, it seems I always end up implying the opposite.

Installing applications is still a primary target for CoApp; the real magic of dependency management was to satisfy shared component dependencies… applications are trivial after that, and of course will be supported.

G

From: Conan Kudo (ニール・ゴンパ) [mailto:ngompa13@xxxxxxxxx]
Sent: Thursday, July 29, 2010 1:21 PM
To: Garrett Serack
Subject: Re: [Coapp-developers] CoApp FAQ: A few important distinctions.

So... we are going to support Windows XP and Server 2003? Not surprised about Server 2003, but Windows XP was news to me...

This also explains why we're using MSI instead of something less painful... Thanks. We can now blame Windows XP for that. :P

However, does this mean that CoApp can still be used for installing applications?
On Thu, Jul 29, 2010 at 2:58 PM, Garrett Serack <garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>> wrote:
(cross-posted to my blog)

It’s been suggested a few times over the last several weeks that CoApp won’t provide any value for the .NET community. With the emergence of several alternative projects to provide a form of package management (NPack, OpenWrap, nu-net, and others), I figured I’d better make some time to explain how CoApp and .NET get along.

Q: Isn’t CoApp about packaging applications?
A: Well, oddly enough, the original vision for CoApp was less concerned about actually installing applications, but rather installing shared components.  The ability to install an application comes by virtue that applications tend to be collections of components (shared or private), and a decent package management system should cover these goals easily.

Q: If CoApp is such a great idea for .NET why is all the work focused on native applications ?
A: The reasons that our initial work that we’re doing is focused around native shared libraries and applications, is that they require quite a bit more adaptation to correctly work using modern C compilers and Side-by-Side technology. Once we’ve got the tools to build properly behaving projects to produce binaries that are useful in this fashion, we’ll be in a good place to actually produce packages themselves.
.NET Assemblies, by their very nature are already beautifully designed to be adapted into CoApp packages.  Strong-named assemblies install into the GAC—which is really just the .NET implementation of the Windows Side-by-Side technology--by design. CoApp .NET packages simply install the assemblies into the GAC, where all applications can share them in the way that was intended.

Q: What if I don’t want stuff to be in the GAC?
A: I’d ask you to reconsider.  I can appreciate the desire to maintain control over every aspect of building and distributing your application.  On the other hand libraries that designed to be shared shouldn’t require the consumer of the library to do anything, except for consume them.  The publisher of the shared library shoulders the responsibility of maintaining the library and publishing security updates as well new versions.  As with native Side-by-Side assemblies, the publisher can indicate what version of a library should be used when a particular version is requested.

Q: What possible reason should I choose using CoApp over another .NET package management ?
A: Well, like I’ve said, a plethora of implementations is always a good thing. From what I can see, most of the other package management systems are focused on assisting developers in getting simplified access to shared .NET components.  CoApp takes a larger scope, hoping to serve developers, end-users, and IT administrators alike.  Our design includes the ability to update any components without the necessity of shutting down or rebooting processes (or even god-forbid, the system itself).  CoApp is designed to apply to software regardless of the language it’s written in, from native (C,C++,etc) to managed code (.NET; C#, VB.NET<http://VB.NET>, etc) ,to dynamic languages (Perl, Python, etc) and web apps (ASP.NET<http://ASP.NET>, PHP, and more).

Q: Why have you chosen MSI files rather than something simpler and more convenient (like Zip+Manifest)?
A: Oh, trust me, I really wanted to.  I realize that Windows Installer is kindof a bloated beast that has a lot of downsides; we’ve has chosen MSI as the packaging format because it is handles so many other situations very well--one noteable point, is that on XP & Windows 2003, the only way to install a native Side-by-Side components is by using MSIs. We’ve taken steps to lessen the burden by deliberately limiting the scope of what we are using in MSI to not encumber packages in a painful mess.
As well, by using MSIs we gain the ability to leverage things like group policies, Windows Logo certification, transactional installations, and trivial adoption by other non-CoApp consumers—there is nothing that would stop someone from using CoApp packages for some of their dependencies, and without having do anything other than install the MSIs.


[Description: Description: fearthecowboy]<http://fearthecowboy.com/>

Garrett Serack | Microsoft's Open Source Software Developer | Microsoft Corporation
Office:(425)706-7939                                       email/messenger: garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>
blog: http://fearthecowboy.com<http://fearthecowboy.com/>                                      twitter: @fearthecowboy<http://twitter.com/fearthecowboy>

I don't make the software you use; I just make it better on Windows.







_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx<mailto:coapp-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp