Introduction

If you want an ASP.NET site to show the deployed SVN revision, the best place to capture that number is during build or deployment, not at runtime. Reading Subversion metadata from the live web server is fragile and often impossible once the site has been published. A generated version file is simpler, safer, and easier to display in the application.

Capture the Revision During Build

The core idea is straightforward:

1. ask SVN for the current revision
2. write that value into a generated file
3. include the file in the deployed site

With command-line SVN, you can get the revision like this:

svn info --show-item revision

If your build agent or developer machine has an SVN working copy, you can use that value to generate a small C# class or configuration file before publishing.

Generate a C# Version Class

One practical pattern is to create a file that exposes the revision as a constant:

1namespace MySite
2{
3    public static class BuildInfo
4    {
5        public const string SvnRevision = "12345";
6    }
7}

Then the site can display it anywhere:

1protected void Page_Load(object sender, EventArgs e)
2{
3    RevisionLabel.Text = BuildInfo.SvnRevision;
4}

The only missing step is generating that file automatically.

Automate Generation in the Build Process

If you have an MSBuild-based project, you can run SVN and write the output before compilation:

<Target Name="GenerateBuildInfo" BeforeTargets="BeforeBuild">
  <Exec Command="svn info --show-item revision &gt; revision.txt" />
</Target>

You would normally follow that with a step that transforms the revision into a .cs file or an app setting. Some teams use a small script for that transformation. Others use a template file and replace a token with the real revision number during build.

For Windows-centric SVN setups, SubWCRev from TortoiseSVN is a popular option because it is designed exactly for token replacement in templates.

Keep Runtime Code Simple

Your application should only read a generated artifact, not shell out to SVN on the server. A very simple runtime approach is to emit a text file during deployment and read it from App_Data:

1using System.IO;
2using System.Web;
3
4public static class RevisionReader
5{
6    public static string GetRevision()
7    {
8        string path = HttpContext.Current.Server.MapPath("~/App_Data/revision.txt");
9        return File.Exists(path) ? File.ReadAllText(path).Trim() : "unknown";
10    }
11}

This is safer because the site no longer depends on an SVN client, a working copy, or repository access once it is deployed.

Why Runtime SVN Access Is a Bad Default

Published ASP.NET sites often do not contain .svn metadata, and production servers should not need direct repository tooling just to show a version string. Runtime SVN queries also make deployment behavior harder to reproduce because the result depends on how the site was copied to the server.

A generated build artifact avoids all of that. The deployment already knows what revision it shipped. Persist that information once and keep the application code passive.

Common Pitfalls

• Trying to query SVN from the live web server instead of generating revision data at build time.
• Assuming published site folders still contain working-copy metadata.
• Writing the revision manually and forgetting to update it on each deployment.
• Coupling display logic to repository tooling instead of to a generated file or class.
• Ignoring the build pipeline, which is the natural place to stamp version information.

Summary

• The cleanest solution is to capture the SVN revision during build or deployment.
• Generate a file or class that ships with the site and display that value at runtime.
• Avoid querying SVN directly from the deployed ASP.NET application.
• 'svn info --show-item revision or tools such as SubWCRev work well in the build pipeline.'
• Treat the revision number as deployment metadata, not as a live repository lookup.