Visual Studio 2017 Incompatibility on *PROJ/SLN Files
Upon joining the Analytics and AI Team at Microsoft to support education, it became quickly apparent that my automation skills were needed more than getting me up to speed on Power BI. My predecessor had built some great solutions, but to be more scalable, it would pay forward in the end for me to do the automation work, knowing I’d be granted a greater understanding of the products in the long run.
The task of building out the automation, along with doing it in a way that is sustainable and easily supportable requires extensive research and one of the pieces that are part of the solutions we were with are a series of solution, (.sln) and project, (*proj) files that perform a number of functions, including data loads, logical object builds and integrations. There are two desktop applications are are commonly used to interact with these kinds of files: Visual Studio and SQL Server Management Studio, (SSMS) with the addition of SQL Server Data Tools, (SSDT).
These files were created as part of a solution build by my predecessor and were most likely build in using Visual Studio 2015. As I build out the automation, the first thing I was to do, was to deploy everything manually, in Azure and then reverse engineer it and then automate. As I’m new, my laptop has both Visual Studio and SSMS and SSDT 2017 installed.
This is where life, learning new technology and learning how to do something. not many others are even looking into, became very, very frustrating.
After I deployed my version of the solution onpremises, everything was commplete. As I moved to deploy it to the cloud, I became aware that I was missing pieces of the solution. I also had an incompatibility error due to a missing application tool that came up in Visual Studio that would ask me if I’d like to resolve, I’d click resolve and it would then go away, displaying the files in the solution or project file.
I spent considerable time checking my extensions and tools to verify that I had everything installed. I then went out to Twitter looking for verification and assistance. I AM still new to these tools and those maybe, just maybe, I had missed something. Upon recommendations from others in the community, it was found that no, my data tools were installed and the error I was receiving made no sense.
As many customer engagements that I have and the intermittent work I was doing to automate everything, I assumed I forgot something and started pestering my peers, who know the deployment well, to go over the deployment with me and figure out what I was missing. Lucky for me, one of my peers, Dustin, (@SQLDusty) had recorded sessions of the deployment. Upon reviewing them for the 10th time in an attempt to locate what I could have missed, I noticed that he was prompted for a password. I hadn’t been prompted a password in any of my interaction with the files and remembered at one time, I had. I asked my customers who were experiencing the same problem if they had been prompted a for a password and neither had they.
Although a longshot, I asked one of my peers to open the files in his older, working installation of Visual Studio, remove the password protection and then save the files. He sent me the new files and I no longer received the incompatibility error and I discovered that there were numerous files that were missing in the incompatbile version.
It appears that Visual Studio 2017 can’t support older password protection on sensitive data in solution or project files and issues an incompatibility error with option to resolve, but doesn’t really resolve it. The resolution is to remove the files with the protection assigned to it with the user being uninformed of the missing code/data/files.
