I have up until now been using my own restart application utility.
But I now see that there is a dedicated restart manager since Vista.
This is useful for me because I now limit my application to Windows 7 or higher.
Currently, I offer a manual restart when the user changes the application language.
Also, after they have downloaded an updated installer (Inno Setup) it shuts the app down and starts the setup program.
I can't work out how to do these thing with the MFC restart manager. It mentions about adding one line of code to my MFC app and how to simulate scenarios. But what about my specific situations?
If you can please direct me to a good tutorial?
Sorry if my question is off topic and I will remove.
Related
I have a VB6 Application that I am deploying using Microsoft Development Environment.
The install package is working for Windows 7/10 32/64 bit.
The problem I am having is if a second user logs into windows and runs the installed app some of the controls are not working.
Forms that contain MSCOMCT2.OCX, TABCTL32.OCX and maybe others fail saying:
"Component ... or one of is dependencies not correctly registered: a file is missing or invalid"
But once again for the user that installed the app all is good.
I see in other installs there is a choice to install for only me or all users. I don't see a way to implement that in "Microsoft Development Environment", is this my problem?
What changes if you install an app for All users?
This may have to do with registry virtualization. The application may be running in some kind of compatibility mode so that the controls are not really being installed system-wide.
I'm not too familiar with those settings but it might be possible to adjust them so that the DLLs/OCX files are genuinely registered for all users and the application runs accordingly. There is a risk that if the compatibility settings were set intentionally, this could break something else.
Hopefully this is a useful starting point.
I will add that IMO installing the application not to require registration whatsoever is a much more robust solution. See How can you force VB6 to use the DLLs and OCXs from the app directory?
When uninstalling my application, it attempts to stop it if it's running:
Sadly, the automatically closing doesn't really work and it displays this error:
My applications disappear, the windows, the tray bar icon, they are all gone. But I can still see them in the process list.
I'm guessing Windows sends a signal to the applications to exit gracefully and the UI does so, but there's some lingering thread preventing the processes from terminating.
How does Windows Installer close an application during uninstall?
Once I know this I want to simulate it while debugging my app to see what's going on. Is this a sound plan?
Since Windows Vista, Windows Installer will leverage the Restart Manager to identify, close, and restart applications. Microsoft's documentation on Using Restart Manager, and in particular Using Restart Manager with a Primary Installer should be a solid starting point for implementing a test harness. Your applications and services should instead follow the Guidelines for Applications and Services.
The Guidelines for Applications discuss the messages sent to your application by the restart manager; services are restarted through the service control manager. In theory you could simulate the restart manager at that level, but I suspect you'd be better served by invoking the real thing, registering a carefully chosen list of resources to target just your application, if possible.
I have an executable application setup.exe for Windows that I realized with Launch4j/Inno Setup based on Java.
I often frequently release new versions and bug fixes.
I would like to know if there is a mechanism to install updates automatically?
Inno Setup does not have any built-in mechanism for implementing automatic updates.
You need to implement that yourself:
Make your application check for new versions (against your application webpage?). E.g. on startup (on a background thread?)
If the application detects a new version, make it download an installer to a temporary location.
Make the application execute the downloaded installer. You can make the installer run in silent mode (/silent switch). The application should close itself, to unlock any files it is using, to allow files update.
This approach will need the update installer to prompt for Administrator privileges. If you need the update to proceed completely seamlessly, you will have to implement a service. For that, see Deploying application with .NET framework without admin privileges.
We have an ERP application which is built in VB6 and it was running just fine till a few of our customer upgraded all their systems to Win7.
This software is programmed in such a way that it registers a few plugins (found in plugin folder) which are COM based at runtime. Now when the software is run by user without setting Compatibility Mode and Run as Administrator setting it fails and crashes.
I know we can manually set both Compatibility Mode as well as Run a Administrator by right clicking on program executable and then going to its properties. But this looks very unprofessional.
I think there will be some way to tell Win 7 to automatically run a software in Compatibility Mode and Run as Administrator.
Please help me.
Compatibility is an administrative function, not a development or deployment function. It is better to fix the application where possible, especially to remove any requirement for elevation.
There are plenty of tools for investigating the issues so you can correct them. However globally registering "plug ins" at runtime is a nasty one. VB6 component self-registration is always global unless registry virtualization can redirect it. Why not create installers for the plug-ins that can run elevated once during installation?
There are ways to set compatibility less manually, even as part of installation - though Microsoft discourages this. Maybe take a look at:
Compatibility Fix Database Management Strategies and Deployment
However the effort required might be better spent on remediating the problem. Support costs will be less over time.
As the other answers have said, you shouldn't need to run all the time elevated.
If you want to register the plugins after its started (as a normal user), you can use ShellExecute() with the "runas" verb to run regsvr32.exe, or use COM elevation which has been discussed many times before.
You can indicate that an application must run as admin by specifying it in the Application Manifest, which in an xml file that you can either embed or deploy with your application.
Once your application is running with admin rights it should be able to register and load the plugins. You should not need to run in compatibility mode to access the COM plugins.
I need a background application to support my client application, which should always run on the client machine regardless of the main client application is running or not.
Windows Service was my first choice but problems I faced with Windows Service were: ease of control over windows service through main client application, release and installation of patches to the windows service and troubleshooting if windows service fails to run.
So, I started thinking for alternatives to the Windows Service and found that a Windows Forms application with NO visible forms can do it for me. This invisible app should start with system startup and keep running all the time, doing all the work that a Windows Service would do. But before I go deeper into the development, I want to explore the pros and cons of this approach.
Any suggestions/comments on this approach?
Your requirements are more suited for windows service. Main advantage with windows service is that it will start as soon as system comes up, irrespective of anybody is logged into system or not.
To sort out deployment issues, you build your business logic into separate assembly and call the necessary function withing windows service. This way you can deploy just the modified assembly.
Winform application with invisible form will not serve the purpose. HTH
That's not possible. User-mode applications must be started by a user, and will not continue to run when that user logs off. That's the purpose of the SessionEnding event: to allow you to shut down your app gracefully when the user logs off or the computer is shutting down. You can't just start something at system startup and keep it running all the time.
You need a Windows Service for that. But you should be aware that under Windows Vista and later, a service cannot interact directly with the user. They run in a separate process and are restricted from displaying their own UI. It's not clear from the question exactly what your needs are, but this is an important limitation of a Windows Service that is worth considering. A proper design really shouldn't require this, but there are apparently a lot of people to whom this new, more secure behavior is a real surprise. I explain this in more detail in related answers to this question and this other question.