September 20, 2010 at 9:27 am
I maintain our company's sales force automation package, which supports over 100 salespeople nationwide. This application uses SQL RMO to sync the client data up to our server once the rep triggers a sync process at the end of their business day. The field units use 32 bit laptops running XP, and use SQL Express 2005 for their database platform.
Recently, our development machines here at corporate were replaced with 64 bit machines running Windows 7. Since then, I have been unable to run this project in Visual Studio. The issues comes when the program hits the first reference to MergeSynchronationAgent, where I get the following:
Message: "Class not registered"
StackTrace: " at Microsoft.SqlServer.Replication.MergeSynchronizationAgent..ctor()\r at Microsoft.SqlServer.Replication.MergePullSubscription.get_SynchronizationAgent()\r at ReplicationAgent.MergeAgent.ProcessReplication() in D:\\Projects\\{ProjectName}\\ReplicationAgent\\ReplicationAgent.cs:line 77"
I have tried to install the 32 bit version of SQL Express on my (now 64 bit) development machine, but the installer will not allow this. When I install the 64 bit version I get the above error during debug.
My understanding was that the only difference between the 32 and 64 bit versions of SQL Express were the presence of additional files in the 64 bit version that would allow it to run on a 64 bit OS. That being the case, I'm not sure what I'm missing here. I've verified the assemblies exist in the SDK folder, and have installed the following as described in other posts:
Microsoft Core XML Services (MSXML) 6.0
Microsoft SQL Server 2005 Management Objects Collection
Microsoft SQL Server Native Client
This sounds like it should be a fairly common issue, but I've had the toughest time finding a definitive solution. Any help would be appreciated. I cannot push changes to the field to accomodate a fix for my development machine, but surely there must be a way to develop and run this application on a 64 bit machine, while still targeting a 32 bit user environment.
Thanks!
September 20, 2010 at 5:24 pm
Have you considered doing your development using Windows XP Mode? Not the solution that you are looking for, but it could help you move forward for now.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
November 16, 2010 at 2:27 pm
Did you ever find a solution to this issue? We're running into the same scenario.
Thanks
November 16, 2010 at 5:04 pm
No the best answer I got was to use XP mode... I am wrapping up a company-wide deployment that I've been on for a few months now, so hopefully I'll be able to devote more time to this in the next few weeks.
Charles
December 3, 2010 at 4:30 pm
Charles-126316 (11/16/2010)
No the best answer I got was to use XP mode... I am wrapping up a company-wide deployment that I've been on for a few months now, so hopefully I'll be able to devote more time to this in the next few weeks.Charles
You don't need XP mode you only need a paid version of VS2005/8/10 so you can build the RMO(replication management object) code AnyCPU instead of x64 which will not run in x86 which is 32bits. AnyCPU will run in both boxes also look for the x86 programs file folder in Windows 7.
Kind regards,
Gift Peddie
January 10, 2011 at 9:55 am
I was running into the same problem. My old system was XP 32-bit, and new system is Windows7 64-bit. Both using SQL Express 05. I managed to fix it by going into Configuration Manager and creating a new x86 platform with the copy settings set to <Empty>. If you already have an x86 option, try deleting and re-creating.
We are also working on 64-bit software the throws a ""SynchronizationAgent" can only be used if the object presents an existing object in the server". I think it is also a 64/32-bit issue. None of the current solutions out there I've found seem to work for me.
January 11, 2011 at 4:54 am
If you are deploying to 32-bit then build and test on 32-bit.
If you build on 64-bit then test on 32-bit before you deploy.
If you build and test on 64-bit then expect the unexpected problems when you deploy to 32-bit. And expect you will not be able to troubleshoot these problems on a 64-bit OS.
There are just too many differences in the software stack between a 32-bit and 64-bit OS to expect that a build and test on 64-bit will work as expected when deployed to 32-bit. The same applies if you build and test on 32-bit and deploy on 64-bit. At least, that is what we have found where I work.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
March 9, 2012 at 9:59 am
I just wanted to update this thread with a solution that worked for me. I had a requirement to develop a replication client that would work with 2008 R2 and 2005 Full and Express editions (basically SQL 9.0 and higher).
I encountered the cryptic "Class not registered" exception for the MergeSynchronizationAgent early on and had the same problem some others have had where my dev environment is 64 bit and my deployment environments are mixed 32 and 64. The first fix to that was to choose Any Platform as the build type. That allowed me to get past the error when using 2008 R2 Full and Express editions. However, clients using SQL 2005 still got the same exception.
To fix that scenario I had to do the following:
Install the following 2008 R2 Redistributables from Microsoft:
SharedManagementObjects.msi
SqlCmdLnUtils.msi
sqlncli.msi
SQLSysClrTypes.msi
Not included, but required to use RMO was:
sql_rmo.msi
This will allow you get as far as creating a subscription successfully at the client, however, you will still encounter the "Class not registered" exception when you attempt to do anything with your MergeSynchronizationAgent.
To overcome that, I had to copy the entire contents of the COM folder from a healthy SQL 2008 Express installation to the failing 2005 client environment and register the following dlls manually using regsvr32:
cd "C:\Program Files\Microsoft SQL Server\100\COM"
regsvr32 AXSCPHST.DLL
regsvr32 mergetxt.dll
regsvr32 msgprox.dll
regsvr32 REPLAGNT.dll
regsvr32 REPLDP.dll
regsvr32 replerrx.dll
regsvr32 replisapi.dll
regsvr32 replprov.dll
regsvr32 replrec.dll
regsvr32 replsub.dll
regsvr32 sqldistx.dll
regsvr32 sqlmergx.dll
regsvr32 ssradd.dll
regsvr32 ssravg.dll
regsvr32 ssrdown.dll
regsvr32 ssrmax.dll
regsvr32 ssrmin.dll
regsvr32 ssrpub.dll
regsvr32 ssrup.dll
regsvr32 xmlsub.dll
At this point you should be able to subscribe and sync at your leisure using a 2005 host in 32 bit environments.
This cost me some time and frustration while researching, but I've learned much from it.
Hopefully this helps someone else...
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply