As the title states, I am having issues with the MergeSynchronizationAgent class in C#. When I try to create my syncAgent using the following call:
syncAgent = subscription.SynchronizationAgent;
where
subscription = new MergePullSubscription();
I receive an error that states Microsoft.SqlServer.Replication.ComErrorException, "Class not registered". Now, I've read solutions to this problem and the most common one is to set my project platform to "Any CPU". This will fix the check out functionality of the tool but unfortunately there is other functionality in the program that looks up 64-bit databases, and setting the project's Platform to "Any CPU" breaks this look up functionality. This functionality is much more rigid than the checkout functionality so we have to set the project's platform to "x86" and have the checkout functionality work around this. My question is are there any other fixes to this ComErrorException issue where our project platform must be "x86"? I am using Sql Server 2008 R2.
I presume that you run a 64-bit edition of Microsoft SQL Server 2008.
The 64-bit installer package does not install / register the 32-bit ActiveX components. The Replication Management Objects (RMO) assemblies make use of these components when you try to access the SynchronizationAgent property.
This lack of registration is the reason why you receive the ComErrorException: your 32-bit application is looking for an ActiveX component with a specific GUID, but this GUID is present only in the 64-bit registry, which your application does not see. Should you build the "Any CPU" version, your application would run as 64-bit, and would thus see the 64-bit registry as well.
The 'workaround' for this is to get a 32-bit Virtual Machine running and install the 32-bit edition of Microsoft SQL Server 2008 there. Then you will need to manually copy a set of specific files from the Virtual Machine to your development environment, and integrate the registration of these files as part of your application setup.
You can find the specifics of the workaround from the bug report filed to Microsoft Connect. The bug report targets a 64-bit application running against a 32-bit SQL Server, but the scenario is the same.
Related
Our primary business application is written in a mixture of VB.NET and C# using VS2008. The back-end is SQL server Express 2005.
The application is NOT installed on client machines. It resides on a network share on (currently) a Windows Server 2003 machine which also hosts the database. Clients access the application through a shortcut, and there are additional server-side executables running as services which are accessed by the client application code. It's an entirely 32-bit environment at present.
We are moving to Server 2008 R2 and SQL Express 2008, and will be upgrading some of our 32-bit Win7 clients to 64-bit. I have set the Target CPU to "Any CPU" in the compile options of all .EXE and .DLL projects that comprise the application and have run PVerify on them all - they are entirely managed code.
Is this enough? Will both 32 and 64-bit clients be able to run the application seamlessly?
Thanks
The client applications should work in this configuration, assuming they are pure managed code as you say. You haven't said whether you've tested this or not, but testing shouldn't be all that hard. :-)
Note that 64-bit versions of Windows have the WoW64 subsystem that can run 32-bit applications, so you probably didn't have to do anything in the first place.
The question What does the Visual Studio “Any CPU” target mean? may be worth reading, but it looks like that is already understood here. If you need to be able to produce both x86 and x64 outputs (for example, if you have unmanaged DLLs that need to be called into), the question Targeting both 32bit and 64bit with Visual Studio in same solution/project may be useful.
I am beginner in using Microsft.ACE.OLEDB 12.0. I create a Winforms application VS 2010.
And create a function for export data grid data to MS Access file. I using Microsoft Oledb
for export the data grid data to MS Access file.But i get this error when i try to export
the
data to ms access.
Please see the below image.
I also refer the Microsoft.Office 12.0 Object Library in my application.
Batch Build Configuration
The reference to the Access Interop bits has nothing to do with your exception and Access Interop is not necessary to use the classes in the System.Data.OleDb.
The problem arises when you have your application compiled for AnyCPU Platform, you are running on a 64bit system and the installed ADO.NET provider (Microsoft ACE.OLEDB.12.0) is the 32bit version.
When using the AnyCpu target Platform your code will be executed as 64bit code on 64bit systems and as 32bit code on 32bit systems. An application executed as 64bit cannot use 32bit drivers (and viceversa). Now add to the mix the fact that Microsoft.ACE.OLEDB.12.0 has two different versions. One for 64bit and and one for 32bit and they cannot be installed together on the same machine.
The simplest workaround is to change the Target Platform of your application through Visual Studio menu
BUILD -> Configuration Manager -> Active Solution Platform -> x86
If the x86 option is not already there, then select NEW, name it x86, Copy Settings from AnyCPU and check Create new project platforms
If you think that using a 32bit app on a 64bit Operating System is a loss of performance or something to be avoided then think twice and read this reference where the PRO and CONS of AnyCpu are critically examined. If you don't have a specific reason to use AnyCpu it is better to stay with x86.
Of course, another option is to deinstall the 32bit version and install the 64bit version of ACE from here and then run you application as AnyCpu on 64bit systems. But this could be a nightmare for your deployment scenarios. What if Microsoft Office 32bit version is installed on your x64 target machine? Office installs its bit compatible version of ACE and, as said, it is not possible to have 32bit and 64bit of ACE installed on the same machine.
Now you should also ask your customer to reinstall Office as 64bit to keep your 64bit app happy.
UPDATE
The situation has changed a bit with the newest versions of Visual Studio. There is now a new option that is the default for new projects. It is called AnyCPU Prefer 32bit mode. More details at this link: What AnyCPU Really Means As Of .NET 4.5 and Visual Studio 11 and another interesting post (albeit regarding Sql Server Compact) is this one The trouble with Any CPU–Prefer 32 bit–BadImageFormatException
Change in its App pool 'advanced settings' to allow to run 32-bit programs... that did it for me.
I have similar issue when we are reading Excel file.
History of the problem:
We recently migrated our application from 32-bit to 64-bit because of the memory requirement. For that we migrated our windows 7 from 32-bit to 64-bit. But still we installed 32-bit office on our machines.
because, of this we had this issue while importing Excel data into application.
Solution,
I downloaded 64-bit version of the http://www.microsoft.com/en-us/download/details.aspx?id=13255 and installed with argument as,
AccessDatabaseEngine_x64.exe /passive
Without any code change my issue get resolved.
Note:
On 64-bit OS and 64-bit office, my functionality was working fine without this fix. This fix is only required while our application is 64-bit running on 64-bit OS which is having 32-bit office installed on it.
Base way:
Application : MVC C#,
For Win Server 64 bit:
Remove all office 32 bit installed.
Download link: https://www.microsoft.com/en-us/download/details.aspx?id=13255
select download 64 bit and then install it to server(If you can't setup program. Please re-check 1 point).
retry access your application again.enter image description here
for me installing Microsoft Access Database Engine 2010 Redistributable fixed the problem, the 32 bit version.
In my case
Download link: https://www.microsoft.com/en-us/download/details.aspx?id=13255
Select download 32 bit and then install it to server(Even if your server is 64-bit)
If you can't setup program uninstall 64 bit version.
Retry access your application again
If you have still error(Set Enable 32-bit Applications to True for your application in IIS)
I am new to .NET application.
I have developed the application on 32 bit OS with Visual Studio 2008.
The application required the Microsoft.Interop services and for PDF services to open PDF files and MS Office files.
It also required SQL Express for database operations.
The application works fine on 32bit OS.
Then I created the setup for 64 bit OS, I added a new Setup project with wizard in Visual
Studio 2010 and select the Primary output and Localized resources.
But it does not included the Resources folder to the Application folder.
I set the target machine 64x and build the project, also before building give the prerequisites to the project which is Windows Installer 3.1, and .net framework 4.0, I have used the .net framwork 3.5 in the application.
Then I ran the setup, which executed successfully.
But when I tried to run the application it gave the message "Application has stoped working. Finding for the solution from the web.." and it closed.
Then I saw that there was no resources folder so I just copied the resources folder to the application where it was installed. Then the application worked fine.
So I created the setup again but this time I also provided the Resources folder to the application folder. Built the Setup and tried to run the application but the same message is prompted to me as it was giving before "Application has stopped working...", so I looked for the resource folder and all the required files which were there.
Creating a separate 64-bit version makes no sense in your case.
You have dependencies to 32-bit components; as a consequence, all1 your assemblies must be compiled to the x86 target platform and be installed using a 32-bit MSI.
If you get an "Application has stopped working..." error, this indicates that an exception occurred that has not been handled by your process. You can get the stack trace e.g. from the event log.
1 In fact, at the least the entry assembly must have an x86 target platform, and all other assemblies must have either an x86 or AnyCPU target platform.
Check you have changed the platform target to x64 or AnyCPU in your project -> Build Properties
hey friends thanks for answering my question. Finally doing a lot of things I found that it was converting the sql database to 2008 while creating the setup. And I was setting the sql express 2005 on the client machine. Then I changed the sql server 2005 to sql express 2008 and run the setup. Then I found that at the first time the exe required all the rights to convert so I tried the setup Run as Administrator and bingo the setup works for 2 different pc..
The only thing is required that at first time I need to run the application as Administrator.
Thanks for help I
I made C# application for my friend which has connection to access database (mdb file). I have developed application on my computer with win7 x86 installed. My friend had XP and it worked perfectly, but now he installed win7 x64 and application doesn't work. In fact, application starts and behave regular, but cannot connect to database... Database too can be opened with access, but my application cannot connect to it.
What can be a problem? How to make my application works on both operating systems?
regards,
Vajda
Ask your friend to download and install the following file:
Microsoft Access Database Engine 2010 Redistributable
and make sure he picks the 64-bit version there (AccessDatabaseEngine_x64.exe).
By default there is no 64-bit ODBC/OLEDB driver for Access installed, but the 2010 version should work for 2007 databases as well.
You could probably also configure your program to be built for the x86 target. That would run the program as a 32-bit program, even on 64-bit OS.
Most likely, the .Net CLR is trying to fire the app up in 64bit mode by default on his new win7 box and this might be causing some issues with the referenced assemblies.
The first thing I would try is to change the Platform target of the application (go to Project properties in Visual Studio for the application) to x86 (from Any CPU) to force the application to run in 32bit mode.
If this works, you will have narrowed down your problem.
Then, after building the project, look in the bin folder to see which assemblies are being copied to the output folder. If you see any System.Data... or any other .Net assemblies that are already contained in the GAC, you'll want to delete these and then try to fire it up. This will force the application to use GAC assemblies written for 64bit use.
I am using a Windows Server 2003 32-bit machine. Using that machine I have created a COM component and consumed it in another application and have an EXE file.
Now I copy that EXE to another machine installed with Windows Server 2008, 64-bit.
And when I try to run that EXE it shows something like "Debug Error: This application needs runtime and terminates in an unusual way".
Is the bitness (32-bit vs 64-bit) compatibilty the reason for this? What could I need to run this on a Windows Server 2008 machine?
When you compile your app, you need to make sure that you compile it for 32 bit. By default, Visual Studio compiles for "Any". This leads to some parts of your app being 32 bit and using 64 bit DLLs.
The .NET framework built into Server 2008 is v3.0. Does your application require .NET v3.5? If so, you'll need to install the .NET 3.5 Redistributable package in Server 2008.
http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe
It should works, thanks to WOW64.
You compiled as debug or release version?
And can it find all the references that are you using?
What development environment are you using? It sounds like your projects are configured to use the C++ runtime DLL for a version that is not installed on the target box.
There should be a VC_Redist.exe somewhere in your development environment that you can copy and execute on the target box to install the necessary runtime assemblies.
Or, go to every project, EXE and DLLs, and ensure that the "Runtime Library" setting under the Project Properties->C/C++->Code Generation page is set to one of the non DLL options (/MTd or /MT). This will bypass the need to install a separate runtime on the target PC, but will make your EXEs and DLLs a bit larger.