As the popular saying  tell us, there's no such thing as free lunch. It is no different for work related subjects.

When we introduced Transparent Activation (TA) concept we knew that it could make developer's life easier (by presenting a simpler model for object life cycle): developers would not be required to think about activation depths again; just let db4o activate your objects when it's need.

IMHO, it was a great improvement since it not only simplifies developer's life as well brings some performance gains also (once objects get activated only when needed there's no wasted time activating objects not needed). But this was not without coasts: to benefit from this simpler model, developers were required to implement IActivatable interface for each object that they wanted to be TA. Also, once enabled, any non TA aware object will be fully activated at retrieval time.

Time passed and we introduced  a way relieve developers from the need to implement Activatable interface, i.e, to make classes TA aware with no effort from developers. This is accomplished through a technique called instrumentation in which we dive into byte code level doing something like:

1. Find each type declared in a specific assembly (.net) / jar or class (java)
   
2. Analise each type found in step 1 to check whether it is a potential candidate for TA or not
   
3. If we found a potential candidate for TA
   
• Make the type to implement IActivatable interface
• Implement IActivatable methods
  
• Ensure that the object will be activated prior to any field access by inspecting each field access in this type and inserting the required Activate() / activate() call prior to it.
  
4. Save the binary component
   

A pretty straight approach, I'd say.

But even when using instrumentation there are some implications that developers should be aware of. To illustrate, think about assembly signing; this is a process in which a developer "seals" an assembly contents by digitally signing it (the whole concept is beyond this post).

Basically, by signing an assembly a developer is providing ways to administrators to selectively grant access to assemblies based on the private key (related to the public key) used to sign it; also, signed assemblies are tamper resistant which means that changes (in byte code level) don't go unnoticed.

By the above description it's clear that instrumenting  a signed assembly turns it invalid afterward (since its contents gets changed) and any tentative of loading it will fail with a invalid signature error.

So, after instrumenting signed assemblies you will need to sign them again but, IMHO, you should never, ever, instrument assemblies that are not under your control, so I'd suggest you to just change your build scripts so instrumentation takes place prior to signing.

To help developers detect this, starting from version 7.4.52 Db4oTool will emit an warning when asked to instrument (whether for TA/TP or Native Queries optimizations) a signed/delay signed assembly.

Just for the sake of completeness I've included the following walk through on how to create assemblies that are instrumented and signed (for a in depth discussion on signing assemblies please, read this).

1. In Visual Studio, open project properties window and select signing tab.
   
   
2. Select Sign the assembly;
   
   
3. Expand Choose a strong name key file drop down listbox and either, select a previously created key or create a new one by selecting option;
   
   
4. Select Delay sign only checkbox;
   
   
5. Save your project and build
   
   
6. Instrument your assembly (either running Db4oTool or through Db4oToolEnhancerMSBuildTask)
   
   
7. After instrumentation, run sn tool as follows to finish the sign process:
   
   sn -Ra myassembly.dll mykey.snk
   

That's it! Your assembly is instrumented and signed.

In the next post I'll address some other implications / pitfalls regarding instrumentation for TA/TP.

Thoughts?