Event processors are awkward to add in this module, for two related reasons:
-
On Windows PowerShell, subclassing SentryEventProcessor directly conflicts with the Process keyword. The current workaround is an internal C# class that renames the call to DoProcess, but PowerShell modules don't export classes cleanly, so the subclasses live as PowerShell class definitions in modules/Sentry/private/.
-
PowerShell tries to resolve class base types at parse time, but SentryEventProcessor_ (and its descendants) are only constructed at runtime by assemblies-loader.ps1. The module recovers on a second pass and works, but every user sees these errors on first import of any sample:
```
ParserError: modules/Sentry/private/SentryEventProcessor.ps1:1
class SentryEventProcessor : SentryEventProcessor_ {
| Unable to find type [SentryEventProcessor_].
ParserError: modules/Sentry/private/StackTraceProcessor.ps1:1
class StackTraceProcessor : SentryEventProcessor {
| Unable to find type [SentryEventProcessor].
ParserError: modules/Sentry/private/EventUpdater.ps1:1
class EventUpdater : SentryEventProcessor {
| Unable to find type [SentryEventProcessor].
InvalidOperation: modules/Sentry/public/Start-Sentry.ps1:24
$options.AddEventProcessor([EventUpdater]::new())
| Unable to find type [EventUpdater].
```
We could avoid this by replace the existing PowerShell class definitions with an Add-SentryEventProcessor cmdlet that takes a `scriptblock` and wraps it in an internal C#-defined EventProcessor implementation. That would avoid the Process-keyword conflict and the parse-time base-type resolution, and silences the import-time errors for end users.
Event processors are awkward to add in this module, for two related reasons:
On Windows PowerShell, subclassing
SentryEventProcessordirectly conflicts with theProcesskeyword. The current workaround is an internal C# class that renames the call toDoProcess, but PowerShell modules don't export classes cleanly, so the subclasses live as PowerShellclassdefinitions inmodules/Sentry/private/.PowerShell tries to resolve class base types at parse time, but
SentryEventProcessor_(and its descendants) are only constructed at runtime byassemblies-loader.ps1. The module recovers on a second pass and works, but every user sees these errors on first import of any sample:```
ParserError: modules/Sentry/private/SentryEventProcessor.ps1:1
class SentryEventProcessor : SentryEventProcessor_ {
| Unable to find type [SentryEventProcessor_].
ParserError: modules/Sentry/private/StackTraceProcessor.ps1:1
class StackTraceProcessor : SentryEventProcessor {
| Unable to find type [SentryEventProcessor].
ParserError: modules/Sentry/private/EventUpdater.ps1:1
class EventUpdater : SentryEventProcessor {
| Unable to find type [SentryEventProcessor].
InvalidOperation: modules/Sentry/public/Start-Sentry.ps1:24
$options.AddEventProcessor([EventUpdater]::new())
| Unable to find type [EventUpdater].
```
We could avoid this by replace the existing PowerShell
classdefinitions with anAdd-SentryEventProcessorcmdlet that takes a `scriptblock` and wraps it in an internal C#-definedEventProcessorimplementation. That would avoid theProcess-keyword conflict and the parse-time base-type resolution, and silences the import-time errors for end users.