Lurgle.Transfer now supports SMB; Lurgle.Alerting, Lurgle.Dates, Lurgle.Logging, EventX Trilogy, and other apps updated!

Update bonanza!

I've recently worked to update dependencies in almost all of my apps, so there are quite a few new versions to check out. Many of these depend on one or more of the Lurgle libraries, so it's logical that when I update the libraries, I also update the apps.

After posting this, Lurgle.Logging was also updated with a quick enhancement that includes a new configuration, IncludeSourceFilePath. This boolean config allows the automatically captured source file path to be filtered to only the filename if set to False.

This can be set in the app.config or via the constructor, and will default to True if not set.

This is particularly useful if you want to include the SourceFile property in file logging!

Lurgle.Transfer - adding SMB transfers

In the case of Lurgle.Transfer - I have added SMB1, SMB2, and SMB3 as a TransferMode, using the cross-platform SMBLibrary for client access to Windows/Samba shares. This means that Windows integrated authentication isn't available (at least at this stage) - but it also means that this should work for non-Windows implementations.

The addition of SMB to Lurgle.Transfer means that there is more capability around chaining multiple transfers. For example - download some files from a Windows share, download other files from SFTP, and then upload all files via FTP. 

As this is abstracted behind the FileTransfer.Connect(), FileTransfer.ListFiles, FileTransfer.DownloadFile(s), and FileTransfer.SendFile(s) calls, you can reliably process SFTP, FTP, or SMB transfers with the same calls. 

For the purpose of TransferMode.Smb2 and TransferMode.Smb3 - these are functionally the same when calling SMBLibrary, and are only provided to reflect that SMB3 shares are totally supported as well.

The library supports the legacy Netbios over TCP (port 135) and the more common SMB over IP (port 445) ports, and this is controlled using the existing port configuration. For the purpose of the Lurgle.Transfer implementation, an invalid port initially defaulted to Netbios over TCP, but after further consideration, I've just pushed an update that will make it use SMB over IP.

A sample of implementation for an upload to \\SERVERNAME\Upload\smbtest using the constructor config method would be:

var destinations = new Dictionary<string, TransferDestination>
{
{"Test",
new TransferDestination(name: "Test", transferType: TransferType.Upload,
transferMode: TransferMode.Smb3, destination: "Test", authMode: TransferAuth.Password, server: "SERVERNAME", port: 445, userName: "FtpTest", password: "Password1",
remotePath: "upload\smbtest", sourcePath: "C:\\Transfer\\Upload", doArchive: true, archivePath: "C:\\Transfer\\Archive", archiveDays: 30)}
};
            
Transfers.SetConfig(new TransferConfig(transferDestinations: destinations));
Transfers.Init();
var ftransfer = new FileTransfer(destinations["Test"]);
var files = Files.CompressFiles(ftransfer.TransferConfig, CompressType.Gzip);
ftransfer.Connect();
ftransfer.SendFiles(files.DestFiles, true, true);
ftransfer.Disconnect();
Files.DeleteCompressedFiles(ftransfer.TransferConfig, CompressType.Gzip, files.DestFiles);
Files.CleanArchivedFiles(ftransfer.TransferConfig);
Files.ArchiveFiles(ftransfer.TransferConfig);

As with all other transfers, the result of each operation can be captured and examined for monitoring, alerting, and logging. 

Lurgle.Alerting - upstream dependency updates

For Lurgle.Alerting, I examined the upstream dependencies from FluentEmail, and found that some were quite out of date with some pending pull requests to permit dependency updates where the code needed changes for Liquid templates. 

To bring all upstream dependencies up to date, I created a fork of FluentEmail and merged the required pull requests so that I could create a coherent build with up to date dependencies. The intent isn't to publish the separate fork, though. As I had previously done with FluentEmail.Handlebars to permit supporting other framework versions, I integrated the code for the following renderers and senders directly into Lurgle.Alerting:

• FluentEmail.MailKit
• FluentEmail.Liquid
• FluentEmail.Razor

The intent isn't to diverge from the FluentEmail codebase, so I expect to revert this to using the FluentEmail codebase in future after the necessary changes are merged. I plan to send a fresh pull request with the dependency updates to FluentEmail for review.

This does mean, however, that Lurgle.Alerting is now able to leverage the current releases of upstream dependencies such as RazorLight, Fluid, and MailKit.

Lurgle.Dates - bug fix / behaviour change

As we rolled around to February, I couldn't help but notice that Lurgle.Dates had a weakness if a specific day (eg. 31) was passed in a shorter month to the Dates.GetUtcDaysOfMonth or Dates.GetDaysOfMonth methods. The private GetDayType method would attempt to parse an invalid date and return an exception, rather than simply returning no match.

This is typically an edge case since you can just pass "last" as a date expression if you want the last day of the current month included.

This now behaves as expected - if you're using a day expression with a specific day (eg. 31) in February, GetDaysOfMonth will return without this invalid day.

EventX Trilogy - Seq.App.EventTimeout, Seq.App.EventThreshold, Seq.App.EventSchedule

It was while performing dependency updates for these 3 that I noted the weakness in Lurgle.Dates, specifically via the unit tests for Event Schedule. This meant, of course, that an update to all 3 would be needed to incorporate both the dependency updates and consideration around the changed behaviour in Lurgle.Dates. 

Essentially - the Seq config for Event Timeout, Event Threshold, and Event Schedule will permit you to pass 31 as an "include" day, but because the 31st February is invalid, this would have resulted in an application error. Following the change - if the only configured include day was 31, this would mean that on months where the 31st was invalid, the apps would have assumed "ALL" days should execute, rather than "NONE". 

I changed the behaviour so that it will now detect that a value was configured in the Include Days of Month setting, but that no days of month were returned. If this should happen, the EventX apps will now calculate a day of month that falls in the past, so that the expected behaviour occurs (eg. the schedule will not execute within the current month).

Update now!

The apps page has all of my apps, with most of them having had simple dependency updates, and the Seq apps will automatically show up as having updates in Seq - but for the apps called out in this post, have some handy links!

Lurgle.Transfer
Lurgle.Alerting
Lurgle.Dates
Lurgle.Logging
Seq.App.EventTimeout
Seq.App.EventThreshold
Seq.App.EventSchedule