We Keep Coding

In-use files not updated by MSI-installer (Visual Studio Installer project)

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."

WPF application doesn't run on another computer

I created a new WPF project. I copied the built .exe file onto another computer and tried to run the application. But nothing happened. It was just loading. Nothing more.
All my WPF projects do this thing.
What am I doing wrong? Has anyone any idea?
Edit: For somebody in the future: the question might not be clear. What I meant was that I created a simple WPF application with nothing in it and tried to run the application on another computer. I wasn't able to make it run. Just nothing appeared. I figured out that the Avast Free Antivirus was causing this problem. When the antivirus is turned off, it runs as expected. Even though it is no solution, at least we know, what was causing the problem.

You are probably missing the dot net libraries on the target machine.
For quick fix, download the dot net framework distributable for the .net version you compiled against and install it on the target machine. Here is 4.5.1 for example.
For actual distribution, look at creating an installer that will ensure all dependencies are installed with the application. InstallShield has a limited edition which may be included with your edition of visual studio

Try publishing your application using click once. You can do this by right clicking on your project > Publish > Specify the location to publish your application > Finish. Copy the files inside the Published folder to another computer and try installing by click the setup.
Note: The instructions I said above only works if you only have basic functions on your app. If your application uses SQL Server, you need to install it first on the computer that you will be installing your application in.
For your reference. How to: Publish a ClickOnce Application using the Publish Wizard

Open Office automation fails when executed from Web Service

I'm using this guide as a basis for what I'm doing:
http://www.codeproject.com/KB/files/generatepdf.aspx?fid=1517061&select=2903150&fr=1#xx2903150xx
I am using the Open Office CLI bridge to try to create an ASP Generic Handler that will download a file from an MS SQL database, convert it to a PDF, and send it back to the browser or app that requested it.
Here's what I've tried:
The Service shown in that article (including adding the OO.org 3 fixes).
Moving the relevant code directly into the Web Service and Switched IIS to run the 32bit .Net runtime (required for OO.org).
Creating a command line tool that performs the conversion and then spawning a process that runs the tool and waits for the Exit code (0 = success, 100 = failure a, 200 = failure b, so on and so forth)
So far all of these work when debugging the code using the development ASP server that Visual Studio provides. What doesn't work is deploying it to my development server and trying to run it there. I can get processes to run no problem, including OpenOffice's soffice.exe and soffice.bin, but under none of those circumstances does the conversion actually occur. I've tried giving the IIS service the ability to interact with the shell and trying to run the process under my own credentials (works under VS's ASP.net server but not on my dev server) but neither was fruitful.
This has been rather frustrating to be so close yet so... far. Any help figuring this one out would be appreciated. My guess is there's some IIS/ASP.net configuration option that I'm missing. My development and production environments use VS2008 and IIS6 under Windows XP 64bit.
Thanks,
Max

Have you actually installed OpenOffice on your production machine. I know that sounds big, but I have had a similar issue when dealing with MS Office. Regardless of whether I copied the appropriate files across they weren't registered.
Hence installing MS Office solved the issue. However I am sure if you register the appropriate files it would work as well. Maybe as a quick test deploy it on a machine without Open Office installed and see if it works, then install Open Office and see if

Creating a "sure to run" app / installer in VS2010

I need to create a simple installer of sorts for a different application. That other application already has it's own simplistic installer, and I don't want to meddle with it.
The reason for my own installer is to allow the user to install SQL Express if (s)he so chooses, and also to pre-install any other basic requirements for such a procedure.
At the moment, here's where I'm at:
I've created a single Windows form application, with big buttons (this is for a user which likely won't be very good with computers) to install SQL Server Express (using silent install with a predefined set of arguments) or the actual application, along with some helpful text to let the user know what's going on. Something along the lines of Visual Studio autorun window.
I've also added the standard set of pre-requirements to the application (.NET, Windows Installer).
Everything works OK if I run the app by using the executable. HOWEVER, if I publish it to create a ClickOnce application (so the pre-requisites are installed when needed) and run it, it stops running other installers.
EDIT: Apparently the problem with not being able to run other application from a ClickOnce application is only on my end, and probably deserves a new question, not necessarily here on StackOverflow (perhaps on MSDN forums?).

In your program before launching the installer you can check if .NET is installed. Its pretty easy to check if a particular s/w or a version of s/w is installed. Write a program that will check HKEY/LocalMachine/Microsoft/Windows/CurrentVersion/Uninstall and in that there will be list of programs that have been installed on that machine. If you find then go ahead with your install else suggest user that he needs to install pre req.
When you create a setup project you can right click on the setup project, go to properties, and click on pre requisites. In that you can mention which version of .NET framework is needed and then give the location of the framework. In this link look for Huggy Bears response eggheadcafe.com/community/aspnet/2/10131905/setup-project.aspx

I've settled for a "Click Once" application. It can install all required .NET components needed for it to run, thus becoming an "sure-to-run-non-native-C++-code-splash-screen".
Granted, there ARE issues with Click Once, but this is far better than nothing. It's also better than running C++ or unmanaged code applications. ;)

ClickOnce, my app crashes Visual C# Express

I'm finishing up a C# app for work, and looking to make a ClickOnce installer.
Right now, I just want to make sure the installer works and that I am able to run the exe without Visual Studio.
So I set up my project to require Windows Installer and .NET 3.5 SP1, and tell it to download from a vendor (I'll be including the components later, but not for this test). It's just a basic utility that won't need updates, so I disable updates and tell it to use a CD/DVD install method since I just want to run it locally. When I run the resultant setup.exe, I get the installation prompt, and MyApp appears in Add/Remove Programs. But, as soon as the installer finishes it crashes with this message:
[MyApp] has encountered a problem and
needs to close. We are sorry for the
inconvenience.
The same message pops up when you try to run the .exe. No Start Menu folders are created during installation. I tried doing away with creating the setup file altogether so it just generated the .application file, but I still got the same error.
Am I missing something obvious? My app compiles in Release configuration and runs just fine. Is ClickOnce just not supposed to work with regular WinForms applications?
This question:
WPF application crash after ClickOnce publish
Sounds similar to my issue, but I'm using Windows Forms, and thus not getting an XAML exception. It just refuses to run.

A good place to start is to add a handler for the AppDomain.UnhandledException event. This is the event which is raised when an exception occurs inside your code and is not handled by a try/catch block (or is re-thrown and never handled again). .NET's behavior in this condition is to close the application--from it's perspective there is a runaway error.
In this event handler, you should--at a minimum--log the error in a manner that ensures it will be written before the application closes. This could be a very rudementary MessageBox to show the error contents, writing to a text-file, or (preferably) writting to a common logging location.