Point taken although the binary & samples download is only 847K.
The reason I decided to move the project was because I’m incredibly busy and didn’t want it to die. Would it help if there were smaller downloadables for each of the contrib components?

Cheers,

Andrew.

I’m probably the only one that thinks adding NHaml to the MVC Contrib project was a bad idea. Personally I highly *dislike* these contrib-style projects because they always tend to become bloated and a PITA to manage. For example tonight I wanted to play with NHaml so I downloaded the nice, clean, simple zip at the top of the page then I realized I should grab that latest source. What *was* a 164 KB download turned into 17.77 MB, 17.75 MB of which I didn’t want nor need. Plus I now have this “MvcContrib” namespace floating around inside my project which again I didn’t want and I’ll spend the next 10 minutes removing and renaming everything back to how it was before NHaml got sucked into the MvcContrib blackhole.

I’m not trying to take anything away from the excellent people behind all the projects inside MvcContrib nor the people that I’m sure only have the best of intentions with the Contrib idea but I’ve seen too many of these things turn into bloated monsters involving massive downloads and weird interlocking relationships between assemblies as people in the contrib project start getting incestuous and suddenly attempting to use just one sliver of functionality like NHaml you have to include 8 other libraries from the project, thus destroying the clean, small and agile nature that the projects were going for in the first place.

Again, nothing against any of the people in the project, I just can’t see a benefit to MvcContrib and I only see the downside.

That's right. If you prefer not to use the default ASPX view engine that comes with the ASP.NET MVC…