A have an app that must be uninstalled before it can be upgraded (not something I can change).
Of course, the default directory for the new install should be where the previous version was installed. But since the app has been uninstalled UsePreviousAppDir doesn't work.
What would be the best way to get an uninstalled app's directory? Is there anywhere it is stored? How would a new registry entry be managed for this?
There is no way to find the previous location of the app after it has been uninstalled, short of asking the user to remember this and re-enter it.
However, a simple solution to this issue is to trigger the uninstall from within the upgrader itself -- UsePreviousAppDir takes effect when the wizard first opens, so it's safe to discover the previous app dir and uninstall at any point after that. The most recommended time to do it is from the PrepareToInstall handler.
Bear in mind that it still could be possible that you won't be able to find the prior path, either because the user manually uninstalled before running the upgrader or because the install failed, crashed, or was cancelled after it successfully uninstalled the prior version. So you'll need a backup (such as asking the user, or assuming some reasonable default) anyway.
Be very sure that you really do need to uninstall beforehand, though -- while there are a few cases where it is required (such as when the prior version was not installed with Inno -- in which case UsePreviousAppDir isn't going to help you either), most of the time you should just install over the top, using flags and [InstallDelete] entries to skip or remove old files as needed.
Related
I would like to check programmatically if a new Windows "feature update" - that is a new major version like 1904, 20H2 - is available. It seems WUAPI doesn't return these updates, but I might be making a mistake.
I think it is possible to install these unattendedly by downloading the Windows 10 Update Assistant and calling it with some poorly documented flags, or by unpacking an .iso and calling setup.exe. But what I'd really like to have is the interface that the Windows settings app uses. I'd like to basically click on "Search for Updates" programmatically, see if a feature update is offered, and possibly install that.
It is not an solution to just unconditionally run setup.exe (I already know how to do that). Neither is "switching to WSUS", because the computer in question may or may not be managed by WSUS. I'd like to show the update if and when it is offered, no matter wheter it comes from Microsoft's servers or WSUS. Is there any way to do that (short up screen-scraping the settings app? :-D).
Have you seen Boxstarter.org ?
Automation of windows installs.
But there is also an Install-WindowsUpdate function.
Finds, downloads and installs all Windows Updates. By default, only critical updates will be searched. However the command takes a -Criteria argument allowing one to pass a custom Windows Update query.
Help Install-WindowsUpdate -Full
See https://boxstarter.org/WinConfig
This should give you any hidden updates:
Install-WindowsUpdate -criteria "IsHidden=1 and IsInstalled=0 and Type='Software' and BrowseOnly=1"
output:
++ Boxstarter starting Checking for updates...
Restarting windows update service
++ Boxstarter finished Checking for updates... 00:00:29.5201057
There is no update applicable to this machine
I have just installed python3.8 and sublime text editor. I am attempting to run the python build on sublime text but I am met with "Python was not found but can be installed" error.
Both python and sublime are installed on E:\
When opening cmd prompt I can change dir and am able to run py from there without an issue.
I'm assuming that my sublime is not pointing to the correct dir but don't know how to resolve this issue.
This isn't a Sublime issue, it's a Windows 10 issue. My Windows 10 boxes don't have this feature so I'm not sure how widely spread it is, but you may want to check out this (seemingly unrelated) question "Permission Denied" trying to run Python on Windows 10.
The general gist from this post is that these new stub redirectors are supposed to direct you into installing some missing applications from the Windows App store and that user-installed versions are supposed to take priority, but depending on how the PATH is modified the system might find the stub versions before your user installed versions.
The currently accepted answer mentions:
The second part of correcting it is to type "manage app execution aliases" into the Windows search prompt and disable the store versions of Python altogether.
It's possible that you'll only need to do the second part, but on my system I made both changes and everything is back to normal now.
In the comments, there are comments from Zooba which further indicate that this is the way to go:
(Microsoft employee and CPython core developer here) You definitely only need to do the second part. There have been a couple of bugs related to upgrading apps resetting aliases which will be fixed in the next stable update, so it should be a one-time fix by then. While you're getting Insiders updates you may need to do it a couple more times.
... And launching the Store is a new feature to help people install Python - if you've added it to PATH using the regular installer it should take precedence over the new redirector, but if not you've discovered above how to disable it.
i had the same problem, so i went to the microsoft store (windos 10) and simply installed "python 3.9" and problem was gone!
sorry for bad english btw
Does SublimeText 3 / GoSublime have some type of caching of Go import packages? If so, how do I clear it on demand?
I ask because while writing a custom package that is under Github source control, it works until I refactor a func or struct. Then, back at my main app (of where I import this package) it lights up like a Christmas tree when I start using the new methods.
GoSublime (or GoLint?) does not pick up the refactored func changes, and everything shows as an error. But yet, I can go to a prompt and run go build and go test just fine - the Go tool works fine.
The only thing I have been able to nail down is after about 24 hours it seems to work?
OSX 10.9
SublimeText 3
GoSublime
sublimelint **<- DO I NEED THIS? SAYS IT IS FOR HIGHLIGHTING**
SublimeLinter
SublimeLinter-contrib-GoLint
SublimeLinter-contril-GoType
(and a few other packages)
I'm a SublimeText novice; but, I believe I have everything linked up and the required packages installed. Sublime's console shows no errors in the Linters (says it find gotype and golint).
SublimeLinter: gotype activated: /Users/user1/go/bin/gotype
SublimeLinter: golint activated: /Users/user1/go/bin/golint
Things work beautifully within the package itself. It's not only my remote app. In my package, I have an "/examples" directory of tests that doesn't even pick up the changes in the root package. But again, the actual Go tool does and builds and runs all tests using the new refactored code.
It is GoSublime/GoLint that is caching the import's schema/package details. How do I clear that?
Thanks!
Coming back to answer myself this after 5 months of no answers...
#dave-cheney himself replied to a Google Groups message I posted on this subject:
https://groups.google.com/forum/#!topic/golang-nuts/N3xB6PGs3wo
Resolution:
That code, even one-off tooling for other projects, must live in your $GOPATH/src. I have changed all projects to be in the $GOPATH/src/privatedomain/etc, and updated build scripts to just deploy the executable to those other repos (and commit them). Learn to work with the tools, not fight it. :)
You need to run go install [package] on those locally developed packages for their changes to show up immediately in your current Sublime project. There is still a long day-long delay that happens though if you don't run go install that the changes are picked up in other tools/packages within Sublime. "go install" works to get around this every time so no big deal (*see next bullet point).
In Sublime, I often run go install [package] and then close/re-open the current file I am working on to pick up the changes.
Note that you don't have to be online for the go install [package] - if the package is local that is (e.g. in development). So, this was the answer to my environment since I do a lot of development offline (commuting).
I see it all of the time when installing updates to retail applications, but after searching for two days, I have not found a way to do it. I am trying to create a package with InstallShield LE in VS 2012. One of my customer requests is to warn the user when the program being updated is running, and allow them to close the app (or possibly have the install try to close it). Is there any way to do this (the simpler the better)? Thanks in advance for your help!
This should just happen. However you may need to make sure that you didn't remove the file and re-add it to your installation; instead make sure you update it at the source location and rebuild. (This helps ensure that the underlying component settings remain the same, which may be relevant to Windows Installer's Files-In-Use detection.)
The following issue just crept up on me. The steps mentioned below had worked just fine until about 2 days ago.
When I deploy a update to a solution (of web parts) to a SharePoint 2010 server I don't see the update. The solution does get installed, but from what I can tell the installed web parts are over a month old (nothing new is installed).
I do the following steps through PowerShell:
retract the solution from the web app
remove the solution
add the solution
install the solution to the web app
I have tried restarting the Web App, restarting IIS and also restarting the server. Nothing seems to work.
I notice that after I remove the solution it does get removed from the GAC. After I add/install it the solution does reappears in the GAC.
Am I missing something? Am I overlooking a step that I should be doing? Something to try?
I never deactivated/reactivated the Feature.
After following the same steps I mentioned in my question I just deactivated, then reactivated, the Feature and everything started to working fine.
This is an easy thing to I can start to implement with my solution updates. However, why did I never have to do this step before?
In general, you should check your ULS log to see which version of your solution is running. If you see the old one, then you can be sure that your activated site feature is still bound to the old version. In this case you have to Inactivate the site feature indeed to loose that tie and then Activate to bind to the new one (it appears Activate always ties the site feature to the newest version of the solution).
Maybe you had not to do this earlier, because you did not change the version number of your solution, appearing as the same version in GAC on the server. In this case you had your site feature already pointing to the correct version of your solution, therefore didn't have to reset the feature.
You have probably checked, but just in case. Make sure that the powershell script is not adding a month old package.
Is the problem in the web part code or the configuration? The configuration usually unghosts itself sooner or later and refuses to update from the solution - you can update the file in the gallery manually if anything has changed there. For most updates there won't be any changes because existing web parts won't get updates applied anyway - they will use new code but old configuration.
If the problem is the code itself, does the assembly appear to the system to be unchanged? All the hardcoded full name references in SharePoint config files mean that usually you are deploying a new assembly but with the same version numbers. This can mean that the system doesn't bother making the update. I have found it very useful to update AssemblyFileVersion (which does not affect binding) on every build and have a page in _layouts that displays the file versions of all the loaded assemblies so I know exactly what is running.