i develop an Asp core web application (.net framework).
how i specify a run as 32-bit applications?
the publish wizard do not give way to change the Target Runtime, which the selected option is x64 is selected.
I installed on my machine the x86 version of .NET Core Installer.
publish wizard screenshot:
PS Why do I need x86.
I had to run the site on a computer that installed Microsoft Access 32-bit (2003, for an old software).
I also need to access data in Microsoft Access file, which requires me to use the Microsoft.Jet.OLEDB.4.0 driver.
The problem is, probably, that the app's core ASP.NET always running as 64-bit applications, is what gives me the known exception 'driver not registred'
stil after set "enable 32-bit application" in IIS.
i cant install the 64-bit access driver engine, because it requires the removal of MS Access 32-bit...
As mentioned here you need to add the "runtimes" key to your project.json file like below image.
Once you do this, the Target Runtime entry in Publish menu will list all of your specified runtimes. Although this is not enough to get it working since using the Publish menu and selecting x86 version will have no effect and will result in x64 binary files. (This bug may be fixed in future).
The workaround is to navigate to your project folder where the project.json resides. Open a command prompt and type the following to have your binary in desired runtime:
dotnet publish --runtime win7-x86
If you get any error yet, you may need to have the corresponding runtime installed (Download form here).
More info:
https://learn.microsoft.com/en-us/dotnet/articles/core/app-types
https://learn.microsoft.com/en-us/dotnet/articles/core/rid-catalog#what-are-rids
There is also a platform key under buildOptions listing all possible targets, but yet because of some issues (like #1624) it has no effect and it seems the system ignores that.
Related
I am trying to migrate 32-bit MS Access DB to SQL Server using SQL Server Migration Assistant (SSMA) 32-bit in my 64-bit Windows machine. The addition of Access DB to the migration project always fails due to the following error. The error message is suggesting to use 32-bit version of SSMA, which I am already using. What could be wrong?
Access Object Collector error: Database
Retrieving the COM class factory for component with CLSID {CD7791B9-43FD-42C5-AE42-8DD2811F0419} failed due to the following error: 80040154 Class not registered
(Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)). Please make sure that you are using the correct version of SQL Server Migration Assistant.
If you have 32-bit Microsoft Access installed, then you will need to use 32-bit version of the Migration Assistant.
In order to use 64-bit version of Migration Assistant, you will need to install 64-bit Microsoft Access components available at https://go.microsoft.com/fwlink/?linkid=834402.
An error occurred while loading database content
Your best course of action is to install the ACE data engine.
Installing recent verisons of Access WILL NOT WORK! Even recent runtime verisons!
Since Access 2013, an install of Access full (or runtime) does NOT install an exposed copy of ACE. Due to this confusing, they are reversing this policy, but with this confusing, and that for several years installing Access (full or runtime) would not work?
Then just go and install the ACE data engine. It is a smaller and lighter install then the Access runtime anyway.
So, use this link:
Microsoft Access Database Engine 2016 Redistributable
https://www.microsoft.com/en-us/download/details.aspx?id=54920
So just keep in mind that installing Access for the last few versions did not and does not install a exposed copy of ACE. You HAVE to install the ACE engine separate for use say from VB6, vb.net, c# or external software like SSMAA that requires a exposed copy of the ACE data engine. While Microsoft is in the process of reversing this decision (an Access full or runtime would expose ACE), the current situation is confusing, since you can try installing several versions of Access, and even runtime versions, and you will STILL NOT get a exposed copy of ACE.
Doing a quick search; do you have the proper Access Runtime installed?
Check out the link below:
https://techcommunity.microsoft.com/t5/microsoft-data-migration/access-connectivity-components-for-ssma/ba-p/391070
They suggest starting with 2016 and see if it works; if not, uninstall the runtime and try an earlier version.
I have a .NRY Standard 2.0 Project with a class library where I use the System.DataODBC (installed as Nuget Package) to connect to an Access mdb file.
I then wrote a .Net Framework 4.7.2 console app to test the library and that works as expected. I then wrote a .Net Core 3.0 console app, because the app that in the end will be using the library is a .Net Core app. But this didn't work I get this error:
ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
But I then tried to compile the solution with "x86" instead of "Any CPU" - And that works. I then think it must have something to do with the ODBC driver for 32 of 64 bit?
To be clear I haven't configured any ODBC driver with ODBC admin (odbcad32.exe). I can now run the core Console App in Visual Studio and stand-alone.
But when I put the Core Console app on another machine (a clean install Windows 10 pro in a VM) it still won't work.
What do I have to do/install in the VM machine to get it up running?
If you use mdb (the older legacy JET engine), then you can connect on any machine since a copy of the JET database is shipped with each copy of windows. And YES, you will have to force your project to x32 (x86) since the JET data engnie is only available in x32 versions.
If you use ACE, then you are using the newer ACE data engine which is require if you use the Access 2007 and later format (so for accDB files, you MUST use ACE).
Of course like any drivers or software, if you going to deploy to additional machines, then you have to ensure that ACE is installed. As a general rule, you then have to (should) install the access connectivity components. eg this one:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
Keep in mind that there are two versions of the above. A x64 bit version, and a x32 bit version. You want to continue to FORCE you .net project to x32 or x64, since you can't leave this choice to the wind.
So, you have to include the above install as part of your installer, or simply provide a copy, or have users download + install.
The only way to eliminate the need for above is to go with JET, but that may not be a possible choice for you, and you are restricted to mdb files, and can't use accDB files with JET.
Thanks for the quick answer.
But I found that to run a .Net core app using the System.Data.ODBC the app heve to be compiled for x86 CPU and the server where the app is installed needs to have the .Net Core runtime 32-bit version installed.
I've written an app which uses OLE DB, and I've encountered the error from the title. I've installed the Access Database Engine as suggested in this question and all had become work well. However, I want to distribute the app among some users to their locale machines and I have been reported such a error from the testers which do not have this util installed.
Is there any way to embed the Access Database Engine into my binary as dll or, maybe, into installer? I do not want to say "to use my app, install that util please"
if your end-user computer does not have MS office or MS Access installed, you won't be able to use the ACE.OLEDB driver UNLESS you install the basic access runtime/databse engine. However, if your end-users have 64bit windows and 32bit office, you will get the same error. To over come this issue you need to change your app target platform to x86.
if you are using visual studio, on additional way would be to add "AccessDatabaseEngine.exe" as one of your prerequisite which will be then installed along with your software.
more about custom bootstrapper:
http://msdn.microsoft.com/en-us/library/ms165429.aspx
I have developed a Microsoft Office application using Office 2013 64-bit edition.
After reading how it is still recommended for most users (even on Windows 64-bits machines)to use Office 32-bits, I came to know what I did is wrong, and my application need to run on many clients with mostly office 32-bits.
Is there anyway I can convert my MS Access file to be compatible with a 32-bit version?
If your application is not being distributed as a compiled (an accDE), and it does not use any API calls, then you should not have to change anything to run the application with x32 version of Access.
So no converting is required. Note that if you distribution a compiled version (accDE), then yes you need to re-compile your application using x32 version of Access. So incompatibility ONLY exists if you distribution a compiled application. Because users cannot modify nor change compiled applications, then Access can not re-compile on the fly when moving the application between x32 and x64 versions. When distribution an accDB standard file, then Access will detect this issue and re-compile your code without any user intervention required.
With your given information, no changes are required and an application written using x32 or x64 versions of Access will run on either system without requiring changes.
So your existing application should run just fine using the x32 version of Access. As noted the only issues are that of using compiled applications, or if your application uses any custom API calls. Such API calls can also be made compatible between x32 and x64 via conditional compile options. However, as noted, such changes are ONLY required if you using API calls.
If you are by chance using any API calls, then how to create an application that runs on both x32 and x64 is outlined here:
http://msdn.microsoft.com/en-us/library/ff700513(v=office.11).aspx
I have a .NET application which uses an accdb file (MS Access 2007 format) as its database. To install this app on another machine I need to install the Access engine on that machine. Microsoft has this file: AccessDatabaseEngine.exe which includes the engine, but when extracted during installation, runs another .msi installer.
As you can guess, since this msi is run during the installation of another msi (my app's installer) the Access engine setup fails with error 1500: "Another installation is in progress. Finish that one before continuing this one..."
I found the Runtime for Access 2007 as well, and it does install the engine, but the Runtime package is again an msi installer which means I'm still having the same problem.
Any ideas to include the engine in my app's installer?
You probably want to have a look at this article: Adding Programs to Access 2007 Deployment Packages
The Access Developer Extensions offer a basic but functional installer that can take care of the general deployment scenarios.
The best think would be to build your own msi pack including needed access files. You could use a product like VERITAS Wininstall. You have this "Discover" method that allows you to build a fully operationial .msi file by (1) taking 2 snapshots of your system (one before the installation, one after) then (2) creating the .msi file corresponding to the installation process.
Anyway, I'd advise you to have multiple packs, one for Access, that can be installed with a "for all users" option when the computer joins your company's domain, one for your app. By doing so you will be able to distribute new versions of your app without redistributing Access, which takes a few mega of space as well as a few minutes of user's most precious time).
Sio if Microsoft already delivers an Access Runtime msi package, just keep it 'as is' and distribute it automatically on your network when a new machine joins the domain.
I wouldn't recommend WinInstall, we have it in my office and we have to keep calling them in to package stuff for us as it's so finiky to use. Some things they haven't been able to package at all. WISE Studio is better or a free alternative is AppDeploy whihc I have heard great things about.
I found this software called "Bootstrapper Manifest Generator" or BMG. It helps create a prerequisite package using an MSI or EXE installer file, and adds it to VS2008 Prerequisites dialog box in Setup and Deployment projects. Although it's not that user friendly, it does the job. It's on MSDN: code.msdn.microsoft.com/bmg
Thought it's good to save others from going through all the trouble.