I don't think there is anything necessarily wrong with that. Assemblies offer a lot of power and have plenty of benefits, but a few times over the last year or so I've wondered if our assembly usage follows the law of the instrument.
Plenty of other development communities very happily exist in a world without assemblies or binaries. The Ruby gems and npm repositories are absolutely filled to the brim with packages that contain no binary files whatsoever. What do they contain? Source code.
Recently I've been wanting to create a NuGet package that would contain common AutoFixture configuration for intrinsic ASP.NET types that I find myself repeatedly using. Unfortunately, every other user of the package would want to slightly tweak the configuration for their project, so I figured I'd simply ship the package with only the source code (no pre-compiled assembly) so that they could easily do that.
When I told Louis DeJardin about this idea earlier in the year at MonkeySpace, his eyes lit up and he got excited. It turns out he's been thinking about source only packages quite a bit and has even released several OWIN packages as source only.
Louis told me about a few best practices and conventions that he has found useful when creating source only packages. I've noticed that only Damian Hickey has picked up on these, so with Louis' permission, I've decided to publish them here for greater exposure:
NuGet Source-Only Package Conventions and Practices
- Package ID's should end in .Sources, which aligns well with and builds upon the .Sample suffix recommended in the NuGet Package Conventions documentation.
- In the .nupkg itself, source code files should be placed in a directory with the path content/App_Packages/{package-id}.{package-version}. Similar to how the .Sources suffix builds upon the prior art of .Samples, the App_Packages directory follows the App_Start folder nomenclature used by David Ebbo's popular WebActivator package.
QR: