TechnicalArchitectureWorx

The (Unofficial) ITWorx Technical Architecture Blog

Archive for the ‘Source Control Tools’ Category

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 »

Subversion on Windows

Posted by archworx on October 9, 2006

Subversion is a version control system that is a compelling replacement for CVS in the open source community. The software is released under an Apache/BSD-style open source license.

Get all the details and features from http://subversion.tigris.org/

For my purposes I need to install subversion on a windows box and have the capability to view the contents of the repository online in a web browser, here are the steps that worked for me:

1. Download the latest version for windows, in my case 1.4 (svn-1.4.0-setup.exe) from the following location http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91 , the download that includes setup in the same includes a friendly Installer.

2. Run the Windows Installer. The defaults are fine

3. If you want a pretty Win32 GUI, TortoiseSVN integrates nicely with the Windows Explorer. Note: TortoiseSVN is a separate project.

4. Using Tortoise, you can easily create your repository and import projects.

Now for the web view part, after trying several project to get this working with IIS, I found the easiest solution is to install Apache and have run on a different port, for my needs, having a different port is not an issue since I will be linking to this repository from an internal website.

To install Apache and the web view component follow the following steps:

1. Download Apache from http://httpd.apache.org/download.cgi  (Use Apache 2.0.55, the newer version 2.2 doesn’t work with the subversion 1.4 modules)

2. Run the Windows Installer. The defaults are fine. When you reach the Server Information dialog, you’ll be prompted to choose between installing on port 80 as a service, or on port 8080 with manual startup. Choose the service option on port 80 (we will change the port in the next step).

3. Since we are working on a Windows server, you probably already have IIS running on port 80. So, we need to pick another for Apache. Open the file C:\Program Files\Apache Group\Apache2\conf\httpd.conf in notepad.exe. Do a find (ctrl+f) for the word “listen” until you fine the line: Listen 80, Change the 80 to 8080 (or whatever port you want).

4. Save http.conf and restart Apache to reflect the changes.

5. Test that Apache is running by going to  http://localhost:8080/ (you should get the default Apache welcome screen).

Now its time to configure Subversion to run with Apache:

1. Copy the following files from Subversion_Home\bin\ to C:\Program Files\Apache Group\Apache2\modules\

libdb42.dll

libeay32.dll

mod_authz_svn.so

mod_dav_svn.so

2. Open C:\Program Files\Apache Group\Apache2\conf\httpd.conf

3. uncomment (by removing the # at the beginning of the line) the following 2 lines:

LoadModule dav_module modules/mod_dav.so

LoadModule dav_fs_module modules/mod_dav_fs.so

4. Add the following 2 lines:

LoadModule dav_svn_module modules/mod_dav_svn.so

LoadModule authz_svn_module modules/mod_authz_svn.so

5. Add the following to the bottom of the file

<Location /svn>
DAV svn
SVNParentPath C:\InetPub\svn
AuthType Basic
AuthName “Subversion repositories”
AuthUserFile C:\InetPub\svn.pass
#AuthzSVNAccessFile svnaccessfile
Require valid-user

</Location>

6. Create username/password for Apache directory

a. Use htpasswd.exe in the Apache2/bin directory to edit the password files.

b. Create a blank file called c:\somewhere_you_want\svn.pass

c. From a Dos window (make sure the path is correct), type the following htpasswd snv.pass svnuser

d. You’ll be prompted for a password. Enter whatever you want.

7. Restart Apache Again to load the configuration changes

8. Go to  http://localhost:8080/svn/ to make sure everything is working.

Posted in Nader, Source Control Tools | 5 Comments »

What is the difference between “Share” and “Share and Branch”?

Posted by archworx on October 1, 2006

What is the difference between “Share and Branch” and “Share” in source safe”?
I spent ages searching the net for meaning information on this.

The easiest explanation I found is as follows:

Share:
Is when 2 projetcs share a common library, so they only refererence that library, therefore, when changes happen to that library both projects see them.

Share and Branch:
This just takes a copy of the shared project and inserts it into your own project, so it will get a totally independent copy of the library and the changes you make won’t make the least bit of difference.
The doc below contains a lot of useful sourcesafe info:
http://portal.dfpug.de/dfpug/Dokumente/Partner/Hentzenwerke/Essential%20SourceSafe%20Chapter%2002.pdf

Posted in MSamy, Source Control Tools | 1 Comment »