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.
Related
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)
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.
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'm updating my operating system to Windows 7 x64, I only have experience with running 32-bit operating systems. Does anyone have any bad/good experiences with a 64 bit environment?
For reference, the tools I use are:
Visual Studio 2008
Tortoise SVN
TestDriven.Net
Oracle 10g XE
PL/SQL Developer
Dundas Chart
Analysis Services from MS SQL Server 2008
Running on a 64-bit operating system has a number of side effects that will be noticeable to some extent. The most common issues:
Edit and Continue in Visual Studio won't work. You can fix this by forcing your .NET app to run in 32-bit mode. Project + Properties, Build tab, Platform Target = x86. Resolved in VS2013.
If you use any ActiveX controls or COM components in your .NET app you may find your program no longer works since your machine doesn't have a corresponding 64-bit version of the COM server. You'll get error 0x80040154, REGDB_E_CLASSNOTREG, "Class not registered". Same fix as above.
The 64-bit debugger doesn't support mixed-mode debugging, you'll have to commit to either Managed only or Native only debugging. Same fix as above, as long as you don't have 64-bit specific issues. Resolved in VS2010.
Poorly written P/Invoke declarations that declare an uint or int where an IntPtr is required will stop working in 64-bit mode. You'll generally get an AccessViolation exception or a failure return code. Or a PInvokeStackImbalance MDA warning. You should not have any trouble locating the mistake, just fix the declaration.
Several legacy end-of-life Microsoft libraries are not available in a 64-bit version. That's most commonly a problem with Microsoft Access databases. Same fix as above.
You must use the correct version of Regasm.exe to register [ComVisible] assemblies. Select the one from either Framework or Framework64, depending on whether the client program is going to run in 64-bit or 32-bit mode. Or both if you want the server to be available in either.
A few COM type libraries contain bit-ness dependent arguments in their method declarations. ADO 2.8 is a notable one. Be sure to use the correct bitness of Tlbimp.exe to generate the correct COM interop assembly, Visual Studio won't do this right. Same approach as Regasm.exe
A 32-bit program has a different view of the registry from a 64-bit program. Specifically the HKCR and HKLM\Software hives are virtualized. In Regedit.exe, the 32-bit visible keys are seen under the HKLM\Software\Wow6432Node key. This can cause many subtle problems with programs that use the registry. The .NET 4 RegistryKey.OpenBaseKey() allows specifying the view you want.
Again for COM, you'll have the use the correct bitness of Regsvr32.exe to register an unmanaged COM server (not .NET servers, they use Regasm.exe). Use the one in c:\windows\system32 for 64-bit servers, c:\windows\syswow64 for 32-bit servers.
Folders in the file system are virtualized, specifically c:\windows\system32 and c:\program files. A 32-bit program will see c:\windows\syswow64 and c:\program files (x86).
Installers need to take all the above issues in consideration.
I wouldn't worry too much, if each program has an x64 download link, then use that. If not then your code will run through WOW64 emulation. And it will seem to you like it is running like normal.
Please see this related question I answered about 5 minutes ago.
WOW64 refers to windows32 on windows64
and it is a transparent emulation
laywer that allows x86 programs to run
on x64 operating systems. WOW64 will
automatically be used if you run an
x86 Windows program on an x64 Windows
operating system.
I am running Windows 7 Ultimate x64.
Visual Studio 2008 works fine.
I am using Subversion, but not Tortoise. AnkhSVN works fine.
The others I have no experience with.
Majority of software I use has no issues with x64, it's been a few years since the XP x64 troubles, and people have caught up with x64 it seems.
The primary issue with development in x64 however, is when running in x64 mode in Visual Studio, you can not edit code while debugging.
You must use x86 as the target platform in order to do so.
This is one of the reasons one of the beta's for Visual Studio 2010 defaulted target platform to x32 instead of Any Platform...
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.