Tag Info

Hot answers tagged

7

One product, one source code, different data. There are not really enough details to know whether my answer is the right one, but your problem is a common one for solution providers with multiple customers who have slightly different requirements. The answers always some to converge on: Just One Product. When you build, you build everything and when you ...


6

It depends... its all about dependency management. You're going to have a lot easier time with a single solution. This is so you can simply reference the other projects within a project and it'll all build and will be up to date everytime. This approach doesn't scale though. So the problem is entirely down to those pesky references. The biggest problem I ...


4

I would advise to think carefully about the different phases of release. For example, usually as a release is created it is built, tested, packaged and then deployed. Just because a solution builds together, doesn't mean it needs to be packaged together. And likewise, just because you have a single package, doesn't mean you need to deploy everything in ...


2

Hmm, trying to mandate how to factor a solution into projects is sort of like mandating how to factor a problem domain into objects in OOP. Good developers know how to do it. Bad developers don't. It is a bit of an art, and an acquired skill, yet is subjective enough that I would avoid mandating too much. I may have 6 different developers who are all bright ...


1

Personally I include only the source files WRT source control. Its a rare case when generated files should be added to source control - maybe if they were generated once and never changed, and the generation step is lengthy or complex, otherwise I can't think of a good reason. For compilation - if they need to be added to the project then I tend to add them ...


1

There are two approaches I can see: One may use user controls just like one uses objects to make primitive data types and basic types within the language or framework more explicit or to enclose logic within them. For example, in OOP, when you deal with percentage, one way is to use an int; a usually preferred way is to create Percentage class which will ...


1

Let me offer my take on this question. Although you certainly can simply use your .SLN file as your 'build process', the file itself really doesn't constitute a build process. The Solution file is really just a part of Visual Studio and is used for development. But Visual Studio is only a part of the build and release process. You can't rely on Solutions ...



Only top voted, non community-wiki answers of a minimum length are eligible