What changed
2.0.0.13 is the same VETS.exe as 2012, with CLR 4 enabled in VETS.exe.config,
form DLLs written under LocalAppData\Omega\CR3 (not inside the ClickOnce cache),
x86 WebView2Loader.dll + managed WebView2 next to the EXE, ClickOnce
manifests rebuilt, and signed CN=V.E.T.S. WinClient (self-signed).
Old 2.0.0.6 files are still on disk. The 2012 bootstrapper is
setup.exe (do not use for this test).
Do not launch a saved VETS.application
The 2026-09-12 log started from C:\Misc\clips\VETS.application.
That local file is a stale subscription. Delete it. Then uninstall VETS, run
rundll32 dfshim.dll,CleanOnlineAppCache, and open
VETS.application
from this page only. "Files corrupt in deployment" after a clips/Downloads
launch is that stale file plus a reused 2.0.0.8 cache, not a missing EXE on the server.
If reopen says "deployment identity does not match the subscription"
That is the 2012 install (Omega publicKeyToken 1ba8d128951c3c0a) asking
https://install.vets.ag/VETS.application for an update. Live 2.0.0.13 is a
new publisher (ea8746e25dec2d0a). ClickOnce cannot update across
publisher keys. Clicking OK keeps the old 2.0.0.6 — it did not install 2.0.0.13.
One-time fix: uninstall V.E.T.S. Practice & Business Management Tools from
Apps & features, then:
rundll32 dfshim.dll,CleanOnlineAppCache
Then open VETS.application
from this page (not a saved copy, not setup.exe, not the old Start Menu shortcut).
Loose-folder fallback (no ClickOnce):
VETSCLR4.zip
ยท VETSCLR4/VETS.exe
Forms no longer drop inside the ClickOnce package (0x800711C7)
2.0.0.13 still launches from this page as VETS.exe. A helper
assembly redirects downloaded forms to
%LOCALAPPDATA%\Omega\CR3\<service>\ instead of
Objects next to VETS.exe. Same shortcut. Same URL.
|