THE SQL Server Blog Spot on the Web

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

Jamie Thomson

This is the blog of Jamie Thomson, a freelance data mangler in London

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.

image

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:

image

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

image

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:

image

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

image

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:

image

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.

@Jamiet 

 

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

Comments

 

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

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement