Our application use WebView2 and it must be keep running for a week or more. We are concerned that if an uninstall occurs due to a WebView2 update while our application is running, it will be terminated by the Restart Manager.
The PC using this application may not have joined the domain and cannot control or block updates by the GP or registry.
(We believe that if an update is performed and WebView2 uninstallation occurs, the application will be terminated by Restart Manager.
GitHub - SessionEnding event is raised when WebView2 is uninstalled
)
Is there a possibility that the WebView2 auto update will occur while
there are processes using WebView2?
WebView2 updates the same way as the Edge browser, you can refer to this thread. Edge can search for updates when process is running but can only finish updates after restarting. I think WebView2 should be the same, maybe it can't finish updates when the process is running.
To get more help, I suggest that you can also raise an issue on WebView2 GitHub.
The WebView2 runtime has an updater that will run in the background and install updates when they are available. New versions are installed side by side with older versions. Older versions are only removed when no longer in use.
The WebView2 runtime updater works in the same way as the Edge browser updater. When a new version is available the updater will install the new version side by side with any existing versions that are currently in use. The old version will be deleted once its no longer in use. That is, apps with already created WebView2s will continue to use the older version. The CoreWebView2Environment.NewBrowserVersionAvailable event will be raised to tell apps using the old version to move to the new version. Once the apps using the old WebView2 version stop using the old WebView2 version, the older version will be deleted.
New WebView2 instances will be created using the newest available version even if there are other apps using the older version at the same time. One exception to this is if you create a new WebView2 instance that shares a user data folder with an already running WebView2 running with an older WebView2 runtime version. In that case the new WebView2 instance will connect to the already running older versioned WebView2 runtime environment.
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 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.
We are trying to move an old client application from one PC to a new windows 7 64 bit PC. At the time the software was developed we used QBFC version 5 to interact with quickbooks, however it appears now that we can no longer do so. I attempted to register the interop.qbfc5lib.dll after installing the QBFC5 installation package and we still receive an error message. I've also attempted installing the most recent version of the SDK to the system and upgraded the QBRPXML2 to the most recent version. The client is now running QB2013 on the server and has updated his data to this version.
The error we are receiving is: "Retrieving the COM class factory for component with cLSID {4877276c-486d-b201-f096035ca4df} failed due to the following error: 80040154.
Suggestions other than recompile the code?
I had this problem with a client who I had used QBFC 8 and he had switched to a new computer. I didn't do a lot of research, but it appears that the installers that Intuit has on their websites use different CLSID than I originally had built against. I just downloaded and installed QBFC 5, which I didn't have anything installed for, and it shows the following CLSID in the registry (I'm on Windows 7 64-bit):
QbFC5.QBOESessionManager {86AC2FAD-C987-4757-B591-02F9867A8BE5}
QbFC5.QBSessionManager {4877276C-A727-486D-B201-F096035CA4DF}
The only thing I can think of is that the COM files that were originally installed on your development machine have been changed in a later installation. For my client on QBFC8, I simply switched to using QBFC12 and recompiled the code.
Code snippet:
navigator.plugins.refresh(false);
var a = new ActiveXObject(collab.axName);
if (a) {
version = parseVersion(a.version);
}
I run something very similar to the above to check the version of my installed FB plugin. If it is out-of-date, I replace it with a newer version (Firebreath bog-standard Windows installer). However, if I run the snippet again, the newer version is not detected - the new ActiveX object has the old version number.
The ActiveX object creation seems to be the key - installing an update before creating an object will work correctly, and the update is detected if the browser is restarted. And updates work fine in NPAPI browser (which do version detection using navigator.plugins).
Internet Explorer 10, Windows 7.
My question:
Is this expected behavior (or indicative of a bug in my code)? If it is expected, is there is known workaround or alternate approach to accomplish the same goal of installing an update without restarting the browser (e.g., version detection without instantiation, forcing ActiveX update detection)?
I have created an ActiveX control which is installed in the client machine. Now I have made some changes in the ActiveX control and now want that Changed ActiveX should be updated in the client machine automatically.
I have changed the version of the setup file from 1.0.0 to 1.0.1 and "removePreviousVersion" to "True" but still it is not asking for update.
Should i change the AssemblyVersion and AssemblyFileVersion of the assmeblyinfo.cs file.
Am I missing something to change the product code or update code or version?
"asking for update" must be your implementation. ActiveX/COM-s do not update automatically. You can run Setup to preinstall the new version.
However you can implement some service/background process which checks for new version via internet. There must be web/file server connected to internet which shares some small file (e.g. text or XML saying which is the latest available version).