How can we help you today? How can we help you today?
Jon Kirkwood
It can sometimes take a while for objects to appear in the search parameters.  You can force an update of the index by selecting Index > Reindex (CTRL + ALT + D) This will refresh SQL Prompt and search for newly created or modified objects [image] / comments
It can sometimes take a while for objects to appear in the search parameters. You can force an update of the index by selecting Index > Reindex (CTRL + ALT + D)This will refresh SQL Prompt and sear...
0 votes
Hi PradnayaN,  Thanks for reaching out on the Redgate forums. This sounds like an issue with obfuscating assemblies that are involved in reflection, dependency injection, or are entry points.  We recommend starting with minimal obfuscation settings and excluding the main assembly and any shared contracts or reflection-heavy code to ensure runtime stability.   Here are some initial steps to try first to see if you can clear your issues with obfuscation Don't Obfuscate Entry Point or Shared Contracts Exclude: Program.dll or main project. Any shared interfaces or base class libraries (used in reflection or dependency injection). DTOs, gRPC contracts, Razor components, etc. ➜ Use [DoNotObfuscate] or SmartAssembly project file filters. Turn Off Type/Method Renaming for Reflection-Heavy Code If you use: Dependency Injection Reflection JSON serialization/deserialization ➜ Obfuscated names won’t match expected strings. Fix: Add [Obfuscation(Exclude = true)] or exclude via SA project rules. Assembly Load Failures? If your app dynamically loads assemblies, you must not obfuscate public types or names unless explicitly handled. ➜ Check AppDomain.AssemblyResolve or plugin patterns. Use Debug Logs or Fusion Log Viewer Might help to catch missing method/assembly load failures. Minimal Working Obfuscation Start with: <Obfuscation NameMangling="0" FieldsNameMangling="0" /> Then incrementally raise levels after testing that the previous setting worked.  / comments Official comment
Hi PradnayaN, Thanks for reaching out on the Redgate forums.This sounds like an issue with obfuscating assemblies that are involved in reflection, dependency injection, or are entry points. We reco...
0 votes
Hi emmar00,    Thank you for reaching out on the Redgate forum regarding your Redgate Monitor alert suppression question.   I did some testing today and found the following: It does depend on how you have your suppression window configured as to which alerts are suppressed My testing was conducted with all alerts suppressed & alerts and notifications suppressed to cover all scenarios. [image]   Alerts raised before a suppression window but ended during - Alert raised, and an initial alert notification is sent; no notification is issued when the alert has ended. The alert is tracked in Monitor and has a status of Ended.    Alerts raised during and ended during a suppression window - No alert is raised, no alert notifications are sent out There is no alert created in Monitor.   Alerts raised during a suppression window and ended after - Alert raised after suppression window and backdated to the computed alert start time. This does not raise an initial alert notification and alert status is set to Active An alert is raised and has a status of Active. This may clear automatically, but ideally needs to be manually reviewed and cleared.   In the third situation, as there is no initial notification that the alert is created, it appears to stay in an open/active status so it may be reviewed.  A new notification can be manually issued and then checked before it is marked as cleared.  This helps verify that any persistent alerts are accounted for after the suppression window has completed. / comments Official comment
Hi emmar00,  Thank you for reaching out on the Redgate forum regarding your Redgate Monitor alert suppression question. I did some testing today and found the following: It does depend on how you h...
0 votes