As I’ve written previously, we seem to have a real problem with binary explosion and we would do well with some techniques to curtail it (such as a monolithic core design). Today I want to talk about another definitely-not-new practice to stem binary sprawl — consuming source code instead! It may sound trivially obvious but I rarely see it in the .NET world. Here are three ways for you to share functionality via code files instead of binaries.
Code generators
Anyone who has used Visual Studio project templates should be hip to code generators. Think of all the boilerplate code that you get for free in “code-behind” or hidden within partial classes for frameworks like WPF, WinForms, WCF, and so on. What is less common in my experience is for teams to build and use their own code generators. With technologies like Roslyn, it is easier than ever to get started with code manipulation tools.
Linked source files
Even easier than generating code is just including pre-canned code files. In a .csproj file, you can do this by adding a Link metadata item within a Compile item. This is very commonly used for shared AssemblyInfo.cs files, but can work for any bit of code that you want to share across a set of projects in the scope of a solution or repository.
NuGet source packages
Surprisingly I was not even aware that source-only NuGet packages existed until quite recently. A source-only package is a good solution when you need to more broadly publish/consume a dependency and gain all the proper versioning benefits you get with a package manager. Daniel Cazzulino (you may know him as the creator of Moq) has a pretty good tutorial in his blog post “How to create lightweight reusable source code with NuGet.” See also Nik Molnar‘s post “Packaging Source Code With NuGet.”