CODEWITHSUNDEEP
c#.netvisual-studio-2010tfsversioning
Sunny
Sunny

Reputation: 53

Do we need Assembly version numbers in a asp.net mvc website project?

Situation - We have a .net mvc solution with WCF layer. the solution has about 20 odd projects that get compiled into DLL. the site is running on SQL server 2008. we maintain the SQL scripts in the solution folder as versions. So we have SQL scripts eg. version 1.0.0.0 to lets say latest which is 3.0.0.1.

the solution is source controlled in TFS, we also use TFS to manage the work items, bugs etc etc. SQL script files are also in TFS

Question - the question is that do we need version numbers on the assemblied i.e. dlls aswell. Our DLLS are not exposed in any way or from to the outside world they are just in the runtime of the mvc app. we do not expose the WCF to outside clients,again its just used by the mvc app.

the deploy process is simplly the latest code against the latest db, so when we deploy we check what version the db is in and run a tool to upgrade it to the latest version that is in the db project in the solution.

One of our senior architects is saying that we should maintain the version numbers in the assemblies aswell. I am saying that we dont need any version numbers in the code. beacuse TFS manages that. when we release we just deploy the latest code with the latest assemblies/ deploy package.

I have not come accross the assembly versions unless them assemblies where released to the outside world (if you know what i mean)

please can you suggest... Also note we dont do feature development its just version numbers so that we know what version a particular DB is at.

Upvotes: 2

Views: 1722

Answers (2)

Jesse Webb
Jesse Webb

Reputation: 45253

In a similar project at my job, we use version numbers.

Every commit against the version control system (VCS) causes our CI server (TeamCity) to build a new artifact, with the version set to "LATEST". Every successful build of "LATEST" get deployed automatically to our test environment. We could, in theory, also deploy this "LATEST" version to production, but we don't.

When we want to deploy a new version to production we run a different, manual build job which creates a versioned release (e.g. 1.4.7). The build job also creates an SVN "Tag" of the current codebase. To have our DLLs have the appropriate version, we use TeamCity's AssemblyInfo Patcher feature. This way, we don't have to constantly manually update our projects' AssemblyInfo.cs files. Instead, they get to always have placeholder version info like this...

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]

These number get automatically updated during the build by TeamCity. The versioned artifacts (which include any corresponding SQL scripts) are saved to our "Releases" directory where we keep all our versions of the codebase.

Now this all seems like overkill, right? Not really.

This gives us the following benefits...

  • Our deploy process does a wget to our monitoring page which lists the version number and asserts the versions match up (version expected to have been deployed vs. the version currently running on the server). This gives us confidence that our deploy process worked properly.
  • If bugs are found in the versioned release (the production release candidate), we can SVN checkout the tag, apply a fix, and create a new release without having to worry about other changes on trunk which could compromise the release. It is hard to stay "releasable" all the time, this allows to not have to be. Although, don't get me wrong, it has it's advantages.
  • If problems are found with a versioned release but they can't be resolved quickly, you can always just re-deploy the older artifact which is known to work. Being able to revert a deployed release to an older version has definitely saved us on a couple occasions.
  • If bugs are found on production that need to be investigated, we are free to deploy the same versioned artifact to any of our test environments so that we can try to reproduce the problems outside of our production environment.

There are probably more advantages I am forgetting at the moment but the above list should give a general idea of the power that proper version management can bring to the table.

What I would advise against is continuously, manually updating 20+ projects' version files. This seems like a lot of busy work which is mostly a waste of time because it is prone to human error. Whatever you decide to do, automate it and verify the results.

Upvotes: 1

Alex
Alex

Reputation: 13229

I would prefer the security of knowing and being able to double check versions. If there were a problem with the publishing process, or there were a bug that manifested itself that appeared to be a publishing problem I would want to rule things out as quickly as possible. I also think that it's so easy to implement you've spent more time discussing and thinking about it than you would have actually spent doing it, and there is no down side to it that I can think of.

Upvotes: 1

Related Questions