organize source code with code on different platforms

Question

if i have csharp code solutions in multiple platforms (winforms, asp.net mvc, asp.net, wpf, etc) but i also have lots of shared code used in more than one of the above platform, what is an ideal way to organize your code in source control.

right now i have:

Root
-- Winforms
-- WPF
-- Silverlight
-- Asp.netmvc
-- Shared
---- Shared1
---- Shared2

where "Shared1" and "Shared2" are examples of projects that have code used in multiple platforms. whenever code is in one of the other directories and is needed, it gets promoted to teh shared directory.

any other way of doing this better ?

Answer 1

With the exception of Silverlight, those are all essentially the same platform (.NET), so you should just be able to bring the assembly/assemblies over the projects and all is good. You could use an extern or similar, but it'll work any which way.

Silverlight is a little different, as you might need (or just choose) a different build for that - but if they are all tightly related (to the same project / product etc) you should be able to keep them pertty close without difficulties.

Answer 2

Why do you want to encode the target platform in the directory structure? Especially as Marc has pointed out, that there is no fundamental differences between these platforms. That way IMO you are just making your own life more difficult as you need to move source code around when it gets reused.

Do you need to deal with projects targeted to specific platforms separately in your process? E.g. do you need to build / release all projects for a specific platform - but only those - at once? Such a need might justify organizing your code like this.

But even then, I would prefer keeping all info about target platform(s) out of directory names and inside the project files, and use tags or separate reference files to mark which project targets which platform.

Edited to clarify with an example: I would have the directory structure

Root
-- Project1
-- Project2
-- ...

And in each project directory I could keep a file named e.g. platforms.txt which contained the list of target platform(s) for that project:

Root
-- Project1
    platforms.txt
-- Project2
    platforms.txt
-- ...

Then if I needed to e.g. build all projects for asp.net, I would traverse the project hierarchy and build all projects whose platforms.txt contains "asp.net". The traversal can trivially be solved with a *nix shell script (using Cygwin on Windows), but I guess it would not be impossible with a Windows batch script either (or Perl, Python, ...).

Alternatively one could maintain a bunch of platform specific files in e.g. the Root directory, so instead of traversing the directory tree for asp.net projects, I could simply process all the projects listed in the file Root/asp.net.projects.

Root
-- asp.net.projects
-- winforms.projects
-- ...
-- Project1
-- Project2
-- ...

I would prefer the former solution, because that way each project's target platforms are maintained inside the project directory, so maintenance is easier and chance of errors / forgotten updates are smaller. Also, this way the target platform info can be freely used in the build process of the project itself. However, if the traversal looks cumbersome or you are not familiar with these sort of scripts, the latter solution may be more viable.

Answer 3

IMHO it is much better to organize your SCC tree by using names of your projects or products, not by technologies. So you don't run into problems when technologies evolve, change names, or you need 2 different technologies in one project.

Answer 4

The general consensus is that you should organize your source control using "deliverables" or "projects." To clarify, a deliverable is something you build and deliver to your client or customer. So this could be one Visual Studio project, or it could be many projects in a solution. For instance, if you provide a suite of web apps as a product, you should have a folder called "Web Suite" or whatever the product name is, and put all those web projects inside that folder.

But as far as putting your "platform" names as folders in the folder structure, I don't think it really matters. You could keep those folder names out of source control, and organize your own checked out copies of the projects into folders named with "platforms" if it helps you personally to organize it that way.

The shared code is a different story. With shared code, you may need it to be present in more than one deliverable, but you probably will want changes to make their way to all the projects that need the source for those shared projects. What you DON'T want is 27 copies of the same objects, but slightly different in each project directory. The way to do this depends on which source control provider you are using, but the general idea is you use shared folders (SourceGear Vault), or svn:externals (Subversion) to achieve this. There are several questions on StackOverflow and several sites with explanations of about how to organize your source control repository if you have shared projects.