I've just tried ClickOnce for the first time to deploy my SQL Server Compact application. I think this kind of deployment is very unprofessional:
The output setup is a folder including 3 objects, one folder named Application Files, a setup.exe and a .application file which I've never seen in a professional product setup package.
Plus, clicking setup.exe seems to help user install the application so quickly but user has no chance to select what location s/he wants to install the application. It's installed by default at somewhere in the target computer. And even I tried looking for its location after the installation, I couldn't find it.
The last, after the installation, there is a folder named "Microsoft" in All programs menu, and the installed application shortcut is located in there. I wonder why it is always Microsoft? I even tried editing my Company info in Assembly info through Project Properties window. The application shortcut is something strange when I can't find its target executable file in its properties window.
With all the above ClickOnce can bring to me, I consider it as a funny job for testing the application only not for publishing a commercial application.
Could you please correct me if there is any wrong in #1, #2, #3 and please give me a better solution for deployment, I'm interested in SQL server (service-based and file-based) application only?
Your help would be highly appreciated. Thanks.
A ClickOnce install is a per user "sandboxed" install, not a normal install you think about when installing normal applications. The .application file is used by the server as a manifest and to determine if it needs to update the install when clicked.
The reason you can't find setup.exe is because it isn't there. Once the files are installed, it isn't kept. The user isn't supposed to know where the files are, the system manages the location and updating of the app.
So, with all that, it appears you need a more normal install, not a ClickOnce. ClickOnce isn't intended to install services or other per machine files.
Related
I'm using the Visual Studio Installer Projects extension to build the MSI-installer for my application. However, my application is meant to be running at all times, and if it's open when the user is installing a new version of my software, the open files are not overwritten, and very little to nothing is actually updated (although there are no installer-errors).
I've found that using the installer project's "Custom Actions" to run a script that closes the application doesn't help, as none of the actions are called before the files are replaced.
Is there a good way to make sure the open/locked files gets terminated before the files are supposed to be overwritten?
We had this problem, and the solution we came up with was to create two apps; the user app and an updater app. The MSI installs both. Each app checks if the other needs updating and, if it does, closes the other app, downloads the other app's updater, runs it, then relaunches the other app. Additionally, each app monitors if the other app is running and, if it isn't, launches it.
It would be useful to know more about your application and how you are doing the upgrade because:
You will normally see a FilesInUse dialog saying that files are in use, prompting the user to shut them down, but not if the install is silent.
Visual Studio setups have no built-in support for shutting down and restarting services, so if your app is a service you'll need extra work.
Files that actually do need to be replaced will prompt the user for a reboot (if they are not previously shut down) in order to replace them at reboot time.
So if you're not seeing reboot requests or FilesInUse dialogs in a UI install then something else is going on. So you need to be sure that:
a. You are really doing an upgrade where the version of the setup project has been incremented, the UpgradeCode is the same (and the ProductCode changes when you increment the setup project's version). Your symptoms could be the result of the upgrade not working and you're seeing just a repair.
b. The definition of "new version" is that you have an upgrade as in a., AND, the file versions of the binaries have been incremented. The default overwrite rules for installs require incremented file versions, so if they haven't been incremented you'll see no updates, and Windows will not attempt to show FilesInUse dialogs or reboot because there are no files that need replacing.
This isn't a solution to the problem, but rather another solution; the one requiring the least work in the end.
I ended up not using 'Visual Studio Installer Projects' for my installer. Instead I looked to Advanced Installer, which just works with no issues. Things like this is taken into account, and custom actions allow for more options.
If your project is open source, you can write to them about a free open source "professional" license, equal to their "professional" plan, which is normally $399 (onetime purchase).
REBOOT: How are you installing this MSI? What command line? If you set REBOOT=ReallySuppress on the command line, you will not be prompted for a reboot even if one is required to complete the installation of the product.
msiexec.exe /i MySetup.msi /QN REBOOT=ReallySuppress
If you are using a distribution system I suppose suppressing reboot prompts could be standard behavior. Then your product files should be put in place after a reboot (PendingFileRenameOperations or perhaps some newer mechanism).
It is also possible that Visual Studio Installer Projects do something strange that I am not aware of.
Log: I would try to create a good log file for the install, to determine what is going on:
msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log
Log All MSIs: Personally I like to enable logging for all MSI installations - as described in the "Globally for all setups on a machine" section in the above link.
Interpreting an MSI log: interpreting a log file can be challenging sometimes. Here is an answer with some links to help with this.
Reboot Manager: Reboot management is a very complex topic, and Windows features functionality - in the form of the restart manager feature - to try to minimize the need for reboots, by instead shutting down and restarting applications as part of an installation in an "auto-magical" fashion (application listens for messages and shuts itself down gracefully when told to, and the system may restart the application after the install - if configured to do so).
Updating your application to comply with the restart manager is the only real fix for such problems that you see, in my opinon.
The section "Restart Manager" in this question tries to summarize how to implement such support (maybe just read the yellow section a bit down the page).
The Advanced Installer guys have a very nice, technical article about this:
How do I add support for Windows Restart Manager to my application? Also linked to in the link directly above - still worth a direct link here I think.
According to below link
https://social.msdn.microsoft.com/Forums/windows/en-US/0b40b367-3341-43d8-b82e-1ace546969f8/how-can-installation-stop-and-restart-existing-service-?forum=winformssetup
"There is no good support in VS installs to stop and start services. During install, the issue is that custom actions run after everything is installed so it's too late to stop a service that you are upgrading or replacing. Yes, they have names like "BeforeInstall" but they really are not before the install."
I am trying to use ClickOnce to automatically update a C# software.
I can publish my application, the setup.exe is created, but when I download/run it, windows tells me that application can be dangerous, the publisher cannot be verified. And if I choose to run it anyway, or as administrator, the install dialog sometimes appear after 10 min but in general nothing happen.
I tried to find a way to make my application trustful but even if :
I enable ClickOnce security settings
Select "This is a full trust application" in "Security"
Add a certificate in "Signing"
It is still not working, so I have no more idea about how to fix this.
I can install it with the ".application" file but I think that is not the correct way to do it.
Thanks by advance !
You are pretty close. Much of the slowness is probably because of anti-virus. Signing it will make things better. The client machines will complain about how trustworthy the app is, unless you install your key (the one used for signing) on each of their machines.
Installing with the ".application" is just fine, especially if you are installing from a network share (instead of a web site or intranet site). That should put an app (icon) in the users' start menu.
I'm a web developer building my first production grade console application (C# .NET 4.0). I have a question about creating a settings file that the user can edit before running the console app (to customize output folder paths, etc).
I'm a little confused -- when I publish my console application and install it (by clicking on on the generated setup.exe file in my target publish folder), all I get is an entry to my start menu. Nothing gets installed to C:\Windows\Programs, and there doesn't seem to be anywhere else on my system that files get installed to. Essentially, I'm just trying to find the app.config xml file so that I can edit it after the program has been installed. (btw, when I click on the start menu entry, the program executes properly).
Is what I'm trying to do possible?
For a clickonce deployment, the files will be installed under the profile of the user who installed the application (by default).
For windows XP this should be:
C:\Documents and Settings\username\LocalSettings\Apps...
For Windows 7 (and Vista?) this should be:
C:\users\username\AppData\Local\Apps...
An installation program for your software is a separate piece of software.
You can definitely make one but when you compile your console app it doesn't create an installation executable. It just makes it's own executable. You can copy that executable alone and run it. If you need more resources to go along with it and therefore decide you want an installation program, you have lots of options.
The two that spring to mind in this case though, are setting your project to use "ClickOnce" from the project properties, or adding a "Setup and Deployment" project to your solution from the "Other project types" section of the add project dialog box.
VS 2008 SP1
I have created a application that I have installed on the user computer. However, I want the application to be self-updating. But I am not sure if this would really update the application.
The application will download all the files from the web server, and replace the files in the directory where the program as been installed to. The user will restart the application.
I am just want to be sure, because I can't replace the installed files with the updated ones. As the application will be running. So really the application cannot delete/replace itself.
So, I was thinking that I could download into another directory, if the program is installed in this directory 'program files/application/1.0.0' then I could download the files to 'program files/application/1.0.1'.
However, when the program restarts, how can it know that it has to execute from the 1.0.1 directory?
I can't use clickonce or the updater block for this.
Many thanks for any advice,
A good option is to make an independant Updater application.
The updater will download the newest version and kill/replace the old.
I think this is the best option, because you can execute the updater within the main appication (so you can say that it´s self-updating), or directly by the user with a shortcut.
The updater can check if the application is running and ask the user to exit the application or kill it by itself.
Forgive my english...
Good luck
All of that is already done for you if you use ClickOnce deployment (Project properties, Publish).
You can wrap the application with a small loader program which will do a version check. If it's out of date, download the newer binaries and overwrite the old ones. If you want to maintain all version you might end up with:
c:\program files\mycompany\myapp\loader (the newer version will point to the latest directory)
c:\program files\mycompany\myapp\v1.0
c:\program files\mycompany\myapp\v1.1
If it's on a LAN, you might be able afford the bandwidth of just re-downloading the binaries on start up instead.
Use Windows Installer for the installation and updating. If you sign your installation packages the user can update your application without needing any administrator privileges.
I've made a website and an application that demonstrates the functionality of what you want on my website.
Wix Clickthrough might meet your needs: http://wix.sourceforge.net/clickthrough.html
I would look into ClickOnce. It can be configured multiple ways, to check for updates before the application runs, to download from the server each time it's run, or check for updates after the application has started.
I have done ClickOnce Deployment and an independent updating application, they both work well. You obviously will have more flexibility over an updating application that you create yourself, however tho, ClickOnce can also be configured to install prerequisites such as the .NET Framework, Windows Installer, etc... for your application to run.
How can I deploy a C# Visual Studio 2005 project so that I can run the application in another system? My project has a few dependencies and files that have to be integrated while deploying the project.
What is the best way to handle this?
You need to know what dependencies you have.
you need to have .Net framework installed
you have to explicitly install all dependencies that you used from the GAC on your target machine (some 3rd party components)
and then you just need to copy files from your \bin\Release folder
install all services, etc. if you have any
In the simplest cases only copying files should be enough.
Have you looked into ClickOnce deployment?
It's far from perfect, but for projects without a huge amount of overhead, it's generally good enough.
What kind of project?
Assuming it's a regular winforms application, just copy everything from either the obj\debug or obj\release directory to the new computer. Then run your executable
You can right click on the project file in visual studio and publish to a different location. This will build the site and copy it to the specified directory.
Also, if you need to do anything extra during the build, you can specify custom build actions on the build tab of the project's properties.
EDIT: now that I see you added that it's a windows application my answer doesn't matter. I'd try adding a setup and deployment project in visual studio to handle installing/deploying your windows application.
You more or less have three options (maybe 4?) as I see it.
Windows Installer
ClickOnce
Just distribute
the exe itself
In your particular case I would suggest ClickOnce as long as the project is not massive with too many dependencies.
For other alternatives.
The right answer depends on many criteria.
The simplest way to deploy is by copying files. Just put your .exe, the dependent .dll's, and the .config file in a directory and copy it onto the target machine. It's simple, but there are many restrictions to this approach:
It assumes that the target machine has the right version of the .NET framework installed
It assumes a certain technical competence on the part of the person installing the software.
The installation won't do basic things like create start menu items.
Publishing the program for ClickOnce deployment addresses a lot of these issues, but it's got its own set of limitations. I haven't used it much, so there are probably more than these, though these alone are pretty significant:
Programs are installed into the ClickOnce cache, not the Program Files directory.
If your program does anything outside of the ClickOnce sandbox, you have to deal with security elevation and code signing.
You can create a VS Setup and Deployment project and build an .msi file to install the program. The most obvious drawback to this is that it's complicated: .msi files can do many, many things, and the Setup and Deployment object model is complex, with documentation that is, let us say, fanciful. But there are things you can do with .msi installation that you can't readily do with other approaches, including (and certainly not limited to):
Cleanly uninstall the program through Add/Remove Programs.
Provide an actual UI for installation that lets the user decide where to put the program.
Support scripted installation via MSIEXEC.
Install components besides the program, e.g. databases, COM objects, etc.
Put components in the target machine's GAC.