For an ASP.NET WEB FORMS web application, check if the web server has the latest version for any specific aspx/ascx pages on any redundant web server

Question

Our team works in a project where the customer manually deploys (copy/paste) the updated release we provide (ascx, aspx, dll, etc.) for the ASP.NET WEB FORMS web application we are developing.

Sometimes the customer reports problems that should be already fixed, and we do not know if this could be caused sometimes because of a bad deployment (error copying files, etc.).

We do not have any access to production or test servers, so we cannot check for it directly on the customer's REDUNDANT (N) servers; That is why we need an alternative method.

Is there an 'automatic' way to check for it? let me explain what I have been guessing:

• we could use some mechanism that introduces the current version number on every page when publishing it, and then obtain it trough a non-visible mechanism for the end user (e.g. an administration page that shows the version for a page).

• or calculate the crc for every page to check if they are equal and show it in the same administration page...

Any ideas are welcome, although I guess that there should be something to do it more properly, as this should be a common requirement.

Regards!

Answer 1

Well, it actually not that common, since in most cases, one does not have multiple copies of the same web site being deployed.

And furthermore, in most cases, to build and deploy, we don't "hand" copy a few pages, but use the publishing wizard.

And double worse yet? Most don't recommend to use a asp.net web site, but in fact you are STRONG recommended to use a asp.net web "application".

With a web application, then none of the aspx.cs (or aspx.vb) pages are deployed to the server. Hence, the site is pre-compiled before deploying. This of course has a long list of huge benefits, all too long to list out here.

However, the one big downside of using an application is that you can't re-deploy an individual page (along with the code behind), since no code behind pages are deployed to the server. (only the .dll's and the aspx pages are deployed, all source code is stripped out at publish time). This means if you change one line of code behind for a given page, the WHOLE site has to be re-deployed. As noted, while this is less then ideal, the long list of advantages in near all cases outweighs the cost of having to do a full redeploy.

And as such, web applications are FAR better when using source code (GitHub for example). As a result, in most cases, the versions, branching, and changes are managed by source code control (just another huge bonus point in favor of using source code control to maintain "versions" of the site).

So, no, given the above, your setup is not at all common, and is a less then ideal way to approach this issue. Customers thus should be supplied a "web deploy" package, of which web publishing can create for you. This of course will mean that such customers are doing a full re-deploy when you provide them that web deploy package. (it consists of a zipped folder and a batch file they run that un-zips, copies to the web folder, and then it does a web re-start for you).

However, you have what you have now. I would think then just adding a simple hidden field control to each page. Thus, each time you update such pages, the developer could set/add/increment some version number.

Then in your main master page, you could have a menu option that when used would get/grab that hidden field, and display that version number. In other words, assuming all pages have that hidden field (with the same name) then code behind in the master page can get/grab that version number from the hidden field, and that would produce a result for each given page.

I not at all convinced that I would want a per page version number, since then customers over time could become well out of sync of how the current main source application you are using. In other words, while it can be great to deploy one page (.aspx and the corresponding code behind aspx.cs/aspx/vb) page, this means that existing code will be running in some pages that have made assumptions about code and things like session() values being passed from other pages.

Hence, you have loose coupling, but that's too lose in many cases! This thus even further reduces compile time referencing (which of course why I recommend using an "application" - they also have FAR better compile time resolving of dependences and code).

So, I think having a hidden field control in each page would work, since you need the ability to display that information, and you thus could provide a menu option in the master page that can read that hidden value based on the current page the users are viewing.

As a general rule, we don't deploy source code to our sites, and thus the version number is application wide, and not per page. Toss in use of source code control, then even less of the developer community has such issues in regards to a per page version number.