Background
SQL Server provides a very convenient method for implementing custom business logic in coordination with the synchronization/merge process of replication. For tasks which need to be done as data is synchronized, or decisions about resolving conflicts which are business-specific, implementing a custom resolver is a surprisingly straight-forward way to go. For more information, check out the following resources:
- How to: Implement a Business Logic Handler for a Merge Article (Replication Programming)
- How to: Implement a COM-Based Custom Conflict Resolver for a Merge Article (Replication Programming)
- BusinessLogicModule Class
Making It Work
Things are never quite as easy as they seem... Chances are, some sort of error message was generated once the DLL was deployed and the instructions in (1) were completed. For example, the following error is common:
Error loading custom assembly "assemblyname", Error : "Could not load file or assembly 'assemblyname' or one of its dependencies. The system cannot find the file specified.
Don't Panic. First, check that the DLL has been placed in the directory containing the merge agent on the subscriber (assuming this is being done with pull - place the DLL on the server for push) or registered in the GAC. This message can also indicate dependency problems for the DLL where dependent libraries can't be found/loaded. One way to test that the assembly can be loaded is to compile and run the following program in the same directory as the merge agent:
class Program
{ static void Main
(string[] args
) { TryLoadType
(ASSEMBLY_NAME, CLASS_NAME
); // Leave window visible for non-CLI users Console
.ReadKey(); } static void TryLoadType
(string assemblyname,
string typename
) { try { Assembly asm
= Assembly
.Load(assemblyname
); if (asm
== null) { Console
.WriteLine("Failed to load assembly"); return; } Type type
= asm
.GetType(typename
); if (type
== null) { Console
.WriteLine("Failed to load type"); return; } ConstructorInfo constr
= type
.GetConstructor(new Type
[0]); if (constr
== null) { Console
.WriteLine("Failed to find 0-argument constructor"); return; } object instance
= constr
.Invoke(new object[0]); Console
.WriteLine("Successfully loaded " + type
.Name); } catch (Exception ex
) { Console
.Error.WriteLine("Error loading type: " + ex
.Message); } }}
Note: It is very important to correctly determine where the merge agent executable is and where it is being run from when testing. The DLL search path includes both the directory in which the executable file exists and the directory from which it is run (for weak-named assemblies). replmerg.exe usually lives in C:\Program Files\Microsoft SQL Server\90\COM, but mobsync.exe (if you are using Synchronization Manager or Sync Center) is in C:\WINDOWS\system32, and this will have an effect on the assembly search path.
Make sure the names are exactly as they were specified in sp_registercustomresolver. If the problem was a misnamed assembly or class (because you are like me and fat-fingered the name...) here's how you fix it: sp_registercustomresolver can be re-run with the same @article_resolver parameter to overwrite the information for that resolver. This overwrites the information stored in the registry at HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\90\Replication\ArticleResolver (or a similar location for different versions/configurations). However, if the resolver has already been attached to an article, the information is also stored in sysmergearticles in the article_resolver (assembly name), resolver_clsid (CLSID), and resolver_info (.NET class name) columns. So, run an UPDATE on these columns to fix errors, as appropriate.
Good Luck!
