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 >
