I've followed this post and it's not working. Can someone tell me what else to check?
Steps I followed:
I added dll's from my current install of Oracle (11gR2_x32) to the root of my project. I did not use the basic-lite as the post stated but I assumed that the dll's would be the same, right?
oci.dll
ociw32.dll
Oracle.DataAccess.DLL
orannzsbb11.dll
oraocci11.dll
oraociicus11.dll
OraOps11w.dll
Selected each dll within my project and set the 'Build Action' to 'Content' and 'Copy to Output Directory' to 'Copy Always'
Added a reference to Oracle.DataAccess
Added 'Imports Oracle.DataAccess.Client' to my vb code.
The code works fine but it still requires the user to install Oracle. My intent was to not have them install oracle. I verified that when they install my program all the dll's are present in the program folder.
What else can I check?
The code works fine but it still requires the user to install Oracle. My intent was to not have them install oracle.
To my knowledge, there is no truly "embedded" Oracle and you cannot avoid installing the Oracle database server. If you really need an embedded database, there are several good alternatives, including but not limited to: SQLite, MS SQL Server Compact or LocalDB1, Interbase/Firebird etc...
Few years back, Oracle ran a licensing program for companies, where you could integrate the Oracle setup into your own setup and make it "invisible" to users, but this would still install the full Oracle server. That's how earlier versions of PTC Pro/INTRALINK installed for example - you didn't need a separate Oracle installation. I don't know whether this licensing program is still available, but even if it were, you are probably looking at a very significant financial investment.
BTW, Fully Managed .NET provider for Oracle is currently in beta - this will ease the client deployment even further and eliminate 32-bit vs 64-bit mismatches.
1 LocalDB is not technically "embedded" as in "in-process", but that probably won't make a difference to your end users.
Related
My ultimate goal here is to install the correct SQLite package in Visual Studio 2019 on a Windows 7 SP 1 64 bit
The project is a WinForms app and I might try UWP apps
It seems the NuGet Ice Cream Store has a lot of flavors of SQLite
System.Data.SQLite 1.0.113.1
The official SQLite database engine for both x86 and x64 along with the ADO.NET provider.
This package includes support for LINQ and Entity Framework 6.
System.Data.SQLite.Core 1.0.113.1
The official SQLite database engine for both x86 and x64 along with the ADO.NET provider.
sqlite 3.13.0
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. This package contains native libraries for SQLite on Linux, macOS, and Windows (desktop and Universal Windows apps).
The Last option here seemed like the correct and logical choice then I looked at this SO Post
SO LINK
After 3 days of reading and searching I have given up hence the confusion has won
While I stated my ultimate goal above can I also assume NuGet will put the SQLite package in the project Reference Folder
The question is I want to have a self contained EXE project once packaged
The last one was last updated almost 4 years ago, so clearly not the right option. That was from before Microsoft embraced SQLite as it's recommended file-based database system. Microsoft used to provide its own SQL Server CE but presumably decided that there was no point trying to compete withy SQLite as it already did what .NET developers needed. Notice that the new options start with System.Data, which is generally reserved for Microsoft's own types.
As for the other two, if you check the dependencies for each you will see that the first has a dependency on the second. As the descriptions say, they are both the official SQLite database engine and ADO.NET provider but, unlike the Core package, the first adds support for LINQ and EF6. Do you want that support? That is what determines which package to add.
If you don't know which you need then you can just add the Core package for now and add the other later if you need it. Also be aware that NuGet packages are added on a per-project basis. Even within the same solution, projects can have different packages added. You should/will add just the packages needed for each project you create.
Working in Visual Studio 2015, I have a VB app that I need to deploy to multiple clients. The app works ok as long as I'm deploying to a machine with the exact same version of the Oracle.DataAccess.dll as it was developed with. But the machines I need to deploy to have varying versions of the Oracle Client. Is there any way to make the application work for different versions of the Oracle Client?
The answer is to use client-less Oracle connection. Refer to this article. Or how about client-less nuget package Oracle.ManagedDataAccess?
the problem with oracle is that a specific client wouldn't work with Oracle.Dataaccess.dll that has different version. Sometimes version might be just a bit different, like client 1.2.0.206 and it wouldn't work with 1.2.0.212.
You can also try not to distribute the dll because, I believe that Oracle client installs odp.net folder where there is DLL that matches that client and it is registered in GAC. But the problem can be that dll you used for dev is of higher version. You can try to tweak app.config to set version range for this dll. Read about redirecting assembly version.
But after all, best is to deploy your app as atomic unit with client-less Oracle connectivity. Even if you use version redirection successfully, the functionality in one dll may differ from another and your results may not match your dev environment.
I have a project done in VB.NET and I want to publish it for distribution. I know that when I build solution It creates an .Exe. But that requires local resorouces. If I build for release I know it works but it still needs the .Net platform installed. Is there anyway to make a true standalone .exe or something that would run on a persons computer if they do not have .NET installed. Also the ClickOnce application thing is not a wanted Solution.
Is there any converter program that can do this for me?
The .NET framework represents the basic prerequisite to run a .NET program; equivalently than having Windows installed is the prerequisite to run a Windows program. Bear in mind that any Windows version includes the .NET framework (and, actually, it tends to involve top-priority updates and thus are automatically perfomed by Windows Update in many cases). A big proportion of the programs running on Windows created during the last 10 years are built on the .NET framework; a relevant proportion of the sites (like this one, for instance) are built on ASP.NET and thus the given server has to include the .NET framework. If overall compatility is a concern for you, you might rely on a-bit-old .NET version: the latest one in VS 2010 (4.0) should be fine for most of modern computers; but you can even rely on the previous one (3.5) to be completely sure. Lastly, bear in mind that a .NET program can also be run under a OS other than Windows (Linux or MacOS, for example); although, from my past experiences, these are not too reliable situations. Nonetheless, in case of being interested in other OS, you should do some research/testing on this front to see if the available options offer what you are looking for.
SUMMARY: the exe file generated by the Visual Studio is actually what you call "standalone .exe". One of its defining features is the .NET version (which can be changed in the Project Settings); a program can only be run on computers with a .NET framework (or equivalent) equal or newer than the one on which it was built. The 4.0 version should be OK for most of new/properly-updated computers; the 3.5 .NET would work with virtually any computer (although, logically, it includes less features than the 4.0 one).
---------------------------- UPDATE AFTER COMMENTS --------------------
From some comments, I have undertood that my statement wasn't as clear as I thought and this is the reason for this update
.NET is pre-installed in Windows only since Vista. XP does not include the .NET runtime by default. The reason for not having mentioned this issue in my answer was that having a XP Windows without .NET is highly unlikely. Firstly because this is a top-priority, automatic update and thus one of the first times the computer is connected to internet "Windows Update" will take care of this. And secondly because this is the basic framework for any Microsoft programming over the last 10 years and thus a Windows computer not having it will not be able to run almost anything. With this last sentence, I don't mind that most of the programs are built on .NET, but that for a Windows-based environment most of nowadays basic requirements do include .NET.
It was also pointed out that there is some compatibility problems between different .NET versions (that various side-by-side versions were required). The basic Microsoft approach to the different .NET versions is backwards compatibility, what means that a given .NET version can run any program built with that version or older. This is theoretically right, but not always right in fact. My approach to this problem is relying on a bit old .NET version (3.5) and not using too new/untested features (e.g., WPF). If you want a for-sure overall compatible program you should work quite a lot on this front (compatibility between versions is one of most typical problem of any programming platform), instead expecting Microsoft to take care of everything. Thus, in principle, just one .NET version (the last one) has to be installed (which, on the other hand, is not the case for a big proportion of computers; for example: computer including the 3.5 version being updated, over the years, to 4.0 and 4.5 by maintaining the previous versions).
Lastly, I want to highlight that my intention with this answer is not defending any programming approach over any other one; I am just describing what is there from the point of view of your question "can I remove the .NET part?" -> no, you cannot; there is no (sensible) way to do that. If you want to rely on a different programming platform you should get informed about it (I am sure that Camilo Martin will be more than happy to help you on this front). If you prefer to rely on .NET, be sure that you can generate an overall compatible program (to be run on Windows).
Easy way to convert in .exe in VB.NET-2010:
Create New Project
Select Windows Application And Save Proper Path
Comple Project then Select File-> Save All
Select Build->Start Build
Your Project .exe Created Your Project Save Path:
Select Windows Application 1
Select bin Folder
Select Debug Folder
And in Debug folder your .exe File is ready.
Quick Basic once made and executable (.exe) directly form their VB code, but I wouldn't recommend converting to Quick Basic. You can look at Mono to see if they have anything yet. (mono allows you to use compiled vb.net in other operating systems).
Ezirit Reactor makes a single executable, but it's not free.
You can bundle .NET Framework into your distribution so that users don't have download it.
Why do you need an executable (.exe)? If the reason is for security and to minimize chances of reverse engineering, then get a good obfuscator.
I am using a custom dll with SSRS. After deployment, I may need to update my custom dll with a newer version. Will my reports continue to work?
If the reports do not work with the new version of the dll, how can I get my reports to work with the newer version of the dll?
Short answer is yes, at least in my experience. I've done this successfully in the past - just replace the relevant custom DLL on the server with the updated version. I didn't have to make any changes to the reports using the DLL.
One caveat here - when I was replacing a DLL in situ I would make sure the version number of the DLL was the same; since the report stores the DLL version number this meant as far as the reports were concerned they were still getting the same DLL.
So if you're incrementing version numbers when building your DLL this might not work. As per the comment from #Gil Peretz just test it out in a non-production environment and see what happens.
I have developed a s/w using acces and sqlserver 2008 and now trying to make a setup file.
How could be the possible way??
I tried in VS2008 software and development. But after installing from the msi file and running the s/w it shows an error
"Microsoft.ACE.OLEDB.12.0 provider is not registered”
plz help
You have to do a few things to set up your application:
Install the .NET framework if required
Install SQL Server 2008 if required
Install your application
Define/configure the connection from your application to the SQL Server instance
Create your database/schema in the SQL Server instance.
Ignore the SQL Server problem for a moment, the easiest way to deal with the .NET framework and installing the application would be to use a setup project - which should be available from within VS.NET under Other Project Types|Setup and Deployment. There are hooks in there to give you options for installing dependencies - of which the .NET framework is one.
Ok, you have a tool to create setups (there are several others, e.g. I'm currently using WiX which I like so far, is very capable but can rapidly becomes complex) - the problem now is that the installer you need to build will depend on how and where your application is to be deployed. Do you want to ship a complete, self-contained, application on a disc? Is it to be downloaded internally within a business or distributed over the internet - each of these suggests a different set of packages at one end "everything" at the other you want the smallest possible pieces pulled down as required or perhaps even a different packaging method (e.g. clickonce).
Next up is SQL Server. You can get a redistributable package for SQL Server 2008 Express, so distributing it is not a problem however you have to determine if the user has an existing instance they want to user or if they want to install.
Once you've got an installed instance - you need to be able to create and to maintain (update) the database/schema within that instance. That I suggest you do using code (see here: How to create "embedded" SQL 2008 database file if it doesn't exist?). Which brings us to another point, you not only have to be able to install the application the first time, but you need to make sure that a) you provide a means to uninstall the application and b) that you can neatly do an upgrade in place.
I hope there are enough pointers there to get you moving - in terms of testing this, Virtual Machines are your friend, they give you the capability to create multiple environments in which to test your deployment and the ability to quickly roll back to a clean environment to test again as its virtually impossible to properly test an installer on a dev box (I've found this out the hard way) as it will already have all the dependencies for your application installed.
Pick your tools and that should let you ask more focused questions.