1

I am working in Visual Studio 2012. I have several C projects in a single Solution. Each project currently produces a single production output (dll/exe) and a single test (exe). I manage the multiple outputs through custom configurations and settings including ignoring files per configuration. My motivation for doing so is an attempt to more closely mimic the single project w/ test structure of object oriented languages. My questions is, is this approach better, worse or equivalent to having a project per output? I understand the subjective aspects of the question.

Edit: My research on the subject has been limited to searching the internet for known performance issues and anti-patterns. All of the search results from several permutations of the title above (and others) have been about the number of projects in a solution. I am not specifically concerned about that aspect as splitting my projects into two would still not produce the kinds of numbers being dealt with in the search results. In general, I don't believe performance would be an issue considering the size of the project. I'm mainly interested in whether there are accepted standards or known patterns/anti-patterns that I should be aware of in this approach. Microsoft's documentation here seems to hint at preferring a single project per solution but it isn't explicit. Other MSDN information focuses more on solution management than project management.

|improve this question
  • Hard to tell without knowing the relationship of the "single production outputs" and "single test" outputs to each other. Can you build both in a single build step, or do you need two build steps, where you switch the active configuration in between? – Doc Brown Aug 11 '15 at 17:22
  • @DocBrown The relationship is that the test is dependent on the production output, typically as a library that the test exercises. Currently, I build in two steps where I switch the active configuration. – OttPrime Aug 11 '15 at 17:36
1

YMMV, but in our environment, we prefer any test code automatically to be rebuild after a change to library on which the test code depends was made. Having to switch between configurations first makes it easier to forget the rebuild. And don't you run into trouble when you try to debug through the test applications, and step from the test application's code into the library code, where the libraries configuration is not the active one?

So IMHO using different configurations for compiling different components is probably technically possible, but - at least in our case - it would increase the administrative work to manage them. Different configurations are made for creating different variants of the same component, like a Debug and and Release configuration, or 32 bit and a 64 bit configuration. That's at least the default usage you get from standard Visual Studio project templates. I would not try to shoehorn a different use case into that feature.

|improve this answer
  • Debugging was something I had failed to consider and a very pertinent reason for using separate projects if it is easier to manage in that way. I've spent most of the time porting these projects from existing source that is produced by another IDE, so I was focused on verifying through testing because all of the debugging had been done in the other dev environment. Now that I'll be working in VS, I should have considered the debugging from the outset. – OttPrime Aug 14 '15 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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