Different solutions/project files for Local vs Build environments

Question

As part of improvements to our build process, we are currently debating whether we should have separate project/solution files on our CI production environment from our local development environments.

The reason this has come about is because of reference problems we experienced in our previous project. On a frequent basis people would mistakenly add a reference to an assembly in the wrong location, which would mean it would work okay on their local environment, but might break on someone else's or on the build machine.

Also, the reference paths are in the csproj.user files which means these must be committed to source control, so everyone has to share these same settings.

So we are thinking about having separate projects and solutions on our CI server, so that when we do a build it uses these projects rather than local development ones.

It has obvious drawbacks such as an overhead to maintaining these separate files and the associated process that would need to be defined and followed, but it has benefits in that we would be in more control over EXACTLY what happens in the production environment.

What I haven't been able to find is anything on this subject - can't believe we are the only people to think about this - so all thoughts are welcome.

Thanks!

Answer 1

Usually, you would be creating Build projects/scripts in some form or another for your Production, and so putting together another Solution file doesn't come in the picture.

It would be easier to train everyone to use project references, and create a directory under the project file structure for external assembly references. This way everyone follows the same environment.

Answer 2

I would strongly recommend against this.

1. Reference paths aren't only stored in the .user file. A hint path is stored in the project file itself. You should never have to check a .user file into source control.

2. Let there be one set of (okay, possibly versioned) solution/project files which all developers use, and the Release configurations of which are what you're ultimately building in production. Having separate project files is going to cause confusion down the road, when some project setting is tweaked, not carried across, and slipped into production.

You might also check this out:

http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx http://bytes.com/forum/thread268546.html

Just my .02.

Answer 3

We have changed our project structure (making use of SVN Externals) where each project is now completely self-contained. That is, any references never go outwith the project directory (for example, if Project A references ASM X, then ASM X exists within a subfolder of ProjectA)

I suspect that this should go some way towards helping solve some of our problems, but I can still see some advantages of having more control over the build projects.

Answer 4

In our largest project (a system comprising of many applications) we have the following structure

/3rdPartyAssemblies
/App1
/App2
/App3
/.....

All external assemblies are added to 3rdPartyAssemblies/Vendor/Version/...

We have a CoreBuild.sln file which acts as an MSBuild script for all of the assemblies that are shared to ensure building in dependancy order (ie, make sure App1.Interfaces is built before App2 as App2 has a reference to App1.Interfaces).

All inter-application references target the /bin folder (we don't use bin/debug and bin/release, just bin, this way the references remain the same and we just change the release configuration depending on the build target).

Cruise Control builds the core solution for any dependencies before building any other app, and because the 3rdPartAssemblies folder is present on the server we ensure developer machines and build server have the same development layout.

Answer 5

@David - believe it or not this is what we actually have just now, and yet it's still causing us problems!

We're making some changes though, which are forced upon us due to moving to TeamCity and multiple build agents - so we can't have references to directories outwith the current project, as I've mentioned in my previous answer.

Look at the Externals section of this link to see what I mean - http://www.dummzeuch.de/delphi/subversion/english.html

Answer 6

I know it's anachronistic. But the single best way I've found to handle the references issue is to have a folder mapped to a drive letter such as R: and then all projects build into or copy output into that folder also. Then all references are R:\SomeFile.dll etc. This gets you around the problem that sometimes references are added by absolute path and sometimes they are added relatively. (there's something to do with "HintPath" which I can't really remember)

The nice thing then, is that you can still use the same solution files on your build server. Which to be honest is an absolute must as you lose the certainty that what is being built on the dev machine is the same as on the build server otherwise.