dconnet

Huh. It looks like the Options dialog does not work on XP. (We are currently reworking the Options dialog, but that won't be done for a while) While we haven't killed support for XP, I would in no way say we actually support it. We're not likely to fix any XP-only bugs.

Possible (probably!) related: https://esupport.trendmicro.com/en-us/home/pages/technical-support/1104301.aspx

Well - kind of - but it will want to move the current database there, not use the one that is already there. The only way to do that in the past was to hack the registry. But StoreApps make that impossible. What you could try would be to do a complete backup of the custom location, point the StoreApp to the existing custom. Tell EN 'yeahyeahyeah'. Then after it finished, close EN (completely) and restore your backup. This is no different then having a custom location on a new computer - EN has never had the ability to forget the current database and use a different one (except, as noted, by hacking the registry)

Not quite. It will not touch the existing install. As long as you're running a current version (6.x - post database move), it will utilize the existing database files. If you have moved the database to a custom location, it won't find it (no access to normal-desktop registry). Both versions will not run at the same time (we have never allowed multiple instances for the EXE), so that's not an issue. But you might easily get confused which one is running. Uninstalling the desktop version will not affect the store version. And uninstalling the store version will not affect the desktop one.

The 2 versions use the same (exact) binary. But there are some runtime differences - WinStore can do tiles and notifications - enscript does not work with WinStore version - WinStore is easier to update - no MSI installer - Some options that make no sense in the Store have been removed - for instance check-for-updates. Other than that, I'm not aware of any other differences. (And I'm who storified it)

Known bug. A fix is in the pipeline.

You need the desktop version of OneNote installed. Not the Metro/ModernUI/UWP/name-of-the-day version. It also needs to be running when you do the import into EN.

You misunderstand. When you upgrade an existing installation, the old version is uninstalled (I'm not talking about an explicit uninstall by the user). That is the phase during which the shortcut is cleaned up. That's how msiexec works. The programs you mention may very well be scheduling the removal after the install. Or they may be doing "bad" things. Unless we can figure out how to safely to an upgrade where we first install and then uninstall, this behavior will not change. We have no plans to reverse engineer how MS stores the shortcuts (yes, I know where they live) and perform undocumented/unsupported actions that are sure to cause issues in future versions of Windows.

How's that? Unless Evernote's application name changes or its file path changes, the "old" pinned item will still point to something. For those who manually pin Evernote to the taskbar, it is most likely pointing to C:\Program Files (x86)\Evernote\Evernote\Evernote.exe unless Evernote is intervening and doing something else and pointing to what, the registry? C:\Users\%user%\AppData\Local (or Roaming)? Because the MSI uninstall process cleans up the shortcut (during RemoveShortcuts). During an upgrade, the old product is uninstalled and then the new one is installed. (If you know MSI terminology, we schedule RemoveExistingProducts before InstallInitialize) When you pin the app, we do not intervene. The _only_ API Microsoft provides for interfacing with a pinned item is IStartMenuPinnedList::RemoveFromList. I think that name is descriptive enough that it's obvious what it does... The _only_ legal way to get the shortcut to stick on upgrade is to change the installer to first do an install and then uninstall the old product. This has it's own set of issues, especially in an already released product. Bottom line, this is not going to change unless Microsoft changes msiexec.

Microsoft frowns on any installer messing with the task bar (http://blogs.msdn.com/b/oldnewthing/archive/2003/09/03/54760.aspx). I believe (tho I haven't looked closely) that we do have some special cleanup code to remove the existing shortcut. Because if you don't, then an uninstall/install (or upgrade) would leave the old pinned item pointing to nothing. (I see that with other programs I use) Also note http://msdn.microsoft.com/en-us/library/dd378460(VS.85).aspx, specifically "A small set of applications are pinned by default for new installations. Other than these, only the user can pin further applications; programmatic pinning by an application is not permitted."