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

Activity overview

Latest activity by Jon Kirkwood

Hi Murali,    Thank you for contacting Redgate support regarding your code coverage concern, I suspect this is related to our SQL Test product and have moved this post into a new location on our forums to better represent that.   SQL Test provides a UI wrapper around the tSQLt framework, it doesn’t change or extend the tSQLt functionality itself.  In other words, SQL Test runs whatever tSQLt syntax you provide, but the underlying behavior (such as how tSQLt.ExpectException or tSQLt.ExpectNoException works) comes from the tSQLt framework, not from SQL Test.   Because of this, issues with exception handling or coverage inside tSQLt tests are usually best addressed by checking the tSQLt documentation or raising the question with the tSQLt community. https://tsqlt.org/join-the-conversation We’re happy to help confirm that SQL Test is running the tests correctly, but troubleshooting tSQLt specific logic is outside the scope of our product support.   That said, some general guidance we’ve seen work for other users: tSQLt.ExpectException only detects errors that escape the procedure — if your CATCH block swallows the error without THROW /RAISERROR , nothing reaches the test framework. For coverage, you may need to either rethrow the error or assert side-effects (like rows in a log table) instead of expecting an exception. You can find more details here: tSQLt Documentation – ExpectException If you’re not sure whether SQL Test itself is working correctly or if this is purely a tSQLt logic issue, we can potentially help you confirm that. / comments Official comment
Hi Murali,  Thank you for contacting Redgate support regarding your code coverage concern, I suspect this is related to our SQL Test product and have moved this post into a new location on our foru...
0 votes
Hi Tim Thank you for reaching out on the Redgate forums regarding your SmartAssembly query.  You're correct that obfuscating a large solution with multiple assemblies — especially when working with ReadyToRun, self-contained builds — requires a bit more setup, particularly without using the merge feature.  The recommended approach in this scenario is to use a traversal project.  Here’s how that typically works:  Create a .saproj file for each assembly you want to obfuscate. Each .saproj will define the input/output paths and relevant obfuscation settings. Set up a traversal MSBuild project that sequentially runs SmartAssembly for each of those .saproj files. This is done by referencing the SmartAssembly MSBuild task like so:<SmartAssembly ProjectFile="Path\To\YourAssembly.saproj" /> These entries can be listed one after another inside a custom MSBuild target, allowing you to run all obfuscation steps in a single build pass.  Each project will need to be defined explicitly, as SmartAssembly does not currently support wildcards or dynamic project discovery.  Ensure obfuscation occurs before the ReadyToRun compilation — obfuscating after native image generation isn’t supported, as native images cannot be modified by SmartAssembly.    While this process is more manual than using the merge feature, it provides the flexibility needed for large applications deploying assemblies individually.  / comments Official comment
Hi TimThank you for reaching out on the Redgate forums regarding your SmartAssembly query. You're correct that obfuscating a large solution with multiple assemblies — especially when working with R...
0 votes