"I'm after some ideas / 'industry accepted best practice' for documenting the modification history to an asp.net app I am in the process of moving from classic ASP."
Version control should cover most of that, whether it's SS, Merant or the latest Team .NET thingy (which everyone says is a complete re-write but just looks like SS with a few extras).
As for the rest, inter-operability so to speak, again that should be covered with either labelling or some sort of versioning policy, e.g. comp A v1.1 is compatible only with comp B v1.0-1.5.
- Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
- Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Collapse
You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:
- You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
- You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
- If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.
Logging in...
Previously on "asp.net, modification history, best practices ..."
Collapse
-
I might have half the solution ...
.... its all about inheritance .....
Write my classes such that I have a class that covers the base functionality for all applications - its got the methods and properties common to all apps.
Then write classes specific to each app that extend the base class with methods specific to the app.
If app A needs a change to the class, do it in app A's class that extends the base class, and therefore there is no change to app B in any way.
Likewise, if the base class needs a change, then it affects app A and app B, and the mod history for both apps needs updating.
I think this makes sense .....
Any other comments ???
Leave a comment:
-
asp.net, modification history, best practices ...
Hi,
I'm after some ideas / 'industry accepted best practice' for documenting the modification history to an asp.net app I am in the process of moving from classic ASP.
In the past, with classic ASP, each page of a given application has only 1 source file (the .asp file), so its been easy. I would write each .asp file with its own version number and detailed mod history comments; and then have an include file which all pages included which had the master application version number and the 'higher level' mod history for the app as a whole.
But now its different - everything is split out (for the right reasons I might add). So, each page now has 2 files - the .aspx, and the code behind .aspx.vb
Then we have the web.config file (which I current use to store the application version number)
And then we have the classes - and thats where it gets messy in my mind.
Lets say I have application A. It has:- a web config file
I put the application version number, and general app mod history comments in there
- some web pages, 2 files each (.aspx and .aspx.vb)
I put the page version no and detailed mod history in the .aspx.vb files
- some classes
I put the class version no and detailed mod history in each class .vb file
And now consider that I have application B. It is setup in the same way as app A (web.config, aspx, aspx.vb files, and some classes). But some of the classes it uses are the same as app A (after all, thats what OO is all about)
What happens when I need to make a change to one of the classes that both apps use ? Even if its a change to a method that only app A uses ?
Of course I up the mod history of the class, and presumably the overal version number and mod history in web.config for app A (app A being the application that required the change)
But what about app B ? I've not change it, and it still functions exactly as it did before (big assumption there ), so I should not need to up its mod history or version number. But one of its classes has changed - so there has been a change to document .....
Presumably this dillema affects all OO architectures ??? What do other people do ??Last edited by Jakes Daddy; 3 April 2006, 12:54.Tags: None
- a web config file
- Home
- News & Features
- First Timers
- IR35 / S660 / BN66
- Employee Benefit Trusts
- Agency Workers Regulations
- MSC Legislation
- Limited Companies
- Dividends
- Umbrella Company
- VAT / Flat Rate VAT
- Job News & Guides
- Money News & Guides
- Guide to Contracts
- Successful Contracting
- Contracting Overseas
- Contractor Calculators
- MVL
- Contractor Expenses
Advertisers
Contractor Services
CUK News
- How to answer at interview, ‘What’s your greatest weakness?’ Nov 14 09:59
- Business Asset Disposal Relief changes in April 2025: Q&A Nov 13 09:37
- How debt transfer rules will hit umbrella companies in 2026 Nov 12 09:28
- IT contractor demand floundering despite Autumn Budget 2024 Nov 11 09:30
- An IR35 bill of £19m for National Resources Wales may be just the tip of its iceberg Nov 7 09:20
- Micro-entity accounts: Overview, and how to file with HMRC Nov 6 09:27
- Will HMRC’s 9% interest rate bully you into submission? Nov 5 09:10
- Business Account with ANNA Money Nov 1 15:51
- Autumn Budget 2024: Reeves raids contractor take-home pay Oct 31 14:11
- How Autumn Budget 2024 affects homes, property and mortgages Oct 31 09:23
Leave a comment: