Chapter 4. Migrating from 1.1 M2

4.1. 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

4.2. 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.

4.2.1. 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));

4.2.2. 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

4.2.3. Web

Moved Spring.Web.Validation to Spring.Web.UI.Validation

4.2.4. 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

4.3. 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.

[Note]Note

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.