TechnicalArchitectureWorx

The (Unofficial) ITWorx Technical Architecture Blog

Archive for the ‘MZayet’ Category

What are the Best Practices for Versioning?

Posted by archworx on July 5, 2007

Versioning is mainly used to identify multiple revisions of the same unit of information/code. Versioning is the corner stone of Software Development – it is used to differentiate between the different work you do everyday. If you do not version it is almost like you haven’t accomplished anything.

RULE #1
Version number should be stored in object code, for example a .NET assembly.

  • This is so it can be accessed from the code itself. This is important because, for instance you can use it to gauge compatibility with other systems that you need to interact with. For example:

    • If you are using a web service, there should be a way to query the web service’s version number from the web service itself. The Web Service itself may also need to know its client’s version numbers. With this information, you can programmatically control version compatibility, for instance the web service can deny the service to its clients because it knows that it is of an incompatible version.

RULE #2
Version Numbers Must be Unique and non-repeated.

  • No two releases with any differences can hold the same version number. Even if it is just a minor bug fix. Even if it is a spelling mistake.

RULE #3
Version Numbers must be related to the Source Control Label/Tag.

  • This works both ways, for example:
    1. The Source Safe label used in labeling a release should contain the same version number stored in the compiled binary, or part thereof.
    2. The Version Number produced inside the binary must be as closely related as possible to the label/tag name. Ideally part of the version number should be retrieved from the Source Control system. For example, using SourceSafe/KeyWordExpansion

RULE #4
Version numbers must be user accessible.

  • Users of the application must be able to find out which version of the software they are using. Do not hide it from them, and make sure they can access it relatively easily.

RULE #5
Version numbers must be consistent across Configuration Items

  • The version numbers stored inside the product binary must be the same as that reported to the user, as well as being strongly related to the source control label/tag name. The best way to achieve this is via a build control tool such as NAnt and/or Cruise Control for example.

More about Version numbers:

  • Version numbers can look like x.x.x or x.x.x.x depending on mechanism or technology used.

Advertisements

Posted in Configuration Management, MZayet | 10 Comments »

When to use Page.IsValid ?

Posted by archworx on May 15, 2007

In his asp.net blog http://weblogs.asp.net/sibrahim/archive/2003/06/15/8723.aspx, Samer Ibrahim  points out a very important issue regarding Page.IsValid usage in asp.net pages. He quoted the following paragraph from Fritz Onion’s book  ‘Essential asp.net’ :

“As soon as you place a validation control on a page, it is imperative that you check the IsValid flag of the Page class before using any of the data posted by the client.  It is a common misconception that if validation fails on a page, the code for that page will not execute.  On the contrary, the only thing that happens when server-side validation fails is that the IsValid flag of the Page class is set to false, and each validation control that failed renters itself as a visible span so that the error indicator shows up when the page is redisplayed to the user.”

 So if a nice hacker bypasses the javascript validation, the server’s postback code will execute unless you check using safety condition: if(Page.IsValid){//run my code}

Posted in .NET 2.0, MZayet | 3 Comments »

Serializing a string within CDATA element

Posted by archworx on January 22, 2007

What if we want to serialize a field of type string; which has some invalid characters to be used as an XML text, like the “<” sign?! Using these characters as is, will generate an error by the XML parser. In fact, we have two choices to overcome this. One way is to encode our string replacing all invalid characters with escape sequences; and decoding it on deserialization. Our second choice, which we are concerned about in this entry, is to serialize the string field into a string enclosed within XML CDATA section which looks like this:  <script><![CDATA[function matchwo(a,b){}]]></script>

To go the CDATA way, we define the string field of our object as XmlCDataSection:

class  MyObject {

public XmlCDataSection myString;

}

Then we will assign our string to the XmlCDataSection field as follows:  myObject.myString = new XmlDocument.CreateCDataSection(“My string >”);

The literal string “My string >” will now be enclosed in a CDATA section which is ignored by the XML parser

Posted in .NET 2.0, MZayet | Leave a Comment »