Best approach for utility class library using Visual Studio

Question

I have a collection of classes that I commonly (but not always) use when developing WPF applications. The trouble I have is that if I want to use only a subset of the classes, I have three options:

1. Distribute the entire DLL. While this approach makes code maintenance easier, it does require distributing a large DLL for minimal code functionality.
2. Copy the classes I need to the current application. This approach solves the problem of not distributing unused code, but completely eliminates code maintenance.
3. Maintain each class/feature in a separate project. This solves both problems from above, but then I have dramatically increased the number of files that need to be distributed, and it bloats my VS solution with tiny projects.

Ideally, I'd like a combination of 1 & 3: A single project that contains all of my utility classes but builds to a DLL containing only the classes that are used in the current application.

Are there any other common approaches that I haven't considered? Is there any way to do what I want?

Thank you.

Answer 1

The way I've done this in the past (on other systems) is using a repository. The common files are all in a library part of the repo, but each solution maps them to an individual project.

That way, all solutions all use the same source code, but each solution only uses the files it needs.

This MS blog post tells you how to do it (for VS2005).

Note that if you do this, you need to make sure that all common functionality is completely covered by unit tests. Otherwise, changing the functionality of one of these common files in a way that only one of the including solutions needs could break multiple solutions.

Answer 2

The approach I want to take this now is to use packages (Nuget or openwrap) for my shared/utility code and then pull them in to projects as needed using a private server.

The libraries themselves would then be developed independently of the projects they serve which should get you out of lots of VCS issues. As its your libarary you can break the pieces into as many nuget packages as appropriate / desirable (and this includes the ability to have meta packages that pull in several discrete components).

---

As an aside I'm not sure I'd be overly concerned about code bloat in the general instance - I understand why (historically its has been an issue from time to time) but right now we're at a point where data storage capacity and data transfer speeds are high relative to the size of deployed code. (And to be clear, "not overly concerned" doesn't mean I don't care, just that its probably not a priority.)