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 at http://groups.google.com/group/castle-project-devel?hl=en.
