Avoid Stop Certain Running Process

A follow up on this topic:

I try to install this on a UAC enabled Win 7 copy. Apparently, it will fail with

"The process does not possess the 'SeSecurityPrivilege' privilege which is required for this operation. when I am upating the application."

So When I run the software as administrator, it detects the LP.exe binary and prompted me to kill the process. (which in fact wasn't killed), but proceed to update everything properly.

Hi Peter,

Unfortunately wyUpdate doesn't currently support stopping & starting services. This is what is necessary to update the files properly.

We plan to add this with wyBuild 2.7 coming in a couple of months.

How exactly are you running the service? Are you using a custom loader or are you using rundll?

Hi Wyatt,

I don't need the service to stop.. I am just updating a config file in the %APPDATA%\myprogramme folder with a recent edition. And as a matter of fact, after the initial installation, the service should never be stopped.

So I am asking is there a way to bypass the checking/stopping/updating certain file? Something like "JUST IGNORE THIS FILE) Or it is in WyBuild's nature it has to write every single exe file in the programme directory?

And as for service procedure:So during the NSIS installation, the service can do auto installation by running myservice.exe /service and I call sc start myservice after that.

It's only when removing the piece of software, will I call sc stop myservice and myservice.exe /unregister to perform all the uninstallation work.

Ok, I see what you're saying. We were planning to add the ability to ignore files later (wyBuild 2.8 or so). I'll move it up to the wyBuild 2.6 release coming in about a month.

Thanks for the suggestion.

Just wondering...is this feature (the ability to ignore certain files) still coming to WyBuild? Thanks!

Hey Ben,

We're actually implementing the ability to properly start/stop/and upgrade services. Our goal is to release this around wyBuild 2.6.8.

Is this what you need it for? Or is there some other reason why you need to ignore certain processes? The reason I'm asking is that it's actually better if we add proper support for complex systems rather than work around them with hacking solutions.

Hey Sam,Thanks for the reply. The reason I need this feature is because there is an executable besides the main one in my application's folder that will be running when wyUpdate is run, and I want to avoid the close process dialog.

Heres a little more background: I have a technical requirement that users are always running the most recent version of our application. The executable that I mentioned is a shim whose whole purpose is to silently launch wyUpdate and then ensure the most recent version of our application is installed before finally starting the actual application. If the most recent version isn't installed (due to an update failure, user cancellation, etc.), the application will not be started and the user will informed that the update must occur before they can continue.

As it stands now, wyUpdate detects the running process and requires it to be closed, which of course requires the user to start my shim again to actually get the program to start. To get around this for now, I've created my own version of WyUpdate that explicitly excludes my shim's process; so I've got a double hack going on here (hacky shim + custom version of wyUpdate). It works, but its messy.

What would be great is if there were an option to require users to download an update, and an option to have wyUpdate launch the client application upon completion -- this would eliminate the need for a shim in my case...

Hope this helped explain my need. Thanks again for your help.

-Ben

I have a technical requirement that users are always running the most recent version of our application. The executable that I mentioned is a shim whose whole purpose is to silently launch wyUpdate and then ensure the most recent version of our application is installed before finally starting the actual application. If the most recent version isn't installed (due to an update failure, user cancellation, etc.), the application will not be started and the user will informed that the update must occur before they can continue.

Why do you force your users to upgrade? What if their internet is out? Or what if between the time they check for an update and the time the click the "Update" button your server goes down?

Hey Sam,Our product is a SAAS line of business application. The customer's data is hosted by us and delivered over the web as well, so if the internet is down the software is useless anyway. We have to be sure they are running the latest version because client side components (i.e. Data Access components) need to match the currently deployed server-side components.

We are currently using ClickOnce configured to require updates and not allow the user to cancel; and when it works, it works flawlessly. We've been having increasing trouble with it though due to Firewalls / AV software and our inability to know the physical disk location between updates.

We've been looking at WyUpdate as a possible solution, and my Shim approach seems to work, but this is why I need to have certain processes excluded. Thanks again for your help.

-Ben

I'm having trouble understanding why don't just do this all within your main app? Why use a shim at all? Why not just use wyUpdate in the main() function of your app (before any UI has run), if there's an update available start wyUpdate.

You can even execute your app after it's been updated.

Hey Sam,I overlooked the execute after update option; your suggestion works nicely and removes a lot of complexity for me. Thanks again for your help.

-Ben

Now in wyBuild 2.6.7 you can Start and Stop services. Simply go to the "Update Actions" and add an action to stop the services before the update, and add another action to start the services after the update.

See Starting and Stopping Windows Services.