De Tout Et De Rien

Image that your .NET application uses an assembly. When compiled, the application references the exact version of that assembly. If a new minor of this assembly is installed, your application will not use it unless a policy told her so. This is fine in most cases, as it avoids the DLL hell issue.

But, the problem with assembly policy is that the oldVersion attribute cannot be a wildcard. You have to specify the exact old version of assembly to redirect to the new one. This can be a problem when you have several versions of the assembly and want to redirect them to the latest version.

There are two solutions for that: - Define as much redirect as there is old versions of the assembly. This is the explicit way. - Although oldVersion attribute cannot be a wildcard, it can be a range. All you have to do is to define the lower and upper bound of the version. This is the implicit way.

Here is an example of range use:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
       <dependentAssembly>
         <assemblyIdentity name="Monobjc" publicKeyToken="d5a8d181860c16be" />
         <bindingRedirect oldVersion="10.5.0.0-10.5.65535.65535" newVersion="10.5.1492.0"/>
       </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

This policy will redirect any assembly whose version begins with "10.5" to the newVersion.

I have update my Visual Studio adding named "Add Dependent Files" (See the original entry). It is available for download here.

Monobjc 2.0.313.0 was released on December 2008, the 17th. One major addition in Monobjc is the support of Sparkle update engine. Sparkle is one of the most used framework in the Cocoa world, as it makes updating an application a breeze. The main problem with Sparkle in Monobjc was the private framework embedding. With Sparkle, updating a Monobjc application has never been so simple. Check out the tutorial for Monobjc and Sparkle.

Many people want to package their .NET application for Mac OS X. And above all, they want the experience to be painless, which means that they want to ship an application that runs, whether Mono is installed or not.

The process of packaging a .NET application for Mac OS X basically follows 4 steps:

• Getting .NET dependencies of the .NET executable
• Generating a native loader that will embed all the .NET assemblies (.NET executable and .NET dependencies)
• Getting native dependencies of the native executable
• Relocating all the stuff so library loading goes well

The process can be even more complicated if you are using reflection, dynamically discovered library and so on. So let's keep thing simple.

Getting .NET dependencies

This is the easy part. You just have to find recursively all the .NET dependencies of the .NET executable. As every .NET assembly contains its references, it is trivial.

Generating a native loader

The native loader generation is simplified by the fact that Mono allows .NET assemblies to be loaded from embedded binary streams. So for every .NET assembly, we generate a binary array and use the magical functions of Mono. If there are configuration files to embed, the process is the same.

Getting native dependencies

Once the native loader is compiled, the otool command can give us all the native dependencies. So we gather all the native library needed to run our application. But on Mac OS X, the dynamic loading is based on paths recorded in each native library. This is the point of the next step.

Relocating all the stuff

This is the tougher part of the packaging. Now that you have all the native dependencies, you must be sure that you only have unique dependencies. Why, because we you gather dependencies, you can find either specific version of a library or compatibility version of a library. Failing to make these reference unique can lead to unexpected behavior (mostly cryptic crashes). That where the otool command is useful as the first line always contains the specific version of a library, even if run against a compatibility version symbolic link. Then the install_name is used to change absolute path to relative path containing the macro @executable_path.

Packaging made easy

All this steps can be tedious and error prone. That's why, in the Monobjc, the packaging is done by a NAnt task: <mkbundle/> (you can find its options on this page). This task can handle most of the need for .NET application packaging in a truly simple way. And as a bonus, this task is not linked to the Monobjc bridge, so you can use it even if you don't use the Monobjc bridge.

Maybe you have already got this error while (re)installing IPv6 on Windows XP:

C:\>ipv6 install
Installing...
Failed to complete the action
Error 0×800704b8

The fix has to do with the Windows security database, which may not be up-to-date. To fix this database, type the following command:

C:\>esentutl /p C:\WINDOWS\security\Database\secedit.sdb

Microsoft(R) Windows(TM) Database Utilities
Version 5.1
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating REPAIR mode...
Database: C:\WINDOWS\security\Database\secedit.sdb
Temp. Database: TEMPREPAIRxxxx.EDB

Checking database integrity.

Scanning Status (% complete)

0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................

Integrity check successful.

Note:
It is recommended that you immediately perform a full backup
of this database. If you restore a backup made before the
repair, the database will be rolled back to the state
it was in at the time of that backup.

Operation completed successfully in 4.469 seconds.

Once the above command is passed, everything should be ok.

C:\>ipv6 install
Installing...
Succeeded.

See http://support.microsoft.com/?scid=kb%3Ben-us%3B318711&x=10&y=14 for more informations.