THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Jamie Thomson

This is the blog of Jamie Thomson, a data mangler in London working for Dunnhumby

SSDT gotcha – Moving a file erases code analysis suppressions

I discovered a little wrinkle in SSDT today that is worth knowing about if you are managing your database schemas using SSDT. In short, if a file is moved to a different folder in the project then any code analysis suppressions that reference that file will disappear from the suppression file. This makes sense if you think about it because the paths stored in the suppression file are no longer valid, but you probably won’t be aware of it until it happens to you. If you don’t know what code analysis is or you don’t know what the suppression file is then you can probably stop reading now, otherwise read on for a simple short demo.

Let’s create a new project and add a stored procedure to it called sp_dummy.


Naming stored procedures with a sp_ prefix is generally frowned upon and hence SSDT static code analysis will look for occurrences of this and flag them. So, the next thing we need to do is turn on static code analysis in the project properties:


A subsequent build causes a code analysis warning as we might expect:


Let’s suppose we actually don’t mind stored procedures with sp_ prefixes, we can just right-click on the message to suppress and get rid of it:


That causes a suppression file to get created in our project:


Notice that the suppression file contains a relative path to the file that has had the suppression placed upon it. Now if we simply move the file within our project to a new folder notice that the suppression that we just created gets removed from the suppression file:


As I alluded above this behaviour is intuitive because the path originally stored in the suppression file is no longer relevant but you’re probably not going to be aware of it until it happens to you and messages that you thought you had suppressed start appearing again. Definitely one to be aware of.



Published Thursday, October 10, 2013 6:42 PM by jamiet

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



AlexK said:

It is probably much simpler, and more robust, to keep this information in the *.sql file itself. This is how JetBrains do it. The approach you are describing is very complicated.

October 13, 2013 7:49 PM

jamiet said:

Keep what information in the .sql file?

October 14, 2013 2:03 AM

AlexK said:

This is how JetBrains do it:

// ReSharper disable InconsistentNaming

       private int level;

// ReSharper restore InconsistentNaming

October 14, 2013 9:39 AM

Philippe said:

We can't suppress code analysis warnings in a SQL script added as a link in a Database Project (for example, a file common at several projects). Because we have the absolute path of the file stored in the "StaticCodeAnalysis.SuppressMessages.xml", instead of the relative path, as in the sqlproj files. So the build fails on TFBuild or on another machine where the absolute path is different !

February 18, 2016 5:48 AM

jamiet said:


OK, so I guess you'll have to ensure the absolute paths are the same. Can you not just map a drive letter to the location?

February 18, 2016 6:12 AM

Leave a Comment


This Blog


Privacy Statement