How can we help you today? How can we help you today?
Jon Kirkwood

Activity overview

Latest activity by Jon Kirkwood

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
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...
0 votes
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...
0 votes
Hi SergeyK for providing your solution.  Your solution does makes sense, as the DDL trigger could indeed be interfering with the clone creation process.  Here are some possible reasons why: Triggers and Permissions: DDL triggers can perform actions like logging schema changes, and in some cases, these actions can require additional permissions or affect the state of the database. If the trigger is set to log schema changes to another database, it could be trying to access resources or log data that isn't available or correctly mapped in the cloned environment. Backup Creation Process: When creating a clone, Redgate SQL Clone effectively takes a snapshot of the database. If a DDL trigger is active, it might attempt to execute additional operations that can interfere with the cloning process, especially if it tries to reference external resources or databases that the clone might not have access to at that moment. Disabling the Trigger: Disabling the DDL trigger before taking the backup makes sense because it prevents any additional operations from being triggered during the clone creation, ensuring that the backup is clean and doesn't have any external dependencies. To summarize: The issue likely arose because the DDL trigger was executing and possibly trying to log changes to an external database, leading to conflicts or missing mappings. Disabling or removing the trigger resolves this issue, as it prevents those additional operations from interfering with the clone creation. Glad that you have resolved your concern, and this information may come in useful in the future for someone else getting the same error. / comments Official comment
Hi SergeyK for providing your solution. Your solution does makes sense, as the DDL trigger could indeed be interfering with the clone creation process. Here are some possible reasons why: Triggers...
0 votes