Extending WPI to deliver anything but web sites using packages compatible with MSDeploy is not easy, relies on MSI and doesn't support updating anything, as it's only a bootstrapper.
I personally won't be going down that route, for this and the other reasons I mentioned before. That said, patches are as always accept. On Jun 27, 12:56 pm, John Simons <[email protected]> wrote: > Seb, > > My understanding about WPI is that it is not just used for websites, you can > use it to package frameworks and other libraries. It currently has things > like PHP, ASP.NET MVC2, ... > The actual packages (I believe) can be hosted on the package author own site. > The value I see from using such a tool is that you don't need to do any > selling to others to adopt it, that work is already done for you by MS + no > doco need to be written. > The other thing is that it actually works quite well and there is already a > large audience using it. > > Anyway, just my 2 cents :) > > Cheers > John > > ________________________________ > From: SerialSeb <[email protected]> > To: Castle Project Development List <[email protected]> > Sent: Sun, 27 June, 2010 8:59:00 PM > Subject: Re: OpenWrap dev Mailing List is open > > The WPI is just a way to deploy msdeploy packages on a local box. > Seeing as that UI doesn't cover remote deployment, and seeing as those > packages are very much tightly coupled to the destination environment > (in terms of what gets deployed, it's a snapshot of a typical asp.net > site), there is no real value in exporting a package as a module for > WPI. > > My current thinking goes through an intermediate package export for > web content, that can be used as-is on environments that support this > kind of deployment (a la war file), or interop with msdeploy for > deployment on servers that support that, which is useful for those > scenarios where you can't control assembly loading (aka medium trust), > or where you need to rely on legacy .config files in your solution > while being host-independent (like an OpenRasta site is) > > That said, OpenWrap itself could be available in the web platform > installer as an entry point to start using packages. Not sure if > there's that much value in taht. > > On Jun 27, 11:16 am, Jonathon Rossi <[email protected]> wrote: > > > > > IIRC Seb has done some research in this area. I think that once we have > > things more stable and well defined, and probably have chosen a single > > solution, it is definitely something that is worthwhile investigating > > further. > > > On Sun, Jun 27, 2010 at 7:07 PM, John Simons > > <[email protected]>wrote: > > > > Seb and Jono, > > > > Do you guys have any plans to also integrate with Web Platform Installer > > > 2.0? > > > I'm asking because it is actually a really nice way of making OSS projects > > > more visible to all kinds of users and it makes installing stuff a piece > > > of > > > cake :) > > > > Looking forward to hear about this > > > > Cheers > > > John > > > > ------------------------------ > > > *From:* SerialSeb <[email protected]> > > > *To:* Castle Project Development List < > > > [email protected]> > > > *Sent:* Sun, 27 June, 2010 6:42:04 PM > > > *Subject:* Re: OpenWrap dev Mailing List is open > > > > The main issue with package management is the amount of "breakage" you > > > get from using it, which stops user in their tracks immediately. As > > > Horn is trying to assemble binaries from a bunch of trunk versions of > > > code, it's no surprise that a lot of the time these things break, > > > taking a *long* time to update your stack. > > > > I see Horn as a package builder, not a package management system. > > > There's still hope that Horn could be the unified way for building > > > software, I don't know. What I know is that I won't be covering the > > > build part of things (aka not provide any automated or convention- > > > based way), and let people writing the code decide how they want the > > > package. > > > > The mailing list is athttp://groups.google.com/group/openwrap-devel > > > > As for the differences with Bricks, we chatted about it with Jono at > > > the time he announced Bricks, and we do very similar things, but it's > > > my understanding that OpenWrap had a wider scope. We discussed about > > > combining efforts from existing codebases, I wanted to wait until we > > > got both systems at their first release before deciding on anything, > > > as I didn't (and still haven't) have the time to both develop the > > > concepts and coordinate a merge. Not sure what the state of Bricks is. > > > > What I can tell you is what OpenWrap does: > > > 1. Everything works through commands, with those commands running from > > > the command line in a noun / verb fashion (a copycat of powershell > > > commands), but should also easily be usable in an upcoming VS plugin, > > > all in XCopy environment. Commands from your project are also > > > included, so you can deploy all your commands as part of packages with > > > your solution. > > > 2. Dependencies are resolved from a dependency descriptor, and the > > > correct references are added transparently, so both MSBuild and VS are > > > none the wiser of the treachery and happily compile > > > 3. Dependency resolving follows platform compatibility rules, so a > > > package can contain binaries targetting .net2, .net3, .net3.5, and > > > MSIL, x86, x64. Platform graphs will let the system be easily able to > > > change the probing mechanism to quickly add new profiles (such as > > > silverlight, mono etc). The binaries are selected at the time of the > > > assembly resolve, so at build time it'll select the correct ddls, and > > > provided you use openwrap for assembly resolving at runtime it'll be > > > supported to. > > > 4. Packages are not only dll's, they are whatever is needed to be > > > packaged. Each area of a package is called an export, processed by an > > > export manager, which itself will be part of a package. > > > 5. StructureMap and OpenRasta are going to be packaged in OpenWrap by > > > their respective authors, so there's some pledged adoption planned in > > > the next iterations of those products, and iMeta is providing us with > > > the hosting space for the first official openwrap package repository. > > > Doesn't mean it's good, just means people have a desire to see stuff > > > happen. > > > > That's just a quick overview of why I think OpenWrap has a good > > > chance of getting somewhere. Any feedback more than welcome, but if > > > it's just about OpenWrap i'd invite people to follow the conversation > > > on openwrap-develhttp://groups.google.com/group/openwrap-devel. > > > > Seb > > > > On Jun 26, 8:49 am, Krzysztof Koźmic <[email protected]> > > > wrote: > > > > Thanks for the info Seb, > > > > > Could you (and Jono perhaps could give us his POV) elaborate on OpenWrap > > > > and Jono's Bricks project, and how they're different? > > > > > Krzysztof. > > > > > PS > > > > > I'm keeping my fingers crossed this (Bricks and OW) will work this time > > > > and not end up like Horn, or one of dozens of similar projects. > > > > > On 26/06/2010 5:42 PM, SerialSeb wrote: > > > > > > Hi guys, > > > > > > as we get quite close to a first release, i've open a development > > > > > mailing list for OpenWrap. > > > > > > I'll have forksof projects on github for the changes that are required > > > > > for each of the castle components to be pushed on the package server. > > > > > If you want to discuss those changes, let me know. > > > > > > For those not aware of it, OpenWrap is a package management and > > > > > distribution system for .net that's been in the work for a while, and > > > > > is what OpenRasta and StructureMap are standardizing on in the next > > > > > couple of weeks. > > > > > > Seb > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Castle Project Development List" group. > > > To post to this group, send email to [email protected] > > > . > > > To unsubscribe from this group, send email to castle-project-devel+ > > > [email protected]. > > > For more options, visit this group at > > >http://groups.google.com/group/castle-project-devel?hl=en. > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Castle Project Development List" group. > > > To post to this group, send email to [email protected] > > > . > > > To unsubscribe from this group, send email to > > > [email protected]<castle-project-devel%[email protected]> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/castle-project-devel?hl=en. > > > -- > > Jono > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
