1

We have a C# desktop application which we run for clients on various servers on a software as a service model. We are still on dot net framework 2. The software has a architecture in which we have an independent application to catch external data thrown by some server. Then an application to make calculations based on it. Also one more application on which the client sees the output. The link between the 3 applications is another application which communicates with the DB.

The 4 solutions are on a SVN for sourcecontrol. But the release management is still manual and the patches are made manually by checking the log and including the dlls, pdbs, xml. etc for the projects for which the code has changed.

There is no assembly versioning implemented and the patch or release management is just done in the dark.

I want to know what is the industry practice for generating automatic patches from the code. Also I want a patch for each revision in the SVN. Also is assembly versioning helpful in this?

I have read much about continuous integration but it fails because we do not have unit tests and other fancy code to moniter the correctness of code. The only thing at this time I would be interested is to implement a way to make patches which can be applied and removed easily. Also I want to know a way to determine the way we can monitor which release is at which level(or what patches have been applied) by some automated way rather than maintaining a log manually.

puneet
  • 769
  • 1
  • 9
  • 34

1 Answers1

0

We use a build script which creates a SvnVersion.cs file containing the last commited revision. This file is placed in the root of the solution, and then added to all projects in the solution (but added as a link, not copied).

The template for the file (SvnVersion.Template.cs) looks like this:

using System.Reflection;
[assembly: AssemblyVersion("1.0.0.$WCREV$")]
[assembly: AssemblyFileVersion("1.0.0.$WCREV$")]

And we simply use TortoiseSVN to fill these placeholders in a batch script:

type "%TRUNKPATH%SvnVersion.Template.cs" > "%TRUNKPATH%\SvnVersion.tmp"
SubWcRev "%TRUNKPATH%\" "%TRUNKPATH%SvnVersion.tmp" "%TRUNKPATH%SvnVersion.cs" -f
IF ERRORLEVEL 1 GOTO ERROR
DEL "%TRUNKPATH%SvnVersion.tmp"

If you don't use TortoiseSVN, there are other ways to get this info in the file.

You will also need to remove this same information from your AssemblyInfo.cs files or you'll get a compile error. Also, to speed up Debug builds, this is only executed in Release builds (and in Debug builds only if the file doesn't initially exists, like after a fresh checkout).

vgru
  • 49,838
  • 16
  • 120
  • 201
  • Thanks for the response. I have a few questions and doubts. And then how do you utilize this to create patches for the release? How does assembly versioning help me in picking up the patch out of the whole release and apply it. Also is there a way to get to to know at what revision a certain client release is if we implement the above. – puneet Nov 09 '12 at 07:39
  • @puneet: hi, I missed your comment. Well, we never actually create patches, so I wouldn't know for sure (we always build and release the full installer which uninstalls the previous version). We presumed this would be the safest and simplest way. Regarding client release version, I'm not sure what you're asking? This value is embedded in each assembly ([`AssemblyName.Version` property](http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.version.aspx)) and in the final installer, so we always know which revision in the SVN it corresponds to. – vgru Nov 13 '12 at 16:03
  • You don't have any client specific requirements or changes in each release? Any ways the biggest of my problem is still the patch creation and deployment, since many changes are done according to the client in app config files we avoid sending the entire release. Also some custom colouring and other things are set according to the client and should not change. Also how do you propagate db changes if you have one. Thanks. – puneet Nov 14 '12 at 06:57
  • Well, we do slightly different type of apps, we have few clients, but with larger customizations, so all branches are stored separately anyway and each client gets the full installer on each release. Branding is chosen during builds. I personally haven't had the need to include SQL scripts in my installers, but some older projects we had included all SQL scripts, each tagged with a revision. During setup, installer would execute all scripts in succession between the last installed version and the current one. I guess something like that might work for other files too (updating `app.config`)? – vgru Nov 14 '12 at 09:04