Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 4 down vote accepted

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.

share|improve this answer
I had completely forgotten about adding files as links! I've used that before, but it's been a long while. Thanks. This is perfect. – gregsdennis Aug 31 '12 at 13:28
You're welcome! – Peter K. Aug 31 '12 at 14:12

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.)

share|improve this answer
+1, nuget changes this problem alot. – Wyatt Barnett Aug 31 '12 at 16:14
Interesting. I haven't used Nuget much, except as a benefactor at work (certainly haven't configured it). I think this is definitely a goal to work toward. Thanks. – gregsdennis Aug 31 '12 at 18:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.