Changelog URL (local network path) - No longer works in version 1.7.5

[cthrockmorton]

To whom it may concern,

The changelog element is no longer working for me in v1.7.5. I updated from v1.7.0, which works fine. I'm using a local URL path.

These are the elements I'm using in my AutoUpdater.xml file:

url element: file:https://///192.168.140.69/ShowcaseMAP_Update/220916_v3.10.22259.1_ShowcaseMAP.zip
changelog element: file:https://///192.168.140.69/ShowcaseMAP_Update/ReleaseNotes.htm
mandatory element: true

NOTE: I couldn't copy the XML code directly into this post, because it kept changing the formatting, so I just listed the element names and the values I'm using.

I have local URL paths configured in my AutoUpdater.xml file and these have been working all along since I started using AutoUpdater.NET quite some time ago.

I just updated to v1.7.5, because I saw there was an update, but I'm now getting an error "The path is not of a legal form." when I run the application.

I figured out that this is an issue with the changelog element, because if I remove the changelog element, AutoUpdater works with no issue.

So, the url element is working with the local URL, but the changelog element with the local URL is not.

Is there some other format for the local URL string that I should be using to get this to work?
Is this a bug in the AutoUdpater.NET version 1.7.5?
Is using a local URL for the changelog element no longer supported?

Please help, thanks!

Best regards,
Christopher T

[ravibpatel]

Are you using Windows file sharing to access those files?

[cthrockmorton]

Hi Ravi,

Thanks for your reply.

Yes, I am using Windows file sharing on the network to access the update folder.

The share is located on the network here: \192.168.140.69\ShowcaseMAP_Update

I've temporarily rolled back to v1.7.0 and it's working fine. I'm not sure what version it breaks in. I haven't tried v1.7.1 through v1.7.4. I had jumped right to v1.7.5, which is where I found that it's not working anymore.

Just to reiterate, the URL element is working fine in v1.7.5. The changelog element is what isn't working anymore.

Hey also, is it possible to add images to the changelog? I tried adding a PNG file and it didn't work. Just curious. Thanks!

Thanks for your help Ravi. I apprecaite it!

Best regards,
Christopher T

[Squall-Leonhart]

This is indeed broken beyond 1.7.0, it doesn't work with our Github XML path @ https://github.com/TexTools/FFXIV_TexTools_Updater/blob/master/updater.xml

Reverted to 1.7.0 and all is well again.

Looks to be this change specifically
v1.7.0...v1.7.1#diff-08879702a8a07e7a24fac0e537044a20ca3e5da0bc0ade7f7a47715ccfaca121L82

[ravibpatel]

@cthrockmorton I tried it with local XML and changelog file, and it does work for me.

@Squall-Leonhart I tested it with GitHub URL "https://raw.githubusercontent.com/TexTools/FFXIV_TexTools_Updater/master/updater.xml" and it does show changelog for me.

[Squall-Leonhart]

the fallback to the non-webview2 code doesn't work.

[ravibpatel]

@Squall-Leonhart Does it show any error?

[Squall-Leonhart]

@Squall-Leonhart Does it show any error?

No exception raised or printed to Event Viewer, the Changelog window just fails to appear so users aren't notified of an available update.

Our code, seperated

        private bool _UPDATING = false;
        private void AutoUpdater_ApplicationExitEvent()
        {
            _UPDATING = true;
        }
        public MainWindow(string[] args)
        {
            _mainWindow = this;

            AutoUpdater.ApplicationExitEvent += AutoUpdater_ApplicationExitEvent;

            // Forcefully assign the correct working directory.  This helps keep the 
            // AutoUpdater from choking.
            var cwd = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetEntryAssembly().Location);
            Directory.SetCurrentDirectory(cwd);

            CheckForUpdates();

            // This slightly unusual contrivance is to ensure that we actually exit program on updates
            // *before* performing the rest of the startup initialization.  If we let it continue
            // some odd things can result.

            // In particular, threads can be spawned that may keep the application files locked when 
            // the updater wants to replace them, and/or new installs can error out on the culture info
            // lines below, due to not having valid settings after Application.Shutdown() was already called.
            if(_UPDATING)
            {
                // Shut down any other copies of TexTools that are active.
                MainWindow.MakeHighlander();

                if (Application.Current != null) { 
                    Application.Current.Shutdown();
                }
                return;
            } else
            {
                // No updates needed? We can clear out the update path then.
                var updateDir = Path.Combine(Environment.CurrentDirectory, "update");
                Directory.Delete(updateDir, true);
            }

        public static void CheckForUpdates()
        {
            AutoUpdater.Synchronous = true;
            var updateDir = Path.Combine(Environment.CurrentDirectory, "update");
            Directory.CreateDirectory(updateDir);
            AutoUpdater.DownloadPath = updateDir;
            try
            {
                if (IsBetaVersion)
                {
                    AutoUpdater.Start(WebUrl.TexTools_Beta_Update_Url);
                } else
                {
                    AutoUpdater.Start(WebUrl.TexTools_Update_Url);
                }
            } catch
            {
                AutoUpdater.Start(WebUrl.TexTools_Update_Url);
            }
        }

[ravibpatel]

@Squall-Leonhart I deliberately set "webView2RuntimeFound" variable to false before this line. That trigger usage of older WebBrowser control, but it did work for me. I also changed the URL that points to your XML file in the test application and set Synchronous to true, but still can't reproduce the issue. I am using latest version of Windows 11. If it is possible, please load the project directly into your solution and try to reproduce the issue. You may be able to pinpoint the issue by debugging it. You can find instructions for it here.

[Squall-Leonhart]

So the fallback doesn't account for the App using autoupdater.net not having webview2 support, in this case the conditions for "webView2RuntimeFound" are met and returns true as the system has a system webview2 version above 86.0.616.0 but a fallback for a lack of supporting dotnet assemblies (and implementation that can use them) is not taken into consideration?

[ravibpatel]

It uses standard WebBrowser control when there is no WebView2 support, so it should work even if your system doesn't have WebView2 Runtime.

[Squall-Leonhart]

Updated to 1.7.7, it now just works? o.O

1.7.1 > 1.7.5 fails silently whether or not the webview files are present
1.7.6 fails silently if they aren't, throws errors if they are, adds and includes webview2.core,winform and wpf files and WebView2Loader.dll (exception is can't load module WebView2Loader.dll / not found)