TechnicalArchitectureWorx

The (Unofficial) ITWorx Technical Architecture Blog

Archive for January, 2007

Running Ant scripts from Eclipse

Posted by archworx on January 28, 2007

Getting Ant scripts to run from eclipse can sometimes be tricky if you are using Ant tasks that require external jar files, for example to run a script to deploy/undeploy to a tomcat server you have to add the make the following configuration changes, the same applies to junit and other external tasks

  • In Eclipse go to Window | Preferences | Ant
  • Open the Runtime section
  • In the Classpath tab: Add to the Global Entries the the catalina-ant.jar file as indicated by the following screen shot.

Eclipse-Ant jar file

  • In the Tasks tab: Add the Deploy and Undeploy tasks as shown in the following screen shot

Eclipse-Ant deploy

Eclipse-Ant Undeploy

Advertisements

Posted in Java, Nader | 13 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 »

Insights on JDC 2007

Posted by archworx on January 22, 2007

Last Saturday I attended the first Java Developers Conference (JDC) to be held in Egypt. The event was organized by the Egyptian Java Users Group (EGJUG) and was held at Intercontinental City Stars Cairo. Consisting of 7 sessions, the conference covered topics ranging from SOA and Webservices to IDEs and productivity. I thought the conference was successful overall, it was well organized (albeit a bit late on the agenda), had good food 🙂 and hosted knowledgable speakers. The sessions I liked most were the ones about “Bullet Proofing your Webservices” and  “New Features in Java 6” which were lectured by Chuk Mun Lee (Sun Singapore Senior Developer Consultant). The first talked about best practices in the use of webservices in Java and how the ease of creation of webservices has evolved in J2EE 5 and JavaSE 6. The second talked about new syntactic features and APIs shipped with JavaSE 6, the most important introduction (in my opinion) being the introduction of Webservices in Java SE for the first time. I also liked the Netbeans session given by Roman Strobl (Netbeans Technical Evangelist), although I must say that the new databinding features that will be shipped with Netbeans 6 were present in .NET 2.0 for ages now, overall I think Netbeans has an edge on other Java IDEs by being the best (again in my opinion) in providing Visual Editors for Java Developers. Anyways, that was it. Microsoft’s Middle East Developers Conference (MDC) is coming to Egypt this Feburary, we’ll just have to see what Microsoft can come up with to counter Java’s new features 🙂

Posted in AFathalla, Java | 3 Comments »

Continuous Integration: Differencing .NET Assemblies – MVID regenerates for every compilation

Posted by archworx on January 22, 2007

Background: This post is about challenges in differencing binaries to identify if they are identical between assemblies on the testing environment and assemblies generated from code on SourceSafe. Read on for more details.

The Problem: At the end of your development efforts, you typically need to subject your code base to testing, and then upon testing approval, you ship your code to the client. However, bear in mind the following:

  1. Your Code Base is on a Source Control engine
  2. Your binaries are not – they are on the development and testing servers. It doesn’t make sense from a configuration management perspective to store binaries on source control (because:
    1. You can always generate them (theoretically) exactly from the source.
    2. It is a huge burden to ensure object/source consistency
    3. Even if you do keep them, you’ll have to check that the source & object are indeed consistent, which is an extra overhead)
  3. You typically need to ship to your client the binaries that are on your testing server – as those are the ones that have been approved by the testers.
  4. You can’t ship the source unless you are sure it generates the binaries the developers claim they have produced on the testing environment.
  5. So the obvious process is to retrieve your source code from your Source repository and recompile it.

Enter .NET Assemblies – which include the following obstacles to successfully being able to recompile the exact binary stream of code twice:

  1. By default .NET assemblies change their version # every time you compile – this is a good thing, as it provides for very good tracking of version numbers; something that is sadly lacking in many developer’s culture. However, this means that binary differencing will yield false positives.
  2. If you need your assembly to be hosted on the GAC, or otherwise want to sign your assembly, your assembly must be strongly named, this can pose challenges if you sign them with keys that are not controlled properly.
  3. The assembly header also contains a field called the “MVID” – which is the Module Version Identifier. This field’s purpose is solely to be unique for each time the module is compiled. This is a rather powerful concept, in the sense that this is the first time I’ve personally seen the concept of someone wanting to distinguish a compilation instance from another one, irrespective of the code being compiled itself.

The Solution: This article is about attempts to solve the three aspects of the problem described above. At this time, we have a simple solution and a workaround for the first two – about the version and the signatures, and we have hopeful indicators that the MVID issue too can be resolved.

Resolutions:

  1. Version Numbers – can be explicitly defined through the removal of the “*” sign for release builds. You can find this field in the assembly info.
  2. Strongly Named – let’s ignore thise case temporarilly.
  3. MVID – we believe this can be controlled via a compiler option – but I am yet to find it.

The rest of this post is mostly dedicated to discussing the MVID issue.

Tools:
Intermediate Language Disassembly:
ildasm /text /all file.dll

Impact:
The MVID is used by the .NET CLR to determine whether or not to reload the precompiled assembly data.
This is to allow caching such precompiled data, and consequently ensuring cache integrity.
This would imply that the MVID is only useful when precompiled information exists in the assembly.
Typically precompilation only happens when you use NGEN.EXE.
Consequently not generating an MVID or generating it with the same ID is not necessarily a dangerous idea to contemplate.

Note:
Emperical Observation has shown that Nant manages to automagically generate the same MVID each time it recompiles, thus dispelling the myth that it must be unique for every ”compilation”. There must be a way to mimic Nant’s communication with the C# Compiler, as it must be using it to do the compilation. There is no way that Nant is faking a compilation. Or is there? 😉

Epilogue:
The observations proposed herein are very encouraging, even in so far as they encourage extreme ideas, such as:
1. manually coercing the same uid value for the mvid for otherwise identical compilations (via injecting it into the binary for example); because this would theoretically not jeopardize the sanity of the ngen-generated data.
2. We could do a manual textual comparison of the assembly’s code via ildasm /text and a script that conceals the mvid information

More on this later.

Posted in Configuration Management, Continuous Integration, mkaram, Source Control Tools | 13 Comments »