I am developing an application which has published tens of versions, during which we have updated electron and electron-builder several times.
Recent I have used electron-builder-notarize to notarize the application. Ever since I have noticed that, the app runs against a different instance of Chromium. I can confirm that since my devtools settings are different when I run the old version of my application compared to when I run the new version.
Additionally, I see different sets of bookmarks and settings (which use localStorage) running the old or the new versions of the application.
localStorage is restricted to the application origin, I confirm that in both versions the app runs over localhost:3000.
How can I configure the release process to use the same instance of Chromium? Or better said, how can I build the application and not loose access to previously stored data on localStorage.
Related
We have an application that we distribute internally on a network share with an MSIX package. We make the MSIX package with the MSIX project type in Visual Studio. Users install it with the index.html page that is created.
We want to rollback changes in case an update goes seriously wrong, so I've created an .appinstaller template and use it to set the ForceUpdateFromAnyVersion flag.
My question is how does a user actually perform a downgrade? I've tried to browse to an earlier version in Windows Explorer and execute the .msixbundle file, but it tells me that a newer version of the app is already installed and my only option is to launch the currently installed version.
I've only just discovered this ForceUpdateFromAnyVersion flag last week and we create weekly releases, so the version that has that flag set is the current version. Is that the reason downgrading doesn't work?
To perform a downgrade, place the appinstaller file on the share near the MSIX/MSIXBUNDLE and instruct the users to install the application via the appinstaller file (double click the appinstaller).
Only then the downgrade scenario will work. The msixbundle does not contain the ForceUpdateFromAnyVersion and it's not aware of it unless you use the appinstaller, that is why, when you try to downgrade via the msixbundle you receive the error that a new version is present on the machine.
What you must consider is this: if the user installed the MSIX/MSIXBUNDLE first, and then you publish the appinstaller file with the old version on your share, the downgrade will not happen automatically, because the MSIX on the user machine does not know that he has to check any share for updates/downgrades. All of the auto-update options are defined in the appinstaller.
But if your users installed the application via the appinstaller first, you can then put a new appinstaller file on your share (and MSIX/MSIXBUNDLE of course) which points to a lower version, and depending on how you defined the check interval in the appinstaller file, the downgrade will be performed automatically..
From what I read (I didn't test it) it seems that indeed the flag needs to be present in the appinstaller of the version that is checking for updates (not just in the new version). So, with the next update you should be able to push an downgrade.
Here is a more details tutorial from Microsoft on MSIX downgrades.
I have been searching the internet but I couldn't find an answer. I just want to find out if I could use the built HTML.
To make things clear. I created a vue-CLI project. I created a built HTML by running an npm run build.
Running the npm run build will create a dist folder with an index HTML, and its needed resources.
Now I would like to add this in electron. Is this possible?
If your project is client-side html only, then it is ready to go: just use one of the minimal Electron examples, and set your index.html as the start page.
If it is connecting to a back-end server (e.g. to access a database), it can still do that, but it means the application won't be able to run offline.
It is worth considering why you want an Electron app, instead of just having a web app. E.g. Are you hitting any security restrictions or other limitations of a web app, that a desktop app does not have? If not, packaging as an Electron app might just be effort spent on something that no-one wants or needs.
As you've built with vue-cli, it might be worth looking at Quasar Framework which is a wrapper for Vue that comes with Electron and Mobile targets ready to go. You don't actually have to use any of their UI components to get this.
I have managed to get an XAF application into the Windows Store via the Desktop Bridge.
When a user installs my software from the Windows Store and then chooses to uninstall,
I want them to have the option to completely uninstall the software including the database.
So that they won't have any problem should they later decide to re-install?
Currently, the UWP uninstall does not give an option to delete the database ( or even explain how to delete it ) Thus the user may be tempted to delete the data files via Windows Explorer - which still leaves some instance of LocalDB maintaining an entry in its list of databases.
Thus on a second install after deleting the database files, the UWP program displays the error
"Login failed for user"
As explained in this question
My connection string is using
(localdb)\mssqllocaldb
How do I automate removing the database and memory of it completely?
i.e What uninstall event can I use, What do I override where?
I can't see any executable code in the Desktop Bridge itself.
At the moment I think I may need to put "Run This Before You Uninstall" option in the actual program.
Or perhaps as a workaround, I should code a Clean Up handler for the "Login failed for user" error.
This issue is related
I am using Entity Framework 6.2 and .Net Framework 4.7.2
The Bridge Project is using Windows 10, version 1809, Build 17763 ( Min and Target)
See Getting Started with EF Core on Universal Windows Platform (UWP) with a New Database. It introduces use of migrations. Migrations are designed to help you change your database design and implement the changes in production. Migrations can be frustrating though because Microsoft has not documented the feature thoroughly. There is a list somewhere of the migration features not supported for SQLite; it is important to know about that from the beginning.
I have a .Net 3.5 web service that installs perfectly on my old XP box. I recently got a beautiful new Windows 7 box and everything has been working wonderfully. Yesterday I remembered that I need to instal this service on my new box and attempted to perform the install.
After the install I did a quick test and it seemed to be working correctly. Later in the day, I went into the config file and made a small change. After restarting the service I was dismayed to discover that the change was NOT being picked up by the service and it continued to use the old values.
Can someone explain how this is possible? I am totally befuddled here.
You've most likely been a "victim" of Windows Backward Compatibility (aka UAC Data Redirection).
When a program running as non-admin tries to write to config files located in Program Files, Windows redirects the write to another (user local) directory. That means, a user can seemingly write the file, but another user will see the original, Program Files, version.
We have a suite of programs that check for new versions at startup, and then download new versions to run if required. This is obviously a problem in Windows 7, when it is locked down as a 'standard user', as they can't write to the c:\program files directory and below. Anyone seen a example of an application that gets around with issue ?
Our applications are written in Delphi, but an example in any language would be useful.
Thanks in advance
Update:
We already have a system for determing whether a new version exists, the only problem is the download and install (if required), as this requires elevation. I can't think of a way that doesn't require an elevation prompt, or our users to reduce their security settings.
Update 2 :
I've asked a subsequent question, rather than adding a new one here
There are two options for application installation:
Application is available for all users: installation or update requires elevation for Windows Vista and up
The application is available for one user: install or update the application in the user profile in %LOCALAPPDATA%, no elevation is required
Ad 2: Google Chrome does this. It installs the .exe here:
%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe
--jeroen
Typically what you will see an application do if it needs to escalate permissions is something like this.
Application determines if upgrade is needed
Application launches an "updater" service that requires "Administrator" permissions
Application updates itself with this updated
Application re-starts
This is a pretty common scenario, especially since to update your own DLL you need to go to a secondary process anyway.
Here are some tips for you to get around updating challenges:
If your file is names 'update.exe' or 'install.exe' then it will automatically force a UAC elevation prompt. This is an easy way to make existing software bypass Windows Vista/7 permissions.
It is not a good idea to have the update checking and update process managed from within your application. The problem is that your app is likely to lock files and need updating itself. An external app should manage your updates.
The simplest update solution is to make an HTTP call that checks for the current product version number, and then download the installer binary if necessary. This won't give you any flexibility in updates, but it is a quick and easy solution.
Our company sells software that specifically helps with automatic updates on Windows 7 UAC (you can visit AutoUpdate+ by clicking here: link text). The best reasons for using a third party solution - any solution - are that you will have more flexibility with your updates and also avoid the finicky challenges of supporting different Windows releases.
Or you can have it so that the user runs a launcher app.
The application uses the LOCALAPPPATH\ folder to store a cache of the main application.
Launcher checks to see if the internet has newer version of file(s) than the cached file.
Launcher launches the cached application in LOCALAPPPATH
Your app can check if a new version is available on the remote server. If it does, then it can download update files in one of user-specific folders, like user's temp folder. You can get address of such special folders using SHGetSpecialFolder API function.
Once the download is done, you can pop up a dialog box telling user that you are ready for update. If user agrees with update, then you can run the updater process with elevated privileges (as administrator), and updater process can replace existing files in your installation path with the ones already downloaded in user Temp folder. To run your updater as administrator, you can use ShellExecute:
ShellExecute(0,'runas','notepad.exe',nil,nil,SW_SHOWNORMAL);
When updating is done, your updater process can restart your app.
You need to have a separate executable to the updating work. The updater needs to have a manifest that marks it as requiring elevation.
See: http://msdn.microsoft.com/en-us/library/bb756929.aspx
If your application uses MSI (Windows Installer) for its installer, then User Account Control Patching, if properly configured, can let you install updates without elevation.
If your installer wasn't run under admin - you don't need any additional rights to install update.
If your installer was run under admin - then it can create a task in Task Sheduler. Say, run this task once a week, under this account (admin) and with highest privs. Task will be your updater. Simple.