We have a .NET application that we distribute to our users via an MSI installer package. We have C++ applications that run each morning to see if the user's copy of the application is out of date, and if so, we pull down the new MSI and install it. If the application is running, we need to take it down so we can perform the update.
Our problem is that every once in a while it seems like windows "loses" our application. It will not report that the process is running - though it is. It will allow us to overwrite, or even delete, the in-use executable file without taking down the application.
Maybe this is something that is common -- but we can't figure out what is going on! Does anyone have any insight into this situation?
It seems like a temporary copy of our application is getting created, and the program is getting ran from that. But if that is the case, why doesn't it happen all the time?
EDIT:
In our program, We are using the "EnumProcesses" function from the Platform SDK, PSAPI.dll, to enumerate all of the running processes.
Could it be that either the script or the application runs as a 64-bit program, and the other as a 32-bit program? If so, then on 64-bit machines the update check could be looking in the wrong location for an existing application and thus reporting it as missing?
What mechanism are you using to check to see if the process is running or not?
Try using something like process explorer to see what path the executable image is loaded from - it should be listed in the modules section.
Related
Is there a way to check within my application whether it is run from App-V (or some other app visualization software) or from a local installation?
I looked around but I could not find a clear answer to that...
The best way to check is to verify if one of the following DLLs are loaded by the application, which should always be the case for applications running into a virtual (App-V) environment:
AppVEntSubsystems32.dll
or
AppVEntSubsystems64.dll
You can read more about this here: https://blogs.msdn.microsoft.com/gladiator/2014/09/04/app-v-5-on-application-launch/
I'm working on an application (A) that has to react and do something when a specific program (B) is installed on the system.
I've been seeing a lot of examples about listing programs already installed using the registry keys and some code to monitor status changes on programs and services using WMI.
I'm thinking I could use those combined to do what I want, say:
1. When my application (A) is started, check on the registry if my program (B) is installed or not (initial condition).
2. Then, monitor for service changes on the local machine from my application (A).
3. And every time a report of status changes comes from service "msiserver", re-check if my program (B) has been installed/uninstalled (initial condition has changed), and do something if so.
This sounds to me like I'm trying to reinvent the wheel here, and I wonder if any of you know if there's a more "natural " or "immediate" way to catch the moment/event when a specific program has been installed on the system ...or not :/
Additional considerations: The default location where the program (B) can be installed is variable, so monitoring for folders (like C:\Program Files) is not an option.
Thanks!
I'm not aware of any mechanism that would allow you to subscribed to an OnInstalled type event. You'd have to loop and detect the installation status change. Perhaps using the Microsoft.Deployment.WindowsInstaller (DTF) library to enum products and/or components. Don't use WMI... the Win32_Product class is horribly slow and querying it causes reinstalls of applications. (Don't ask... it just sucks).
I have developed a small-ish C# console application (TextMatcher.exe) on my local development machine and now need to deploy it to the live environment. It references another class library which I developed which has generic functions, which I intend to use and improve in future console applications.
Ultimately this specific application will be executed from within an SSIS package, but for now I'm just trying to run it from cmd.
I kid you not that this is the actual output from the program:
E:/TextMatcher>TextMatcher.exe
No
E:/TextMatcher>
The computer literally says "No" and gives no further information. I have not included, anywhere in the program, to output the word "No", on any failure or otherwise.
Of course, it runs fine locally. I made sure I included the dll of the utility class library too. I have read other questions (here, here) about how to deploy console apps correctly, and have followed the advice.
NB: This is also proving to be quite hard to Google because of the use of the word "No" being fundamental to the problem...
EDIT - It seems to be working now... I simply copied over the files again from my local machine to the remote machine... I am trying to get it to break again so that I can figure out what on Earth happened, and until I do, I will not accept an answer so that people could maybe shed some more light onto it. Either way it is quite baffling.
There's a chance that someone has modified the Image File Execution Options registry setting on the server to launch a debugger automatically.
In short, examine the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\currentversion\image file execution options and see if there's an entry that matches the name of your executable.
Check whether you have installed the necessary Framework components,
i.e. the suiting Dot net framework. Application with 4.0 and installed 3.5
can cause very strange behaviour.
Try writing a very simple window application and start it on the deployment machine
(this will give you probably more help what is missing).
Check whether the needed Dlls (that you developed, e.g. your class library) are reachable for the console application. And check whether the right version of your Dll is matched!
Check the plattform settings in your console application. Do they match with
the machine where you want to run your application? (win64 and win32 mismatch)
If all of those do not help, try inspecting your executable on the deployment machine
for example with depends.net, checkasm, or similar.
Does your production environment have AppLocker running? I don't know if its output can be customized to output "No" on a command line. Applocker comes to my mind because you can use it to restrict a system to run only signed executables. If your Textmatcher executable is unsigned, it may get shut down immediately. If you have the ability, I'd be curious to see if signing your binary changes the behavior.
I have a system with two web applications, one web service, one Windows service and a WPF application running 24 hours a day on a touch screen. All of them are connected to a database.
I want to be able to upgrade all of those applications by uploading upgrade files to the database and set the date and time for the upgrade to occur.
I have one idea on how to do this.
An application has a thread running to look for available upgrades.
When an upgrade is found, the file is downloaded to the application's computer.
When download is complete, the applications triggers a restart.
When application starts, it looks for an upgrade file on the local computer.
If upgrade is available, the application upgrades itself.
I'm not really sure how all these steps should be done yet, especially the last one. But I want some comments about this. Is this completely wrong? Am I on the right track? Any tips on how to do it like this or in another way?
I think you're going down the right lines here. A polling application to check the database for the existence of a new update followed by an xcopy deployment script would do it.
This might be doable from a PowerShell script too, that runs on a schedule, say every 10 minutes. It could check the database, close the process and service, xcopy the application (from a shared source) and restart the said service and app.
All this assumes that you are not using Windows Installer to package and deploy your application initially. Although an xcopy to directly replace binaries wouldn't hurt an MSI package, it's not recommended. We use AD MSI deployment at work and it's a pain at the best of times!
MSDN contains references for MSI vs XCopy deployment for WPF applications (as well as the security requirements).
This was the first link I found for querying SQL from PowerShell: http://elegantcode.com/2008/03/27/discovering-windows-powershell/
Good luck!
You will have trouble doing this with ClickOnce. ClickOnce would only work for your WPF app, it can't do anything with the services or web application. You could write a separate ClickOnce-deployed "Updater" app whose job is to update the other apps, but that still seems a little iffy.
It may sound stupid, but I'd start with the simplest thing I could think of. How about using Dropbox to push your update files; then an AutoHotKey script that runs on startup, watches the Dropbox folder for new updates, and runs them?
Sounds hokey, but it's something you could prove out in an hour or two.
Microsoft have an Updater Application Block which might be what you are looking for.
Do you really want to run an update from the database or is this just a possible solution? You are reinventing the wheel.
Have a look at ClickOnce deployment, everything you need is already done for you and integrated into VisualStudio. If you use something that already exists you have the benefit of existing documentation, helpful blogs of people who have already gone through the pain points and updates and fixes.
ClickOnce Deployment
ClickOnce Deployment in .NET Framework 2.0
How you want to use ClickOnce depends on what you want to get out of it. Out of the box you can very easily create a deployment that checks for an upgrade every time you run the application but you can also with a little bit of code have the application check for updates whilst it is running.
The Updater Application BlockVersion that Dominic Zukiewicz mentioned is the pre cursor to ClickOnce.
EDIT
ClickOnce provides a roll-back scenario on both the Server and Client end. The client can roll back to a previous version using the normal add remove programs dialogue and you can easily republish a previous version.
You could create another Windows Service that does the updates on a daily basis. The service would look on a specific folder if there are any updates to be process. For example it could look for an xml file which tells it the new version of the application and what the files to update are. It would shut down the application/services, backup the files that it needs to update, start the application/services, and clean up backup files keeping at least three backup files. The service should keep track of the last and current version installed so that when it reads the xml file it can check if it is a new update or not or you can simply delete the xml file when it completes.
How about Google Omaha? It's an open source tool, currently used to push updates of Google Chrome and Google Earth. Omaha can handle application installation, too. A high-level design overview can be found here.
For a testing usage of not very complex WPF applications I often don't make installer - just, after building project, copy Bin>Debug folder content of a VS2008 project folder to a hard drive of a user computer and put an icon to a desktop. No records to windows registry.
Are there any drawbacks of such a way of using windows applications for testing period?
There's nothing wrong with this approach at all - it is what's called xcopy deployment. You don't get a few things doing it this way:
an entry in the add/remove programs for users to uninstall with
the ability to add shortcuts to desktop/start menu/quick launch
any changes to the registry for settings etc...
Another benefit is that you can get your application onto a computer by a user who does not need administrative privileges to install.
It really comes down to your requirements. If you don't need any features of an installer, then just copying the files is a good approach.
I'd agree with the other comments about using a release build though - especially if you are deploying for real use and not just testing.
The only change you might want to make is to build the app in Release rather than Debug and take the files from the Bin>Release folder.
more info: http://haacked.com/archive/2004/02/14/difference-between-debug-vs-release-build.aspx
When you have multiple files to deploy along with your exe, dll's to register, file associations to set up, then an installer is a neat way to deliver all of that in a reliable manner. If you don't do this with an installer the user could easily screw things up.
In addition to that, the installer is sometimes used as a means to ensure the computer is truly ready for the application. For example, the installers I've written check to ensure the proper version of .NET is installed, and will download & install it if necessary.
However, there are many times when these characteristics are simply not worth it and deploying a standalone application in a single exe is perfectly acceptable. Simple applications that don't need to store a lot of settings on your computer and don't have a lot of prerequisites are perfect examples. The first thing that comes to mind are all the utilities from Sysinternals.
I see only one potencial drawback. There is nowthing wrong in your approach as long as you don't have more than 1 to 3 users and changes during test session are not often.
When changes are often and you have to copy library to more than 3 users (hosts etc.) the drawbac I mean is maintenance time. I know what I'm talking about because in place where I work, we have such issue.
Last time I've started to more taking care about maintaining our application and copying files from one host to another than coding. :(
In my honest opinion sometimes is better to invest your time on the beggining and write an installer than have a lot mainteneance and copy things later.
To solve the number of users problem, there's a very simple solution that does not require to setup a full installer.
Basic setup for multi-users xcopy/.bat deployment:
A shared drive, with one folder for the .bat files, one for the binaries.
Upload the binaries to the shared
drive and update the install script
if needed.
Have every user run the install script.
By the way, some very complex information systems are ENTIRELY deployed by .bat files (even when not testing!).