update fody

[taooceros]

I run the build and everything seems to work.

[github-actions[bot]]

@check-spelling-bot Report

:red_circle: Please review

See the :open_file_folder: files view or the :scroll:action log for details.

Unrecognized words (1)

fody

To accept :heavy_check_mark: these unrecognized words as correct and remove the previously acknowledged and now absent words, run the following commands

... in a clone of the [email protected]:Flow-Launcher/Flow.Launcher.git repository on the update_fody branch (:information_source: how do I use this?):

curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/main/apply.pl' |
perl - 'https://github.com/Flow-Launcher/Flow.Launcher/actions/runs/3833959472/attempts/1'

To have the bot do this for you, reply quoting the following line: @check-spelling-bot apply updates.

If the flagged items are :exploding_head: false positives

If items relate to a ...

• binary file (or some other file you wouldn't want to check at all).

  Please add a file path to the excludes.txt file matching the containing file.

  File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.

  ^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).

• well-formed pattern.

  If you can write a pattern that would match it, try adding it to the patterns.txt file.

  Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.

  Note that patterns can't match multiline strings.

[taooceros]

@check-spelling-bot apply updates.

[jjw24]

I run the build and everything seems to work.

@taooceros please list what everything includes e.g. booting it up in sandbox env or querying with Explorer plugin, because I also need to test this and I don't want to double up.

[taooceros]

I run the build and everything seems to work.

@taooceros please list what everything includes e.g. booting it up in sandbox env or querying with Explorer plugin, because I also need to test this and I don't want to double up.

Actually the only place we use fody is to trigger property changes. If fody doesn't work as expected, flow will be completely unusable so a very simple test suffices the job.

Explorer plugin even don't use fody, so we don't need to test it. I don't think sandbox is needed for this case.

[Yusyuriv]

I did some digging. Now, of course I could have missed or misunderstood something, but from what I found it doesn't seem like this update changes much besides bringing new features from PropertyChanged.Fody v4.x.x. This PR is a little outdated, I tested with Fody v6.8.0, not with v6.6.4 specified in this PR.

PropertyChanged.Fody is mentioned in dependencies of 3 projects:

Flow.Launcher

Used in the following files:

SelectFileManagerWindow.xaml.cs
HotkeyControl.xaml.cs (will be replaced soon)
SelectBrowserWindow.xaml.cs
ViewModel/PluginViewModel.cs
ViewModel/MainViewModel.cs
ViewModel/ResultViewModel.cs
ViewModel/ResultsViewModel.cs
ViewModel/SettingWindowViewModel.cs

Flow.Launcher.Plugin

Used in the following file:

PluginMetadata.cs

Flow.Launcher.Infrastructure

Used in the following files:

UserSettings/CustomBrowserViewModel.cs
UserSettings/CustomExplorerViewModel.cs
UserSettings/PluginHotkey.cs
UserSettings/PluginSettings.cs
UserSettings/Settings.cs

Flow.Launcher.Core project has the FodyWeavers.xml file, but doesn't have the dependency on Fody, so it doesn't do anything.

The only differences in the generated low-level C# I found (decompiled with JetBrains decompiler) were these:

• Updated library version in the generated attribute.

- [GeneratedCode("PropertyChanged.Fody", "3.4.0.0")]
+ [GeneratedCode("PropertyChanged.Fody", "4.1.0.0")]

• In some auto-generated setters, it now accesses the backing field directly, not with the getter. I found 16 places where this happens. As far as I can tell, it only happens when the getter is also autogenerated, so this doesn't change anything functionally.

- if (object.Equals((object) this.CustomExplorers, (object) value))
+ if (object.Equals((object) this.<CustomExplorers>k__BackingField, (object) value))

[taooceros]

I did some digging. Now, of course I could have missed or misunderstood something, but from what I found it doesn't seem like this update changes much besides bringing new features from PropertyChanged.Fody v4.x.x. This PR is a little outdated, I tested with Fody v6.8.0, not with v6.6.4 specified in this PR.

PropertyChanged.Fody is mentioned in dependencies of 3 projects:

Flow.Launcher

Used in the following files:

SelectFileManagerWindow.xaml.cs
HotkeyControl.xaml.cs (will be replaced soon)
SelectBrowserWindow.xaml.cs
ViewModel/PluginViewModel.cs
ViewModel/MainViewModel.cs
ViewModel/ResultViewModel.cs
ViewModel/ResultsViewModel.cs
ViewModel/SettingWindowViewModel.cs

Flow.Launcher.Plugin

Used in the following file:

PluginMetadata.cs

Flow.Launcher.Infrastructure

Used in the following files:

UserSettings/CustomBrowserViewModel.cs
UserSettings/CustomExplorerViewModel.cs
UserSettings/PluginHotkey.cs
UserSettings/PluginSettings.cs
UserSettings/Settings.cs

Flow.Launcher.Core project has the FodyWeavers.xml file, but doesn't have the dependency on Fody, so it doesn't do anything.

The only differences in the generated low-level C# I found (decompiled with JetBrains decompiler) were these:

• Updated library version in the generated attribute.

- [GeneratedCode("PropertyChanged.Fody", "3.4.0.0")]
+ [GeneratedCode("PropertyChanged.Fody", "4.1.0.0")]

• In some auto-generated setters, it now accesses the backing field directly, not with the getter. I found 16 places where this happens. As far as I can tell, it only happens when the getter is also autogenerated, so this doesn't change anything functionally.

- if (object.Equals((object) this.CustomExplorers, (object) value))
+ if (object.Equals((object) this.<CustomExplorers>k__BackingField, (object) value))

Oh what a detail review. Maybe we can go ahead with the update as you mentioned.