diff --git a/doc/reference/src/migration.xml b/doc/reference/src/migration.xml
index 383d4736..d782352f 100644
--- a/doc/reference/src/migration.xml
+++ b/doc/reference/src/migration.xml
@@ -1,148 +1,182 @@
-
-
-
- Migrating from 1.1 M2
-
-
- Introduction
-
- Several API changes were made after 1.1 M2 (before 1.1 RC1)due
- primarily by the need to refactor the code base to remove circular
- dependency cycles, which are now all removed. Class and schema name
- changes were also made to provide a more consistent naming convention
- across the codebase. As a result of these changes, you can not simply drop
- in the new .dlls as you may have done in previous release. This document
- serves as a high level guide to the most likely areas where you will need
- to make changes to either your configuration or your code.
-
- The file, BreakingChanges-1.1.txt, in the root directory of the
- distribution contains the full listing of breaking changes made for RC1
- and higher
-
-
-
- Important Changes
-
- This section covers the common areas were you will need to make
- changes in code/configuration when migration from M2 to RC1or
- higher.
-
-
- Namespaces
-
- Note: If you previously installed Spring .xsd files to your VS.NET
- installation directory, remove them manually, and copy over the new
- ones, which have the -1.1.xsd suffix.
-
- The names of the section handlers to register custom schemas has
- changed, from ConfigParsersSectionHandler to
- NamespaceParsersSectionHandler.
-
- The target namespaces have changed, the 'directory' named /schema/
- has been removed. For example, the target schema changed from
- http://www.springframework.net/schema/tx to
- http://www.springframework.net/tx.
-
- A typical declaration to use custom schemas within your
- configuration file looks like this
-
- <objects xmlns='http://www.springframework.net'
- xmlns:db="http://www.springframework.net/database"
- xmlns:tx="http://www.springframework.net/tx"
- xmlns:aop="http://www.springframework.net/aop">
-
- The class XmlParserRegistry was renamed to
- NamespaceParserRegistry.
-
- Renamed
- Spring.Validation.ValidationConfigParser to
- Spring.Validation.Config.ValidationNamespaceParser
-
- Renamed from DatabaseConfigParser to
- DatabaseNamespaceParser
-
- Renamed/Moved Remoting.RemotingConfigParser
- to
- Remoting.Config.RemotingNamespaceParser
-
- A typical registration of custom parsers within your configuration
- file looks like this
-
- <configuration>
-
- <configSections>
- <sectionGroup name="spring">
- <section name="parsers" type="Spring.Context.Support.NamespaceParsersSectionHandler, Spring.Core"/>
- </sectionGroup>
- </configSections>
-
- <spring>
- <parsers>
- <parser type="Spring.Aop.Config.AopNamespaceParser, Spring.Aop" />
- <parser type="Spring.Data.Config.DatabaseNamespaceParser, Spring.Data" />
- <parser type="Spring.Transaction.Config.TxNamespaceParser, Spring.Data" />
- </parsers>
- </spring>
-
- A manual registration would look like this
-
- NamespaceParserRegistry.RegisterParser(typeof(AopNamespaceParser));
-NamespaceParserRegistry.RegisterParser(typeof(DatabaseNamespaceParser));
-NamespaceParserRegistry.RegisterParser(typeof(TxNamespaceParser));
-
-
-
-
- Core
-
- Moved Spring.Util.DynamicReflection to
- Spring.Reflection.Dynamic
-
- Moved TypeRegistry and related classes from Spring.Context.Support
- to Spring.Core.TypeResolution
-
- Moved Spring.Objects.TypeConverters to
- Spring.Core.TypeConvesion
-
-
-
- Web
-
- Moved Spring.Web.Validation to Spring.Web.UI.Validation
-
-
-
- Data
-
- Changed schema to use 'provider' instead of 'dbProvider' element,
- usage is now <db:provider ... /> and not <db:dbProvider
- .../>
-
- Moved TransactionTemplate, TransactionDelegate and
- ITransactionCallback from Spring.Data to Spring.Data.Support
-
- Moved AdoTemplate, AdoAccessor, AdoDaoSupport,
- RowMapperResultSetExtractor from Spring.Data to Spring.Data.Core
-
- Moved AdoPlatformTransactionManager,
- ServiceDomainPlatformTransactionManager, and TxScopeTransactionManager
- from Spring.Data to Spring.Data.Core
-
-
-
\ No newline at end of file
+
+
+
+ Migrating from 1.1 M2
+
+
+ Introduction
+
+ Several API changes were made after 1.1 M2 (before 1.1 RC1)due
+ primarily by the need to refactor the code base to remove circular
+ dependency cycles, which are now all removed. Class and schema name
+ changes were also made to provide a more consistent naming convention
+ across the codebase. As a result of these changes, you can not simply drop
+ in the new .dlls as you may have done in previous release. This document
+ serves as a high level guide to the most likely areas where you will need
+ to make changes to either your configuration or your code.
+
+ The file, BreakingChanges-1.1.txt, in the root directory of the
+ distribution contains the full listing of breaking changes made for RC1
+ and higher
+
+
+
+ Important Changes
+
+ This section covers the common areas were you will need to make
+ changes in code/configuration when migration from M2 to RC1or
+ higher.
+
+
+ Namespaces
+
+ Note: If you previously installed Spring .xsd files to your VS.NET
+ installation directory, remove them manually, and copy over the new
+ ones, which have the -1.1.xsd suffix.
+
+ The names of the section handlers to register custom schemas has
+ changed, from ConfigParsersSectionHandler to
+ NamespaceParsersSectionHandler.
+
+ The target namespaces have changed, the 'directory' named /schema/
+ has been removed. For example, the target schema changed from
+ http://www.springframework.net/schema/tx to
+ http://www.springframework.net/tx.
+
+ A typical declaration to use custom schemas within your
+ configuration file looks like this
+
+ <objects xmlns='http://www.springframework.net'
+ xmlns:db="http://www.springframework.net/database"
+ xmlns:tx="http://www.springframework.net/tx"
+ xmlns:aop="http://www.springframework.net/aop">
+
+ The class XmlParserRegistry was renamed to
+ NamespaceParserRegistry.
+
+ Renamed
+ Spring.Validation.ValidationConfigParser to
+ Spring.Validation.Config.ValidationNamespaceParser
+
+ Renamed from DatabaseConfigParser to
+ DatabaseNamespaceParser
+
+ Renamed/Moved Remoting.RemotingConfigParser to
+ Remoting.Config.RemotingNamespaceParser
+
+ A typical registration of custom parsers within your configuration
+ file looks like this
+
+ <configuration>
+ <configSections>
+ <sectionGroup name="spring">
+ <section name="parsers" type="Spring.Context.Support.NamespaceParsersSectionHandler, Spring.Core"/>
+ </sectionGroup>
+ </configSections>
+
+ <spring>
+ <parsers>
+ <parser type="Spring.Aop.Config.AopNamespaceParser, Spring.Aop" />
+ <parser type="Spring.Data.Config.DatabaseNamespaceParser, Spring.Data" />
+ <parser type="Spring.Transaction.Config.TxNamespaceParser, Spring.Data" />
+ </parsers>
+ </spring>
+
+ A manual registration would look like this
+
+ NamespaceParserRegistry.RegisterParser(typeof(AopNamespaceParser));
+NamespaceParserRegistry.RegisterParser(typeof(DatabaseNamespaceParser));
+NamespaceParserRegistry.RegisterParser(typeof(TxNamespaceParser));
+
+
+
+
+ Core
+
+ Moved Spring.Util.DynamicReflection to
+ Spring.Reflection.Dynamic
+
+ Moved TypeRegistry and related classes from Spring.Context.Support
+ to Spring.Core.TypeResolution
+
+ Moved Spring.Objects.TypeConverters to
+ Spring.Core.TypeConvesion
+
+
+
+ Web
+
+ Moved Spring.Web.Validation to Spring.Web.UI.Validation
+
+
+
+ Data
+
+ Changed schema to use 'provider' instead of 'dbProvider' element,
+ usage is now <db:provider ... /> and not <db:dbProvider
+ .../>
+
+ Moved TransactionTemplate, TransactionDelegate and
+ ITransactionCallback from Spring.Data to Spring.Data.Support
+
+ Moved AdoTemplate, AdoAccessor, AdoDaoSupport,
+ RowMapperResultSetExtractor from Spring.Data to Spring.Data.Core
+
+ Moved AdoPlatformTransactionManager,
+ ServiceDomainPlatformTransactionManager, and TxScopeTransactionManager
+ from Spring.Data to Spring.Data.Core
+
+
+
+
+ Support for .NET 4
+
+ Beginning with the 1.3.1 release of Spring.NET, initial
+ compatibility with the .NET 4 Common Language Runtime (CLR) is provided
+ via the .NET 4 Framework's support for In-Process Side-by-Side deployment
+ of .NET assemblies. This approach is typically refered to as
+ In-Proc SxS.
+
+
+ For more information on the In-Process Side-by-Side support
+ introduced into the .NET 4 Framework, see the MSDN Magazine article
+ located here:
+ http://msdn.microsoft.com/en-us/magazine/ee819091.aspx
+
+
+
+ In-Prox SxS permits applicaitons that target
+ the .NET 4 Framework (and later) to reference and execute assemblies that
+ target earlier versions of the .NET Framework CLR transparently within the
+ same process space. By using this approach, Spring.NET ensures maximum
+ backwards-compatibility with prior .NET Framework releases.
+
+ Subsequent releases of Spring.NET will be compiled to target the
+ .NET 4 Framework directly but during this transition period where
+ significant users are using Spring.NET to target pre-.NET 4 applications
+ while at the same time other users are beginning to target the .NET 4
+ Framework CLR, supporting In-Proc SxS will permit
+ maximum flexibility for Spring.NET users.
+
+