Activity overview
Latest activity by 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...
Thank you for your patience whilst this has been worked on. Our developers have pushed a fix for this into an upcoming Prompt release. Please keep an eye out for this release in the SQL Prompt release notes https://documentation.red-gate.com/sp/release-notes-and-other-versions/sql-prompt-10-16-release-notes We would anticipate this to be part of release V10.16.10.a / comments
Thank you for your patience whilst this has been worked on.Our developers have pushed a fix for this into an upcoming Prompt release. Please keep an eye out for this release in the SQL Prompt relea...
Hi Sean, What method of staying logged in do you use, is it the checkbox when you first access the Montor Web front-end? There maybe a timeout value built into this session, however we are thinking this is closer to 24 hours and not 1-2. Do you know if your Monitor deployment is using IIS or Kestrel? / comments
Official comment
Hi Sean, What method of staying logged in do you use, is it the checkbox when you first access the Montor Web front-end?There maybe a timeout value built into this session, however we are thinking ...
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...
Hi Carman Houston, Thank you for reaching out on the Redgate forums regarding this SSMS21 install anomaly. I've replicated this and can confirm that Prompt is creating it's pkgdef extension data in the standard SSMS21 install folder even without SSMS21 installed. This is not ideal. I shall escalate this to our developers to ensure that the installer more accurately determines the installed versions of SSMS to load the extension into. / comments
Official comment
Hi Carman Houston, Thank you for reaching out on the Redgate forums regarding this SSMS21 install anomaly. I've replicated this and can confirm that Prompt is creating it's pkgdef extension data in...
Sorry to hear that is happening, are you able to confirm what version of SSMS you are using SQL Search in? If you are using it in SSMS21, can you confirm if the same issues with refreshing databases are occurring in SSMS18-20 also? We have recently implemented preview support for SSMS21 and may have some bugs like this occurring. If you are using SSMS18-20, can you locate the most recent log file and provide a copy of it for investigation. You can access it in the Help > Logging > Locate log files menu option. [image] You can provide logs to this secure file link, it will be valid for 14 days: https://files.red-gate.com/requests/Fz2UUZT776sd7QtK0lXeEo / comments
Sorry to hear that is happening, are you able to confirm what version of SSMS you are using SQL Search in? If you are using it in SSMS21, can you confirm if the same issues with refreshing database...
Hi Axium7, Thank you for reaching out on the Redgate forums regarding your SQL Search inquiry. Unfortunately, SQL Search does not store any default settings that can be recalled. Drop-down selection is recalled for the active SSMS session, and this data is dropped when that session closes. The displayed information in these drop-downs depends on a connection to your database instances so they can be populated. This is generated when a connection is made and isn't stored outside the active session. You can post this on our UserVoice forum as a feature request if this is something you'd like to see: https://redgate.uservoice.com/forums/101149-sql-search / comments
Official comment
Hi Axium7, Thank you for reaching out on the Redgate forums regarding your SQL Search inquiry. Unfortunately, SQL Search does not store any default settings that can be recalled. Drop-down selectio...
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...
Hi rick105, Thank you for reaching out on the Redgate forums regarding your SmartAssembly concern. Interesting that you have a variance between VS build process over running it through SmartAssembly GUI directly. Since your other .NET 8.0 projects obfuscate correctly, here are some things to check: 1️⃣ Compare SA Logs (Build vs. UI) – Check if the build log shows SA skipping obfuscation or using the wrong input/output paths. 2️⃣ Check the SmartAssembly Project File (.saproj) – Open it in a text editor and compare it to a working one. Make sure dependency merge/embed settings match. 3️⃣ Investigate MSBuild Process – Run MSBuild /verbosity:diagnostic to see if SA is being invoked properly for this project. 4️⃣ Check the SA Task in .csproj – Verify that SA is actually being triggered. You might have something like: <Target Name="AfterBuild">
<Exec Command=""$(SmartAssemblyPath)\SmartAssembly.com" /build MyProject.saproj" />
</Target> Try running this command manually to see if it works outside the build. 5️⃣ Check Dependencies – Does this project reference anything different, like native libraries or unmanaged code? 6️⃣ Rebuild from Scratch – Try a full clean (bin/obj deletion) and test with a fresh SA project file. If nothing stands out, feel free to share your SA logs and .saproj file so we can investigate further I have generated a secure file-link to provide any logs/project files. This link is valid for 14 days. https://files.red-gate.com/requests/CHkY0nxjxnmEUmVu8HZACE / comments
Official comment
Hi rick105, Thank you for reaching out on the Redgate forums regarding your SmartAssembly concern.Interesting that you have a variance between VS build process over running it through SmartAssembly...
Hi rick105 Thank you for reaching out on the Redgate forums regarding your SmartAssembly question regarding obfuscating into a single file app. When publishing a .NET application as a single file, SmartAssembly can still obfuscate it, but some extra steps are required since the assembly is embedded within the single file executable. Here’s a possible method on how this can be achieved 1. Publish Without Single File First SmartAssembly needs access to the raw assembly (.dll ) before it gets bundled into a single file.
Publish your app without the PublishSingleFile option first: dotnet publish -c Release -r win-x64 --self-contained false
This generates a normal set of .dll files in the bin\Release\netX\publish\ folder.
2. Obfuscate with SmartAssembly
Open SmartAssembly and create a new project.
Add your main application .dll (e.g., MyApp.dll ).
Configure obfuscation, string encryption, control flow obfuscation, etc.
Build the obfuscated .dll .
3. Publish as Single File Manually Now, repackage the obfuscated assembly into a single file:
Replace the original .dll with the obfuscated version.
Run the dotnet publish command with single file enabled: dotnet publish -c Release -r win-x64 -p:PublishSingleFile=true -p:IncludeAllContentForSelfExtract=true --self-contained false The IncludeAllContentForSelfExtract=true ensures embedded assemblies can still be loaded properly.
4. Test the Application
Run the generated .exe and verify functionality.
Use a decompiler to confirm that obfuscation is applied.
Hopefully this process can be used to obfuscate your project and end with a single file executable as desired. / comments
Official comment
Hi rick105 Thank you for reaching out on the Redgate forums regarding your SmartAssembly question regarding obfuscating into a single file app.When publishing a .NET application as a single file, S...