This post discusses a lot about the way db4o activates (reads) and stores (writes) objects so it assumes you are familiar with the activation depth, transparent activation/persistence concepts. If you are not (or if you want to refresh your memory), please, read the following posts/docs. 

If you take a look in the changes introduced in db4o in the last years you'll see that we have been paving the way for a more intuitive and performant object storage model. First we introduced Transparent Activation (or TA for short) simplifying object activation hurdles and, at the same time, bringing some nice performance improvements. The next step was to introduce a TA equivalent for the update side: Transparent Persistence (or TP for short).
 
Although bringing big improvements, in both ease of use and performance camps, our implementation had a serious limitation: the framework collections (in both platforms, Java and .Net) were not supported (i.e, they didn't play nicely with TA/TP). Since this limitation puts a performance penalty for every class that stores such collections (a pretty common scenario) we moved on and started introducing our own "activation" enabled collections.
 
With these collections in place you may defer activation costs to the point where you really need to use your collection; in scenarios where you don't touch the collection you'll be able to avoid activating it altogether!
 
We built these TA/TP friendly collections for Java first. Today we are proud to announce that we started adding support for the .Net collections also. As of today List<T> and Dictionary<TKey, TValue> are supported (our implementations are called ActivatableList and ActivatableDictionary respectively). We certainly want to grow this list based on community feedback.
 
In order to get the benefits brought by these collections you may either choose to refactor your code replacing the framework versions (with the db4o counterparts) manually or you can keep your code as it is (as much as possible) and rely on our instrumentation tool (Db4oTool) to apply these replacements on your binary assemblies. 
 
No matter what approach you choose (manual / instrumentation  replacement) keep in mind that the original (FCL) collections were not developed with extensibility in mind so we could not simply inherit from them, as we do in the Java side. So, the best practice regarding their usage is to define your class fields/local variables/parameters typed to the collection interfaces (instead of the concrete classes that implement them). The rest of this post assumes you'll be following this guidance.
 
If you decide to follow the manual refactoring path, just replace List<T>/Dictionary<TKey, TValue> constructor calls with db4o implementations (ActivatableList<T> / ActivatableDictionary<TKey, TValue>). If you have any methods being called directly on the concrete type (for instance List<T>.BinarySearch()) just replace the target of the cast to the respective db4o collection.
class TestCollection 
{ 
    private List<int> _list = new List<int>(); 

    public void DoSomething() 
    {
          _list.BinarySearch(10); 
     }
 }
should become:
class TestCollection 
{ 
    private IList<int> _list = new ActivatableList<int>(); 
   
    public void DoSomething() 
    {
         ((ActivatableList<int>)_list).BinarySearch(10);
     }
  }
 
If you decide to use instrumentation instead, run Db4oTool with "-ta" and "-collections" arguments. After instrumentation finishes you can use reflector to confirm that Db4oTool indeed applied the transformations above.
 
If Db4oTool encounters any construct that may not be converted it'll emit either a warning or an error. For instance the following classes would cause Db4oTool to emit a warning (and leave the assembly untouched) because the concrete List type is used in the field declaration (declare as IList<int> instead):
 
class TestCollection
{ 
    private List<int> _list = new List<int>(); 
   
   public void DoSomething() { }
 }

class TestDb4oToolWarning2 
{
    public void DoSomethingWithList(List<int> items) { } 
   
    protected static void Main() 
    { 
           new TestDb4oToolWarning2().DoSomethingWithList(new List<int>());  
    }
 }
Note that Db4oTool will replace all List<T>/DIctionary<TKey, TValue> constructor calls by db4o equivalent ones. That means that fields, local variables and parameter assignments will be replaced.
 
Please go grab the db4o development release and try it out (and please, let us know about any issue / concern you may have and/or improvement ideas).
 
As always, last but not least, we are still working on performance improvements, so bear with us, and stay tuned.
 
Best
 
Yours db4o team!