How to deal with a reporting services project in VSS when each developer needs different connection strings?

Question

How do I deal with a reporting services SSRS project inside of Visual Source Safe, when each developer on the team might have different connection strings and different deployment URLs?

Some developers might be developing off their local SQL Server while others might be developing of a remote server. Some developers might be using the default SQL Server instance name, while others might be using a named instance.

The problem is that the connections strings and deployment URLs are embedded in project, which is in source control, which makes it hard for multiple developers to work on the SSRS reports.

Does anyone know of a solution to this?

Thank  you.

Answer 1

Hi Usp,

 

As my understanding, you want to place your SSRS project under source control VSS, and each developer can use a different connection string setting in the project file when checking out. If so, in my opinion,  that would be a issue in the “reporting services SSRS project”, you’ll have the same problem with other source control systems, not only with VSS.

 

Settings that are not meant to be shared between the team members should not have been stored in the project file – the setting should have been placed in the project.user file, which stores per-user settings and is not added by VisualStudio to source control.

 

To workaround the problem, the users that want to have different settings will have to either change the attribute on the local file, or checkout the project file. The first who will checkin will cause a bit of trouble for the others that will do a get – they will have to merge the changes and accept their versions. Pretty much the setting in the file in the database will change everytime someone will checkin the file.

 

If I misunderstood you, or you have any questions, please let me know.

 

Best Regards,

Nancy

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 2

Nancy,
Thanks for the reply. What I do now is to go to the file system, uncheck the read-only box, and enter the desired settings using a basic text editor. The downside is that every time I update my SSRS project to get changes made by other team members I have to skip over those modified files and I get alerted to the fact that the files are writable. If I set the files back to read-only after making the change the files get overwritten automatically upon syncing with source control.

I looked at that .user file. I learned that this file contains login credentials, although it is in a binary format that can't easily be read so I'm not sure what else it contains. The deployment URLs and database connection strings are stored in separate files, and I don't know of any way to change the behavior of Visual Studio to store additional settings in the .user file.

A nice feature that Subversion has is the concept of an ignore list. I don't think there is any equivalent using Visual Source Safe and Visual Studio.

If anyone knows of a good way to have a file ignored by VSS source control in a reporting services project I would be interested to know what that is. Thank you.

Answer 3

Hi Usp,

Sorry for the delay.

After my research and consulting to other engineer, you can use File/SourceControl/ExcludeFromSourceControl function to exclude files.

In VS/scc integration the files that are controllable are dictated by VisualStudio and not by the source control provider. And SCCI supports files excluded from source control (File/SourceControl/ExcludeFromSourceControl), but the project files themselves cannot be excluded via this mechanism. The project files and *.vspscc hint files contain information about source control bindings of the project, which are supposed to be shared between the team members.

Additionally, the project files contains the lists of files in the project; if you delete/exclude the project file from the scc database then other users won’t be able to open the solution from source control.

If the settings that the customer doesn’t want to be shared across the team member are in other files that the project file then by all mean use the ExcludeFromSourceControl functionality on them.


Best Regards,
Nancy

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 4

Thanks for looking into that for me Nancy. I am so used to programming Web site projects, which offer no way of excluding Web site files from VSS source control, that I forgot that option existed for other types of projects. That technique does help with the Reporting Services data sources. Unfortunately it does not help on the development server deployment URLs that are for some reason stored inside of the project file itself.

Your answer did clue me into another problem with my technique that I was overlooking. When I was skipping over the project file when doing source control synchronizations, I was also not getting the list of any of the new files added by colleagues. It looks like I will have to modify the deployment URL every time I get new files from source control and want to deploy the reports to my development database. Resolving that problem is more of a reporting services issue than a source control issue.