• 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!

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.

Previously on "asp.net, modification history, best practices ..."

Collapse

  • Joe Black
    replied
    "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.

    Leave a comment:


  • Jakes Daddy
    replied
    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.

Working...
X