I've developed a Windows Store apps and save some data in SQLite, and the data file is in LocalState folder.
I know for the OS policy when I uninstall the app from windows, the appdata folder will delete automatically.
My question is
1. Is there any idea to deny user uninstall some specified Windows Store apps that I developed from windows?
If I can do it, I think can develop a Windows Program to install & uninstall Windows Store apps by using Powershell, and I can backup the LocalState data by C# code.
2. If No.1 is impossible, can I catch the uninstall action from Windows?
I think I can develop a Windows Service and set it to Auto Run when windows startup, and if I can catch the uninstall action from Windows by using the Windows Service that I developed, I can backup the data by C# code in Windows Service.
Is there anybody who can help me out?
Thanks.
Related
I have purchased the Windows sideloading key to deploy an LOB app without using
Windows Store. My clients are reluctant to use powershell to install the app.
Is there a way to automate the powershell installer to a much more user friendly
way? So I can give a one click installer to install the app on devices.
Using an MDM is very costly, devices can't be domain joined either, and I don't know any other way of doing it. Please help.
Try WiX Poweshell extension, https://github.com/flcdrg/PowerShellWixExtension and create standalone installer.
Few machines have 'MyApp.exe' installed using ClickOnce. And I have created a new MSI Windows Installer for 'MyApp.exe' using MS Visual Studio 2013 Setup and Deployment. I have a requirement that when my new MSI Installer runs it has to automatically remove/uninstall all previous 'MyApp.exe' (installed using ClickOnce) and install the new exe. Installer has to do it as part of its installation process.
Is this even possible? ClickOnce doesn't make any registry entries, so how can I get the Upgrade codes/Product codes which I can feed to Windows Installed 'Upgrade Paths' to upgrade it. ClickOnce is per user installation, but Windows Installer is not.
Is it even possible for Windows Installer to uninstall ClickOnce installed application ?
Any help is greatly appreciated. Thanks
ClickOnce is a per-user deployment experience and MSI is usually a per-machine experience. Per machine can't clean up other people's profiles. The only way I know is to do an active setup trick to run a program for each user who logs on and then execute a script to do cleanup. Either that or put first-run code in the applicaton itself to do the same.
I have developed an application in Lightswitch 2012, and now need to deploy it to a desktop PC running XP SP3.
I have already looked at two previous posts Can't run Lightswitch 2012 Programm under Windows XP and
Lightswitch Desktop Application Wont Install in XP SP3
The two posts both refer to executing [editbin vslshost.exe /SUBSYSTEM:WINDOWS,5.01 /OSVERSION:5.1] to modify the vslshost.exe file, though only the first post says it worked.
In my case, I have tried the above to update the vslshost.exe file, but when I publish my LS2012 project it reverts back to the default vslshost.exe file. And if I manually swap the file with the copy I modified, when I run the deployed app I get the following error:
System.Deployment.Application.InvalidDeploymentException (HashValidation)
- File, vslshost.exe, has a different computed hash than specified in manifest.
- Source: System.Deployment
So, the questions are
am I doing something wrong?
is there a master copy of vslshost.exe I need to update instead?
(BTW, I also ran the VS2012 (KB270250 from VS2012 Update 1 CTP 4))
Thanks for your help
As this is an internal company app, I have just convinced our IT guy to upgrade the machine, because the certain grief of trying the different possible solutions was just too much.
BUT if you MUST deploy to XP
To find out more, here are two pretty exhaustive posts with input directly from the Lightswitch team:
Progress on LS2012 desktop apps installing AND running on XP yet?
Windows XP 32 bit deployment
Enjoy....(???)
We have a large application that has been developed over 15 years and in installed in 200+ client locations. The application currently consists of an Access database and a bunch of executable and report files located on a network share. A Setup.EXE file is run on each client machine (dlls are installed on the client) and then the client machines run the executables directly from the network share. During our upgrade procedure the new executable and report files are copied to the network share and that way each client gets the update immediately.
Our current installation program is very old and, among other things, it doesn't handle x64 so we are in the process of moving to a new deployment tool. At the same time we are migrating client Access databases to SQL Server. I am having difficulty finding a deployment tool to do what we require. Specifically we need the install/upgrade file to do the following:
It must be able to be run from a client machine on a network and copy the new executable and report files to the network share. That share could be a Linux box or a dumb storage device.
Accept a password before running the installation
Allow the user to select the network share as the location to copy the executables
It must NOT add anything to the client machine from where the package is run (Add/Remove Programs, registry, etc.)
Connect to a SQL Server database and run a script
The install/upgrade must be contained in a single, standalone .msi or .exe file. (no dependencies on dlls or frameworks other than those that come with Windows XP)
The file must be able to be run in one simple step. It is the end user that runs the upgrade without our support and without involvement from IT.
It looks like the closest thing to what I need is WiX but the problem there is that whenever the .msi file is run from a client, the client machine thinks that a program is being installed so it allows the client machine to uninstall the product, which is not acceptable.
If the product were written today it would certainly be architected differently but it currently is what it is and we can’t change that. Any help here would be greatly appreciated!
WiX is just a toolset built on top of Windows Installer technology. It makes many things easier and simpler as well as hides lots of Windows Installer weird features... But, it is still limited by Windows Installer, its underlying technology.
Your list of requirements made me think that Windows Installer is not the right technology to choose. I would assume that you'll spend more time on workarounds, than on functional code... But I have no experience with other installation technologies, so I'll leave those recommendations to others.
I am currently using the Visual Studio 2010 Setup Project to deploy my application to an MSI installer file, which includes a Windows Service and a Windows Forms application. But I am disappointed with the performance and compatibility of this form of packaging.
My application is compatible with Windows XP and upwards, but several older XP user-testing boxes simply don't have the right version of the Windows Installer or the necessary service pack installed. (Un)installation can take dreadfully long for a program under 1MB in size and many systems do not support it. InstallState errors can crop up and ruin the (un)installation if the service has been deleted or already installed, or if any program files are missing (for uninstall).
What I need from an (un)installer:
Manage .NET dependencies.
Copy/remove my application files to a folder.
Add/remove menu and shortcuts to the desktop and Start menu.
(Un)install a Windows service, though I can also do this from my application. The stop and uninstall part is important.
Run my application when it's done.
This question's answers recommend NSIS (which I have used with good results) and WiX. Ironically there is no easy link to simple installer for WiX on their website.
Am I missing something with VS2010's setup project? It is optimized for speed, but it's just too slow.
You should run the installer/uninstaller explicitly with
msiexec /x thefile.msi /l*v thefile.log
(/i for install). Then inspect the log file; it will have time stamps telling you what action took what amount of time. Of course, the logging will affect that, but you should get an idea what makes it take so long.