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


6

The makefile for msbuild is the .sln file (or vcproj file). A typical msbuild command line would be something like: msbuild /p:Configuration=Release BigProject.sln The point of using msbuild is so you can script and automate the build process. Whether you were aware of it or not, TeamCity has been using msbuild all along.


4

First point of fact is that the solution file pretty much magically becomes a MSBuild file when MSBuild executes it -- which is what happens when you build the solution in visual studio. In addition, all those project files are just msbuild files managed by visual studio. In fact, the project files handle most of the real dirty work here no matter if you are ...


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

The best approach here is to have the Model of the MVC triad in a separate, common project. This Model should provide all the model features that are needed by the various versions. But the model should not implement the restrictions that differentiate the Simple version from the Advanced version. To take your example, if the Advanced version supports ...


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

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

Re-using the issue tracker should be fine, as long as you're tagging the issues properly so that it's easy to differentiate between projects. Re-using the same repository is more convoluted. The advantage to this approach is removing potentially extravagant merges. On the other hand, it may become more difficult to deploy to test environments unless you can ...



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