From 1c7268d11850ea7182fc85b39954534d91916190 Mon Sep 17 00:00:00 2001 From: "Mark Wiemer (MSFT)" <80539004+mwiemer-microsoft@users.noreply.github.com> Date: Wed, 17 Jun 2026 15:50:19 -0700 Subject: [PATCH 1/2] Fix "one method" typo in csharp/modern-events.md --- docs/csharp/modern-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/csharp/modern-events.md b/docs/csharp/modern-events.md index 1503d8bfa8289..69b9864690a43 100644 --- a/docs/csharp/modern-events.md +++ b/docs/csharp/modern-events.md @@ -10,7 +10,7 @@ ms.subservice: fundamentals The previous article discussed the most common event patterns. .NET Core has a more relaxed pattern. In this version, the `EventHandler` definition no longer has the constraint that `TEventArgs` must be a class derived from `System.EventArgs`. -This increases flexibility for you, and is backwards compatible. Let's start with the flexibility. The implementation for uses a method defined in one method: , which creates a shallow copy of the object. That method must use reflection in order to implement its functionality for any class derived from `EventArgs`. That functionality is easier to create in a specific derived class. That effectively means that deriving from System.EventArgs is a constraint that limits your designs, but doesn't provide any extra benefit. In fact, you can change the definitions of `FileFoundArgs` and `SearchDirectoryArgs` so that they don't derive from `EventArgs`. The program works exactly the same. +This increases flexibility for you, and is backwards compatible. Let's start with the flexibility. The implementation for uses a method defined in : , which creates a shallow copy of the object. That method must use reflection in order to implement its functionality for any class derived from `EventArgs`. That functionality is easier to create in a specific derived class. That effectively means that deriving from System.EventArgs is a constraint that limits your designs, but doesn't provide any extra benefit. In fact, you can change the definitions of `FileFoundArgs` and `SearchDirectoryArgs` so that they don't derive from `EventArgs`. The program works exactly the same. You could also change the `SearchDirectoryArgs` to a struct, if you make one more change: From 49b425a6574e44e9615a3001231001d830eb648b Mon Sep 17 00:00:00 2001 From: Bill Wagner Date: Thu, 18 Jun 2026 11:35:19 -0400 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- docs/csharp/modern-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/csharp/modern-events.md b/docs/csharp/modern-events.md index 69b9864690a43..6c2e09c3760b7 100644 --- a/docs/csharp/modern-events.md +++ b/docs/csharp/modern-events.md @@ -10,7 +10,7 @@ ms.subservice: fundamentals The previous article discussed the most common event patterns. .NET Core has a more relaxed pattern. In this version, the `EventHandler` definition no longer has the constraint that `TEventArgs` must be a class derived from `System.EventArgs`. -This increases flexibility for you, and is backwards compatible. Let's start with the flexibility. The implementation for uses a method defined in : , which creates a shallow copy of the object. That method must use reflection in order to implement its functionality for any class derived from `EventArgs`. That functionality is easier to create in a specific derived class. That effectively means that deriving from System.EventArgs is a constraint that limits your designs, but doesn't provide any extra benefit. In fact, you can change the definitions of `FileFoundArgs` and `SearchDirectoryArgs` so that they don't derive from `EventArgs`. The program works exactly the same. +This increases flexibility for you and is backward compatible. Let's start with the flexibility. The implementation of uses a method defined in : , which creates a shallow copy of the object. That method must use reflection in order to implement its functionality for any class derived from `EventArgs`. That functionality is easier to create in a specific derived class. That effectively means that deriving from System.EventArgs is a constraint that limits your designs, but doesn't provide any extra benefit. In fact, you can change the definitions of `FileFoundArgs` and `SearchDirectoryArgs` so that they don't derive from `EventArgs`. The program works exactly the same. You could also change the `SearchDirectoryArgs` to a struct, if you make one more change: