Unable to reference installer download via file:// type url

[holtt]

I am utilizing NetSparkle with .NET Framework 4.8 in an internal environment with no web server, so am relying on a windows file share and file://-type URLs.

I am able to host and access the appcast.xml as well as release notes files without issue. However when it comes to the actual installer item link (defined in ), I am unable to use a file:// link.

Specifically, this triggers the following error which cancels the update download...

netsparkle: Error: Only 'http' and 'https' schemes are allowed.

It would be nice if the download would support file://-type URLs for more versatility, specifically for localized non-web facing utilizations.

[Deadpikle]

Hi @holtt,

Thanks for the request. I think someone has implemented this on their own in the past, but you're right that there is no official implementation at this point. In the meantime, you can always implement your own IUpdateDownloader or whatever else is needed for your own use cases. :)

[Deadpikle]

@holtt,

There is an NOT TESTED OR TRIED WHATSOEVER version of IUpdateDownloader (LocalFileDownloader) and version of IAppCastDataDownloader (LocalFileAppCastDownloader) in version 2.2.0, which just rolled out. Please try it out and see if it works.

Like I said, I did NOT test this whatsoever. Use at your own risk. If it works, please let me know.

[eminsenay]

Hi @Deadpikle

Thanks for the classes. In my case all files I need are located on a remote smb folder. Because of this, I needed to do some minor modifications:

In LocalFileAppCastDownloader:

public string DownloadAndGetAppCastData(string url)
{
  Uri uri = new Uri(url);
  return File.ReadAllText(uri.LocalPath);
}

In LocalFileDownloader:

public async void StartFileDownload(Uri uri, string downloadFilePath)
{
  await CopyFileAsync(uri.LocalPath, downloadFilePath, _cancellationTokenSource.Token);
}

And the total file length you're returning is incorrect

using FileStream sourceStream = new FileStream(sourceFile, FileMode.Open, FileAccess.Read, FileShare.Read, num, options);
//...
long totalFileLength = sourceStream.Length;
//...
UpdateDownloadProgress(totalRead, totalFileLength);

You need to get the last change in any case; but for the others, I don't know if uri.LocalPath is always the correct option.

Btw until recently I was using version 2.0.11 which was functioning correctly with file uri scheme. I think in this version the WebRequestAppCastDataDownloader was still using GetWebContentResponse() internally, which is checking if the request is a FileWebRequest or HttpWebRequest. Probably a similar thing was also existing for the WebClientFileDownloader.

If this is not too much to ask, maybe you may bring the uri scheme check back to both classes and if the input has a file uri scheme call LocalFileDownloader and LocalFileAppCastDownloader automatically.

[Deadpikle]

@eminsenay

Thanks for your message and thorough reply on what needed to change to work for you. I went ahead and made the UpdateDownloadProgress fix (thanks for that), but I don't have time to research the other changes at this time. I think your suggestion to handle things via a uri scheme check is a good one.

I am gone for several weeks starting Wednesday and probably won't be able to address this further for quite some time. Feel free to follow up with anything else you learn or whatnot in the meantime. :)

[ALDamico]

Hello. Any ETA on when @eminsenay's changes might be implemented? I too have a need to host files on an SMB share and if a release isn't on the horizon I might have to roll my own implementation of that interface.

Thanks

[Deadpikle]

@ALDamico The fix that was needed was already implemented. For the uri.LocalPath use, I will add a bool flag that can let you more easily opt into that next week when I have time and will also make those methods virtual for easier overriding. Until then, you can simply copy+paste the code into your project, change the file/class name, and adjust the methods as needed, unless of course you can wait until it's ready.