lol -- well, still, you take my meaning :) Other packages that are also unable to make sweeping assumptions about the environment into which they are being added are similarly unable to provide a 'comprehensive, automated, no-user-interaction-required' experience for their NuGet consumers.
Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Mon, Mar 14, 2011 at 1:07 PM, Fabio Maulo <[email protected]> wrote: > Not only that, my friend...... Castle.Core is just another "*Core > Services; not intended to be consumed by itself*" > > > On Mon, Mar 14, 2011 at 2:04 PM, Stephen Bohlen <[email protected]> wrote: > >> ELMAH is a poor example b/c its only got ONE way to configure it, it only >> runs in ASP.NET apps, etc. A more salient example is probably something >> like Castle.Core, StructureMap, etc. that has MANY ways to configure it. >> When you add Castle.Core, do you get a Castle.Config.xml file (probably NOT) >> --? >> >> The challenge is that NuGet (in its present form) isn't nearly mature >> enough to provide the rich interaction that a more complex and configurable >> project like NH would really demand from a package manager in order to fully >> support our 'desired' user experience. >> >> Until that time, I think the NuGet-user-consumes-NH is going to remain >> decidedly sub-optimal. >> >> >> Steve Bohlen >> [email protected] >> http://blog.unhandled-exceptions.com >> http://twitter.com/sbohlen >> >> >> On Mon, Mar 14, 2011 at 12:55 PM, Patrick Earl <[email protected]> wrote: >> >>> Ya, I think you're right that as a core development project, we don't >>> really need to publish packages that are based on preference of >>> operating mode. I do however think that we need to provide packages >>> that actually save time and help the user, rather than just making >>> them do all the hard work themselves. The spirit of this is embodied >>> in the NuGet example video for Elmah. You install the package and it >>> configures your application immediately for use. I would be rather >>> disappointed if there was no help in this area and the nuget packages >>> only served as a fancy zip file with dlls. >>> >>> Patrick Earl >>> >>> On Mon, Mar 14, 2011 at 10:39 AM, Fabio Maulo <[email protected]> >>> wrote: >>> > What I mean with this is that the NH team should avoid to publish >>> packages >>> > where the main matter is: "This is my taste about how work with NH". >>> > As example try to write a post about: How implement session-per-request >>> in >>> > ASP.NET MVC3.(note: I didn't say how manage NH session in general). >>> > Or even a more simple post as: The best way to configure >>> session-factory >>> > with NH3 >>> > On Mon, Mar 14, 2011 at 1:31 PM, Fabio Maulo <[email protected]> >>> wrote: >>> >> >>> >> Guys. >>> >> NuGet is free. >>> >> You can create your : >>> >> >>> FullAspNetMvc3WithRazorAnd_StructureMap_BaseEntity_QueriableRepo_NH3_NHV_NHSP_NHE.nuspec >>> >> in your local machine or in "your own space"in NuGet-gallery >>> >> >>> as: >>> JhonWhite.FullAspNetMvc3WithRazorAnd_StructureMap_BaseEntity_QueriableRepo_NH3LinFu_NHV_NHSR_NHSP_NHE.nuspec >>> >> >>> >> On Mon, Mar 14, 2011 at 1:00 PM, Stephen Bohlen <[email protected]> >>> wrote: >>> >>> >>> >>> Well, it shows that you're continually thinking :) >>> >>> >>> >>> Here's my comments (more or less in order of your ideas)... >>> >>> >>> >>> re: including (consistent) categories (ByteCode, Database, etc.) in >>> the >>> >>> package names: good idea, I like it and it makes a lot of sense to me >>> >>> re: changing config files in addition to just adding assemblies, I >>> fear >>> >>> that this is anything but straightforward given the many, many ways >>> one can >>> >>> now configure NH (app.config/web.config, hibernate.cfg.xml, >>> Loquacious >>> >>> code-config, etc.); I'd hate to have a package manager register the >>> >>> ProxyFactoryFactory in hibernate.cfg.xml when the whole rest of my >>> config >>> >>> was in my web.config or in code -- it would be the *last* place I'd >>> look to >>> >>> see WTF was going on with my app when all hell breaks loose after I >>> add the >>> >>> package <g>; this probably needs so serious consideration re: how it >>> would >>> >>> ever work; not dismissing it, just suggesting its a non-trivial >>> problem to >>> >>> solve >>> >>> re: a dummy package that just contains a 'getting started.txt' file, >>> to >>> >>> me this seems mostly contrary to the concept of NuGet as >>> >>> add-assemblies-to-my-project, but I don't dismiss it out of hand >>> entirely; >>> >>> what do others think about this strategy--? >>> >>> re: 'starter packages' like Nhibernate.Example.AspNet, I like this >>> idea >>> >>> (a LOT) but I'm not certain how simple it is to actually deliver what >>> >>> amounts to an entire new project infrastructure via NuGet; some >>> >>> experimenting with this seems to be warranted to better understand >>> the >>> >>> limitations of this kind of unintended use of NuGet >>> >>> >>> >>> Steve Bohlen >>> >>> [email protected] >>> >>> http://blog.unhandled-exceptions.com >>> >>> http://twitter.com/sbohlen >>> >>> >>> >>> >>> >>> On Mon, Mar 14, 2011 at 11:49 AM, Patrick Earl <[email protected]> >>> wrote: >>> >>>> >>> >>>> Okay, my brain won't shut up. >>> >>>> >>> >>>> I had the thought that packages like NHibernate.Example.AspNet or >>> >>>> NHibernate.Full.AspNet could be offered. These combined packages >>> >>>> could have all appropriate dependencies to get up and running in a >>> >>>> particular scenario. The fact of the matter is that the NHibernate >>> >>>> world is so flexible and wide-reaching, that it's hard to pre-decide >>> >>>> on an exact set of packages the user might need. I would think it >>> >>>> would be more clear in the end to have simple packages and then >>> >>>> combine them either through "example" packages or documentation. >>> >>>> >>> >>>> Patrick Earl >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Fabio Maulo >>> >> >>> > >>> > >>> > >>> > -- >>> > Fabio Maulo >>> > >>> > >>> >> >> > > > -- > Fabio Maulo > >
