VBoxManage.exe: error: Error in (line 120) — Invalid value ‘VBOXSVGA’ in Display/@controller attribute.
Kann offenbar passieren, wenn eine VM unter Linux erstellt und dann unter Windows gestartet wird. Lösung: Die .ovf-Datei der VM öffnen, und
|
1 |
<Display controller="VBoxSVGA" VRAMSize="128"/> |
in
|
1 |
<Display VRAMSize="128"/> |
ändern. Beides von hier.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Add-Type @" using System.Net; using System.Security.Cryptography.X509Certificates; public class TrustAllCertsPolicy : ICertificatePolicy { public bool CheckValidationResult( ServicePoint srvPoint, X509Certificate certificate, WebRequest request, int certificateProblem) { return true; } } "@ [System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy Invoke-WebRequest 'https://127.0.0.1:8444/my/endpoint' -OutFile 'c:\response.json' |
via. PS, in einem Vagrantfile so zu escapen – man beachte auch die Einrückungen:
|
1 2 3 4 5 6 7 |
config.vm.provision "disable cert validation callback", type: "shell", inline: <<-SHELL Add-Type @" ... "@ [System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy Invoke-WebRequest 'https://127.0.0.1:8444/my/endpoint' -OutFile 'c:\\response.json' SHELL |
HTH
Wenn Windows Server 2016 immer 0% Fortschritt anzeigt, dann kann man davon ausgehen, dass er nix runterlädt. Auch wenn die Liste der noch verfügbaren Updates sich dabei ständig ändert 🙄
Lösung: Offenbar laufen Windows Updates über “WinHTTP“, und selbstverständlich hat WinHTTP seine eigenen Proxy-Einstellungen. Man kann aber die IE-Einstellungen importieren:
|
1 |
netsh winhttp import proxy source=ie |
, danach neu starten, klar. Den Rechner oder nur den Service (per PowerShell):
|
1 |
Restart-service wuauserv |
Ein
|
1 |
netsh winhttp show proxy |
sollte dann die importierten Proxyeinstellungen zeigen.
In Ubuntu 18.04 gibt es ein “Feature” aus Windows 10: Klicke ich im Dock auf ein Icon einer Anwendung mit einem Fenster, komme ich zu dem Fenster. Klicke ich auf ein Icon mit mehreren Fenstern, öffnet sich eine “Vorschau” dieser Fenster. Das ist extrem disruptiv, weil ich nie sicher sein kann, ob ich nun zur Anwendung komme oder nicht. Zum Glück kann man es wenigstens deaktivieren:
|
1 |
gsettings set org.gnome.shell.extensions.dash-to-dock click-action 'cycle-windows' |
Einen Überblock über die möglichen Optionen bietet
|
1 2 3 4 5 6 7 8 9 |
crusy@HAL:~$ gsettings range org.gnome.shell.extensions.dash-to-dock click-action enum 'skip' 'minimize' 'launch' 'cycle-windows' 'minimize-or-overview' 'previews' 'quit' |
Angenommen, ich möchte JAVA_HOME setzen und %PATH% um %JAVA_HOME%/bin ergänzen, habe aber keine Adminrechte. JAVA_HOME kann ich setzen, das überschreibt ggf. gesetzte globale Variablen mit demselben Namen. Aber ein User-PATH wird hinter den globalen PATH gehängt, und überschreibt dadurch nix.
Lösung (nur für die CMD!):
|
1 2 |
reg add "HKCU\Software\Microsoft\Command Processor" /v AutoRun ^ /t REG_EXPAND_SZ /d "%"USERPROFILE"%\init.cmd" /f |
%PATH% hinter meinen):|
1 2 |
SET JAVA_HOME=C:\jdk-11.0.2+7-jre SET PATH=%JAVA_HOME%\bin;%PATH% |
tl;dr: MajorUpgrade ab der initialen Version!
Folgendes Szenario: Ich baue mit WiX einen MSI-Installer für meine Software. Die Software hat die Version 1.0. Nun möchte ich meine Software auf v1.1 upgraden. Was tun?
WiX bietet mehrere Möglichkeiten, namentlich “Major Upgrades”, “Minor Upgrades”, sowie “Small Updates”, die sich ungefähr so definieren:
Liest sich, als würde man meistens ein Minor Upgrade wollen. Internet sagt allerdings das Gegenteil, die Literatur* sieht Major Upgrades als “easier to implement than any other option” an, und last but not least empfiehlt WiX selbst:
When creating an .msi-based installer, you are strongly encouraged to include logic that supports Windows Installer major upgrades.
Was dabei nie so richtig, richtig klar wird (teilweise wird implizit das Gegenteil angedeutet): Beinhaltet nicht bereits Version 1.0 MajorUpgrade (sondern bspw. erst das erste Upgrade), dann funktioniert quasi nichts:
MajorUpgrade enthielt, wird von Upgrade/Downgrade-Logik komplett ignoriert!Warum das dann nicht mandatorisch ist, wird wohl Microsofts Geheimnis bleiben.
*Nick Ramirez, “WiX 3.6: A Developer’s Guide to Windows Installer XML”, Seite 342
Per default deinstalliert ein MajorUpgrade die alte Version und installiert dann die neue. Das kann problematisch sein, denn ein Upgrade (engl. für “Verbesserung”, “Aufrüstung”!) sollte ja bspw. Konfigurationsdaten usw. behalten. Da hilft das Scheduling-Attribut:
|
1 |
<MajorUpgrade Schedule="afterInstallExecute" DowngradeErrorMessage="A newer version of [ProductName] is already installed."/> |
sorgt dafür, dass bestehende Dateien (und in diesem Fall auch Services) erhalten bleiben. Es wird quasi definiert, wann das bestehende Produkt entfernt werden soll, und afterInstallExecute sagt “nach der Installation des Upgrades” – natürlich wird dann nur noch entfernt, was in v1.1 nicht mehr benötigt wird.
Achtung: Das setzt offenbar die Erkennung außer Kraft, die eine Neuinstallation derselben Version verhindert 🙄
Bestimmte Schritte des Installers sollen nur bei Erstinstallation ausgeführt werden (etwa die Konfiguration durch den User, die Installation eines Services, …). Dafür gibt es Conditions, bzw. verschiedene States, auf die man prüfen kann – und das ist ziemlich unübersichtlich. Ich beschränke mich an dieser Stelle auf einen Stackoverflow-Post, der gute, sprechende Aliase definiert:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<SetProperty After="FindRelatedProducts" Id="FirstInstall" Value="true"> NOT Installed AND NOT WIX_UPGRADE_DETECTED AND NOT WIX_DOWNGRADE_DETECTED </SetProperty> <SetProperty After="SetFirstInstall" Id="Upgrading" Value="true"> WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL") </SetProperty> <SetProperty After="RemoveExistingProducts" Id="RemovingForUpgrade" Sequence="execute" Value="true"> (REMOVE="ALL") AND UPGRADINGPRODUCTCODE </SetProperty> <SetProperty After="SetUpgrading" Id="Uninstalling" Value="true"> Installed AND (REMOVE="ALL") AND NOT (WIX_UPGRADE_DETECTED OR UPGRADINGPRODUCTCODE) </SetProperty> <SetProperty After="SetUninstalling" Id="Maintenance" Value="true"> Installed AND NOT Upgrading AND NOT Uninstalling AND NOT UPGRADINGPRODUCTCODE </SetProperty> |
Ein Kind von Component sollte immer KeyPath="yes" gesetzt bekommen. Selbst, wenn es nur ein Kind gibt, aber insbesondere bei mehreren. Daran wird entscheiden, welches die maßgebliche Datei ist, die vorhanden (und aktuell) sein muss, um “muss (re-)installiert werden” zu entscheiden.
Internet über WLAN? VNC über LAN? Browser bekommt keine Verbindung, weil LAN höher priorisiert wird als WLAN? Dem kann abgeholfen werden:
hth
Wer sich mittels Remmina zu macOS (hier: Mojave) verbinden möchte, und immer die Meldung
[VNC] TRUE colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
[VNC]VNC server closed connection
bekommt
, der sollte die Farbtiefe auf 24 bit setzen:
|
1 2 3 4 5 6 7 8 9 10 11 |
@ECHO OFF ECHO Looking for *.xml files... SET /a count=0 FOR /F "delims=" %%i IN ('dir/s/b/a-d ".\*.xml"') DO ( ECHO Processing %%i SET /a count=count+1 ) ECHO Processed %count% files PAUSE |
Nachdem ich mich neulich über sc gefreut habe: net ist cooler. Während
|
1 |
sc start HelloWorld.exe |
meinetwegen auch über’s Netzwerk möglich ist, wartet
|
1 |
net start HelloWorld.exe |
dafür, bis der Service auch läuft. Und, mal ehrlich, in einem Skript ist das das deutlich häufiger benötigte. Und so spart man sich nerviges Drumherumgebastel.