Add Add-SentryEventProcessor cmdlet for custom event processors

[jamescrosswell]

There's no clean public API for registering an event processor. To do it today, a user has to write a PowerShell class deriving from an internal C# base type (SentryEventProcessor_) and then register this with options.AddEventProcessor from inside Start-Sentry.

sentry-powershell/modules/Sentry/private/SentryEventProcessor.cs

Lines 1 to 5 in 7818d05

	// This is an abstract class for any PowerShell event processors. It gets around an issue with Windows PowerShell
	// failing to compile scripts that have a method name `Process`, which is a reserved word.
	// https://stackoverflow.com/questions/78001695/windows-powershell-implement-c-sharp-interface-with-reserved-words-as-method-n/78001981
	// This way, we can keep the PowerShell implementation of the event processor, with access to System.Management.Automation, etc.
	public abstract class SentryEventProcessor_ : Sentry.Extensibility.ISentryEventProcessor

In #27 Ivan proposed we add Add-SentryEventProcessor taking a scriptblock, wrapped internally by a C# class that implements ISentryEventProcessor directly. Could be used like so:

Add-SentryEventProcessor {
    if ($_.Message -match 'secret') { return $null }
    $_.SetTag('host', $env:COMPUTERNAME)
    $_
}

Nice-to-have follow-on: migrate the two existing built-in processors (EventUpdater, StackTraceProcessor) onto the same mechanism so the PowerShell class files in modules/Sentry/private/ can be deleted. This also eliminates the Process-keyword constraint on the internal architecture.

PR #130 implements both pieces.

[linear-code]

POWERSH-12

[vaind]

That's surprising - when did you encounter this? I've never seen this personally. Also not present in CI logs https://github.com/getsentry/sentry-powershell/actions/runs/23848934882/job/69523457650

[jamescrosswell]

That's surprising - when did you encounter this?

I bumped into it yesterday when trying to run the new sample I'd but together (same behaviour with the other existing sample) on my mac. I saw you'd already made a comment on it in #27 :

event processors - it's a pain to add to Windows Powershell due to the conflict with the Process keyword. Internally, we have a c# class that changes the call to DoProcess but modules don't really work well with exporting classes. Alternatively, we could have a Add-SentryEventProcessor which would take a scriptblock argument and we would wrap that in our internal EventProcessor implementation.

At least I think your comment relates to the same thing.

I had Claude put a PR together yesterday to address it, which I haven't had time to look through yet and check/understand. It looks like a fairly substantial PR though so will definitely sanity check with you if/when it looks like we might want to merge that. I'm far from a Powershell expert (I think I've generally resisted it and all it's weird syntax - but maybe it will win me over one day).

[jamescrosswell]

That's surprising - when did you encounter this? I've never seen this personally. Also not present in CI logs https://github.com/getsentry/sentry-powershell/actions/runs/23848934882/job/69523457650

Possibly Claude misdiagnosed this... it might be a side effect of this:

sentry-powershell/modules/Sentry/private/Get-SentryAssembliesDirectory.ps1

Lines 12 to 18 in 7818d05

	if ($PSVersionTable.PSVersion -ge '7.5') {
	return 'net9.0'
	} elseif ($PSVersionTable.PSVersion -ge '7.4') {
	return 'net8.0'
	} else {
	return 'net462'
	}

On my machine I have:

$PSVersionTable.PSVersion    

Major  Minor  Patch  PreReleaseLabel BuildLabel
-----  -----  -----  --------------- ----------
7      6      0                      

@vaind if you've still only got PS 7.5 installed, that would explain why you're not seeing the same warnings I am (and why we're not seeing any issues on CI).

I've updated the title/description on this issue to dial it back to just what you had in your original TODO and we can deal with correctly matching more recent versions of PS to .NET in #125 - looks like there's already an automatically generated PR for this which needs a bit of TLC:

• chore(deps): update Dotnet SDK to v6.5.0 #109