Having come across MSIX I am parking my self-updating Windows (and other OS) code, however pointers appreciated on getting Windows Services updated.
I have seen using Windows.ApplicationModel.Package we can check for updates:
private async Task CheckForUpdates()
{
var result = await Package.Current.CheckUpdateAvailabilityAsync();
if (result.Availability == PackageUpdateAvailability.Available)
{
// Shutdown BackgroundWorker service - but what restarts it?
}
}
But how would restarting and updating of the service take place thereafter?
Would I run my own process (I am running as am admin):
Process process = new Process();
process.StartInfo.FileName = "cmd";
process.StartInfo.Arguments = "/c net stop \"servicename\" & net start \"servicename\"";
process.Start();
Or does MSIX have a built in workflow for the above (i.e. the upgrade script detects the runing service, updates it, then starts it etc)?
Also are there cross platform equivalents for Linux and Mac (as a deameon) and Windows for the above updating of services?
I have also seen How do I update programatically a WinForms app which is always running, deployed with msix? using PackageManager - does this also work on Linux/Mac?
Related
I'm working with the following:
Docker for Windows v20.10.11
Docker running in Windows container mode
mcr.microsoft.com/windows:1903 base image
Proprietary application installed on top of this base image
Each year we create a Docker image with the latest version of our company's software. However this year's version behaves differently. Host machine installation runs fine. Containerized installation fails to run in certain situations. I can start the application as a simple EXE, for example using the Docker run command. The app will start and show up in "tasklist". However I can't start the app via the COM API, which is a critical requirement. The problem appears to be COM related. Normally we can create COM objects for our software just like for any other application. For example, IE returns a COM object just fine:
Creating these objects for our application works outside containers. However inside the container, our latest installation gives this error:
Access permissions appear to be ok. I tried a couple tests to prove this. First I can install other software like MS Word into a container and create COM objects for that:
Second I tried retrieving + modifying the application's DACL in PowerShell.
Changing access masks or trustees can cause an Access Denied error:
This also appears to confirm the access permissions were Ok by default.
Next I made sure COM is aware of the application. This appears to be fine. I get the same result on host machine and container when running this PS script:
gci HKLM:\Software\Classes -ea 0| ? {$.PSChildName -match '^\w+.\w+$' -and
(gp "$($.PSPath)\CLSID" -ea 0)} | ft PSChildName
The application shows up just like any other. The details show up fine when querying by AppID. LocalServer32 points to the correct EXE:
Some other things I tried:
Querying registry keys. There are 7 keys created when installing our software. These appear identical on host machine install and container install.
Even though permissions appear fine, I still tried logging into the container as alternate users. For example "nt authority\system" is another virtual admin user. I also changed the password of the "builtin\administrator" user to enable logging in with that one. Lastly tried creating new users entirely and adding them to the Administrators user group. All these attempts had the same errors as "builtin\containeradministrator" (default user).
A minor check was ensuring CMD.exe / Powershell is running as x64:
Re-registering the DLLs associated with the installation using regsvr32.
Starting from different base images. https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images. The full Win Server base image behaves exactly the same way regarding errors. The smaller Win Server Core base image is even more problematic, as I can't even start the app's EXE manually using that base. Lastly I tried other tags of the full Windows base image such as 20H2 and 2004. Same result from those. Multiarch or x64 makes no difference.
Included the "Ogawa hack" which was historically needed to make MS Office apps function correctly with COM: https://stackoverflow.com/a/1680214/7991646. It could be necessary for other COM apps too, but didn't help with my specific installation.
Is there anything else I can do to diagnose or solve this COM issue?
There are several things to consider:
The Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
The When CoCreateInstance returns 0x80080005 (CO_E_SERVER_EXEC_FAILURE) page describes possible reasons.
If many COM+ applications run under different user accounts that are specified in the This User property, the computer cannot allocate memory to create a new desktop heap for the new user. Therefore, the process cannot start. See Error when you start many COM+ applications: Error code 80080005 -- server execution failed for more information.
Finally, you may find a similar thread here helpful, see Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
I have created an action to shut down several processes. Why? I am using Dragon Pro voice-to-text and Voice Computer in my adaptive technology stack. Unfortunately, the former crashes regularly, and when this happens, it doesn't shut down cleanly. I have the following action in Windows Power Automate, using this trick to listen for a shortcut key.
I tried targeting each process by its ID, but it seems that the ID changes each time the process runs a new. So then I tried by process name, but that doesn't seem to work. How do I properly target these processes?
Can I suggest using a PowerShell script? Using PAD seems like a bit of overkill to achieve such a thing but I guess if it's baked into your entire solution then this will work nicely and we all know there is an action within PAD to run a PowerShell script.
$processes = Get-Process
Foreach ($process in $processes) {
if ( $process.Name -eq "natspeak" ) {
Stop-Process -Name $process.Name
}
}
I am facing an issue with Java SDK 3, after performing some operations i.e creating and deleting documents from kuzzle, it hangs and does not respond.
I investigated the issue and found that CPU utilization of my java service (which is making Web Sockets connection with Kuzzle) is spiking to 100%.
Is it a normal behavior or I am missing some WebSocketOptions or KuzzleOptions setting?
I am using kuzzle over ssl
WebSocketOptions opts = new WebSocketOptions();
opts.setPort(443);
opts.setSsl(true);
opts.setAutoReconnect(true);
opts.setConnectionTimeout(42000);
WebSocket ws = new WebSocket(host, opts);
KuzzleOptions kuzzleOptions = new KuzzleOptions();
// Instantiates a Kuzzle client
kuzzle = new Kuzzle(ws, kuzzleOptions);
// Connects to the server.
kuzzle.connect();
System.out.println("Connected!");
You should use the version 3.0.1 of the Java SDK, it fixes this issue https://github.com/kuzzleio/sdk-java/releases/tag/3.0.1
I am using foreverjs within my electron app main like so:
const forever = require("forever-monitor");
let child = forever.start(scriptPath, {fork: true});
I am doing this intentionally over using child_process.fork because I want foreverjs to monitor the forks and restart them when needed.
Well - the above works, but looking at my dock on mac osx, I see that the electron app is duplicated for each fork. In production it is the same -- the app icon get's duplicated N times in the Dock for each process.
Investigating further I found the cause but not the solution. The cause is that when you fork a process normally using child_process from within electron, it launches it using the Electron Helper app.
However when you fork a process using forever.js it uses the Electron app itself, thus explaining the duplicates.
How do I force forever to use the Electron Helper app when forking and not the Electron app itself?
OK, so I figured it out. Quite simply you need to pass one environment variable to foreverjs like so:
const forever = require("forever-monitor");
let child = forever.start(scriptPath, {fork: true, env: {ELECTRON_RUN_AS_NODE: 1}});
Doing this and the fork will correctly use its prepackaged version of node instead of launching another copy of electron "main".
I'm using Hangfire in my MVC webapp. I configured it this way:
GlobalConfiguration.Configuration
.UseMongoStorage(mongoConnectionString, mongoDatabaseName);
app.UseHangfireServer();
When I run the application I see IIS Worker Process takes constantly almost 40% CPU.
Removing it brings the application to works normally.
What's wrong?
Hangfire.Mongo since version 0.2.2 uses a new version of the mongocsharpdriver package that migrated to async API when talking with Mongo. Hangfire still uses synchronous methods, and looks like there is an error in "sync over async" wrapper.
One user reported that after setting the following options everything is fine.
CountersAggregateInterval = TimeSpan.FromMinutes(5);
JobExpirationCheckInterval = TimeSpan.FromHours(1);
However, the fix isn't available currently, and another option is to downgrade the Hangfire.Mongo package to the previous version. Please see the related GitHub issue.