publishing app in vb.net - vb.net

when i publish an app in vb.net it creates some files:
application files directory, app.application, and setup.exe
i am going to be distributing this application to people who can barely use a computer, so i need to bundle everything in one, self-extractable package.
how can i do this?

I think your best choice would be to use Click Once Deployment. All your user have to do is to click on a link and the application gets installed. Moreover its easy for you to send updates too.
HTH

Related

How to disable local data cache in Windows Form?

I have a vb.net Windows Form that is launched from the .application file - no installing done. I have an issue on some users' machines where they can't launch the application unless they go into their C:\Users\%userprofile%\local settings\apps\ folder and delete folder "2.0".
How can I prevent the application from using/creating that cache? All user settings are stored server-side and pulled down on open.
I've found AN answer, maybe not the best, but it works.
Turns out, ClickOnce is the problem. I haven't been able to figure out how to deploy without it, however it can be bypassed. Within the deployment folder, you've got an Application Files folder, and a [Project Name]_[version] folder. Within that is the .exe for your application, within the ClickOnce wrapper.
If your application, like mine, doesn't use non built-in controls, you don't actually need ClickOnce, as far as I can tell. So having users run that .exe, rather than the .application file within the deployment folder will prevent the "2.0" cache folder, as well as preventing the ClickOnce install and loading form - resulting in a faster open.
Hope that helps someone.

Application works without installation

I created a program in vb.net in vb language. After that I created an installer (.msi) for the same in Advanced Installer program. I installed it on the computer and everything seems professional.
I copied the folder that contains the program and all its dependees and sent to to a different computer. I was surprised that the application (.exe) file works without installation!!
How can I make my application works only with installation?
Appreciate the help.
Advanced Installer has a licensing module that works for VB.NET apps too, which you can easily integrate into your installer.
However, this is in the Enterprise edition, and I assume you are using the free edition, as this sounds like quite a simple application/installer.
In this case you can try looking for an alternative OSS solution for a licensing/trial library.
Basically with this library every user that needs to use the software will need a key to activate it, so even if they copy the folder with the application files from Programs Folder, they will still not be able to run your app.

Publish vs. Release

I created a simple application in VB.net in Visual Studio 2013.
It's not a website or a web app, it's just a simple Calculator, I think I created it as a Windows Forms Application.
When I build the application in release mode, it builds and runs properly.
It puts the executable it built in: Documents\Visual Studio 2013\Projects\DataCalculator\DataCalculator\bin\Release
I can just send that executable alone to someone and the program works fine. So what is the purpose of all the other files?
Furthermore, there is a Publish button in the Build menu of VS2013. What does publishing the program do that the the release doesn't?
Also, when I click the publish button it asks me how the user will install the application. What if I don't want them to install it, I just want it to run from a simple click of the executable. So what is the purpose of publishing?
If by "all the other files" you mean .application, .manifest, .pdb, etc., they all have uses in various contexts. If your calculator is stand-alone, then it will only require the .NET Framework version you used to create it installed and the .exe itself.
I have used the Publish feature a few times - at a previous company - it's useful for 'transparent updates' to users. For example, the tools I created were published to a shared drive on the server along with the associated "other files". The users then installed the tool from the shared drive by clicking on the setup/install version, which creates a shortcut on their start menu/desktop/wherever. The beauty of this particular method, is that you can configure the application to automatically update when it is run; so I continuously improved the tools and every time a user ran one, it copied the newer exe to their PC and ran that, without any further updates/reinstalls from their perspective.
It worked quite well for small engineering tools, but I'm sure with larger/more complex applications with databases and backward-compatibility to worry about, it could cause headaches in many situations.
Release will only create an .EXE Application file which is executable in supported platforms, but database must be separately copied . where as publish will create a setup file along with database and the sub folders inside the project folder. It helps you to install your application in any computer which meets the requirements.
Click to refer Advantages and procedure for publish http://msdn.microsoft.com/en-us/library/vstudio/ms233806(v=vs.100).aspx

I am looking for information to make my windows form app self updating

I would like to make my windows form app self updating when it starts. Where can I find good information for that?
I am using Visual Studio 2008 VB.NET.
I like the click once approach. With this application I have an access db as the backend datastore. When the application self updates how can I be sure the mdb file is not overwritten?
What is the best way to self upgrade the mdb if their is a change to the mdb file but not loose the data?
If you deploy using ClickOnce, you get this functionality for free. I do not have any experience with this (yet), but I can point you to an article.
I have been using Click Once for years with very little problems.
I've written a custom automatic updater and basically, the way it works is this:
The whole application is essentially 3 parts:
A launcher .exe that's essentially like a bootstrapper
The launcher .exe has an embedded .exe resource that is used if the launcher .exe itself needs to be updated
The application dll's
When you start the application, the launcher app starts and checks via webservices if the dll's are up to date. If they are not, it downloads them to a temporary directory and then makes sure the checksums are all correct and overwrites the existing app libraries with the new ones. It's then loading the application's core assembly and calls a "Run" method via reflection.
Now, in our app we sometimes have the need to update the launcher itself and the way we achieved this is by embedding an .exe in the launcher .exe resources. If the launcher detects that there is a new launcher .exe available, it downloads it to a temp directory, then extracts the .exe and launches it. This extracted .exe simply shuts down the launcher process, copies the new launcher .exe over the old one and then starts the launcher process again.

Why Setupper created by Publish feature does not copy files to c:/PROGRAM FILES

I have VB project and I tried to use PUBLISH feature.
It seems to create nicely some kind of setup program, but the setup program does not ask where to copy files (it does not seem to copy filesto target machine "PROGRAM FILES".)
Is this setup program somehow different from usual installers?
NOTE: I want that app files are installed to Hard disk( from USB stick source)
Is the signing recommended or necessary? My App is pretty simple, its just using access DB + printer api, should I still sign?
The "Publish" feature creates a ClickOnce installer. Such applications are installed per-user instead of per-machine, i.e., they are installed somewhere into the user's profile. This is by design and has the advantage that the user installing the software does not need administrative privileges on the machine.
You can also create a setup project by going to File/New/Project/Other Project Types/Setup and Deployment/Setup Project. This creates a "conventional" MSI-based installer, offering the "classic" C:\Program Files type of installation.
On MSDN, two approaches are compared here.
Our biggest problem in-house is privleges.Does the "user" have access to write to "Program Files"?