ParseUpdateInfoEvent prevents default XML deserialization when no custom parsing is intended

[shuwaki]

Summary

When a handler is attached to AutoUpdater.ParseUpdateInfoEvent — even if only for logging or inspection — the built-in XML deserialization logic is bypassed, causing UpdateInfoEventArgs to remain null unless the handler explicitly assigns it. This can lead to silent update failures or exceptions.

Steps to Reproduce

Attach an empty or logging-only handler to ParseUpdateInfoEvent.

Call AutoUpdater.Start(updateXmlUrl).

Observe that args.UpdateInfo is null and update check fails.

Expected Behavior
If the handler does not assign args.UpdateInfo, AutoUpdater.NET should still fall back to its internal XML parsing logic.

[ravibpatel]

This is intended behavior. You should only provide the handler to ParseUpdateInfoEvent if you intend to parse and return the data. You can't use it for logging. Is there are reason for logging the output of the returned XML?

[shuwaki]

Yes, to inspect it, like I did when I noticed the bug. Even though it's expected behavior it wouldn't hurt to have the fallback. I can share my fix in a PR

[ravibpatel]

I think the current behavior is fine for now. In production, we usually don’t need to log the request, so debugging should still be possible without any changes. If more people find this useful, or it gets more traction, we can definitely consider adding it later.