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.
Related
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'm trying to use WCF Data Services and a little confused what library should I reference to interact with WCF Data Services: Microsoft.Data.Services.Client.dll or System.Data.Services.Client.dll.
What is the difference between them? In which case should I use each of them?
When trying to add references to both of them I get a compiler error:
The type
'System.Data.Services.Client.DataServiceContext'
exists in both 'e:\Program Files\WCF
Data Services Mar 2011
CTP2\bin.NETFramework\Microsoft.Data.Services.Client.dll'
and 'e:\Program Files\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Data.Services.Client.dll'
System.Data.Services.Client.dll is part of the base framework that ships with .NET 3.5 and upwards. The Microsoft.Data.Services.Client.dll is an updated version of this library (from your directory paths I see you're using the March 2011 CTP) which is not yet part of the base .NET installation package and contains any new features since the base release.
So if you're looking to use some of the latest features include the Microsoft dll. If you're just after base functionality (that will be 100% supported by anything with the proper .NET framework installed) use the System dll.
Here's a blog article outlining the difference between the Microsoft and System namespaces:
http://blogs.msdn.com/b/brada/archive/2008/11/16/what-does-that-net-namespace-mean-system-and-microsoft.aspx
If you do need to use system.data.services and system.data.services.client, make sure to explicitly remove the microsoft variants i.e. right-clicking references -> right click and remove the microsoft ones.
I developed Vb.net project.
My project name is Lone.
My front-end is Vb.net Backend is Ms Access.
I completed my project.
Now I copy the Lone.exe and put shortcut into my system desktop.
Now I want to run that Lone.exe to all system.
I don’t no how to share that one.
Tell me how I want to run my project to all system.
Note: In my system only having Vb.net.
Remaining systems doesn’t installed vb.net.
You have to install the correct version of the .Net framework on all 6 systems, you don't need the whole VB.Net development environment, just the framework. This might already have been installed using Windows Update or similar, so this step might not be needed.
Just try googling download .net framework x.x where x.x is the version you need and you should find a link to download the correct version from Microsoft if needed.
After that just copy that executable to each system and run it.
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.
I have a VB.NET 2.0 project developed using VS2005 Free Edition and I am considering to upgrade it to VS2008 FE, mainly because I have problems once per year, whenever my Temporary Certificate expires.
I was wondering if you can point to some resources describing in what parts of the code I should pay attention after the upgrade. My project uses only two external components (zipforge and objectlistview) and I am not using any databases, in case this information is of any use to your answers.
Try to open your project in VS2008, the wizard will ask you whether you want to convert your project, you hit yes, then point - to create backup, and show log after conversion.
At the end wizard will show you conversion results. If any error will occur, you'll be able to clearly see its location.
then it will be up to you if you want to upgrade project to .NET 3.5 version, but if no - fine, VS 2008 has .NET 2.0 support as well.
If you want to stick with the .NET 2.0 framework once you upgrade to 2008, click on My Project in the Solution Explorer, select the Compile tab, Advanced Complile Options button, Target Framework drop down box. If you don't do this, the project defaults to using the latest framework, 3.5, which could cause problems when you deploy upgraded exes if you inadvertantly start using 3.5 only features and your target PCs don't have 3.5 installed. Changing this option before you start making changes to your source prevents you using 3.5 only features.