A software upgrade/update always starts out with such good intentions and hopeful optimism. There are perhaps two opposing schools of thought that emerge when it comes to the merits and necessity of always ensuring you’re on the latest version of an application. The arguments for and against will generally look something like this:
In Favour
- Having the latest version protects against potential exploits or security vulnerabilities present within an older version of the application.
- The latest version of the application is easier to use, supports X feature etc.
- The application will be end of life in the very near future, so we need to be proactive as opposed to reactive*
Against
- The upgrade will take time to complete - we will have to perform in-depth testing and schedule time outside of normal business hours to carry this out.
- As part of the XXX update, X feature is no longer available and we have to instead use Y feature instead.
- The current version of the application works just fine - upgrading could cause us problems as a result of a bad security patch or similar.
*“very near future” is becoming more commonplace these days, particularly with Microsoft Cloud products. For example, Office 2013 is technically considered end of life for ProPlus customers at the end of this month.
Whilst I would argue strongly that keeping your important business applications up to date should always be an ultimate priority, the reality is less straightforward and even I have fallen foul of this in the past. Case in point: I recently upgraded to the Windows 10 Anniversary Edition from Windows 10, on a personal machine that had Hyper-V installed and a number of virtual images. The update went fine, but I was informed after the update that the latest version of .NET Framework needed to be downloaded. I dismissed the error message, as I was in the middle of something else, and then spent many hours later on attempting to figure out why the update had removed the Hyper-V program feature from my machine; after researching, I determined it was because of the prompt I had received when first booting up Windows and that the updated version of Hyper-V required the latest .NET Framework. I was able to get the role installed and re-configure all of my virtual images accordingly, but it did take some time and was definitely an unwelcome distraction! Suffice to say, an upgrade can never go exactly to plan, which is why I would always encourage the need for dedicated testing environments within your business for your primary IT systems. This will grant that you sufficient latitude to perform all required testing of an update and to give you the confidence that it can be deployed safely into your production environment(s).
Of course, the above does not help very much if you are upgrading your test environment and everything goes wrong there, such as what happened to me recently. The business in question was wanting to upgrade from Visual Studio 2013 to Visual Studio 2015. Their development environment was a virtualised, remote desktop server, which all of the developers logged into as their primary working environment. Development was carried out using the “out of the box” templates included in Visual Studio (C#, ASP.NET etc.) and also using SQL Server Data Tools for BIDS/SSIS development. All projects/solutions were stored in a central Git repository.
The process of installing Visual Studio 2015 and the current “production ready” 16.5 version of SQL Server Data Tools for Visual Studio 2015 went (rather too) swimmingly, and we began to run tests confirming that all Team Services projects opened without issue. We immediately came across an issue when attempting to open certain .rdl report files - Visual Studio would hang for about 10-15 minutes every time the report was opened, with the following prompt stuck on the screen and the application remaining in a non-responsive state:
The report would open fine in the end, but the issue was repeated whenever the report was re-opened.
We initially tried the following in an attempt to resolve the problem:
- Re-cloned the repository - no joy.
- Attempted to open the report from VS 2013 - the report opened fine without issue, so definitely a problem with VS 2015
- Created a brand new Report Project template in VS 2015, added the report into the project (both as a copy and as a new report, with the underlying .xml definition copy + pasted) and then tried re-opening - the same issue occurred.
Being officially stumped at this juncture, I then did some further research online to see whether anyone else had encountered the same issue. Fortunately, I came across the following TechNet thread which contained the exact same symptoms we were experiencing:
The thread seemed to attract some confused answers (in the sense that they didn’t grasp the underlying problem), before petering out with no apparent solution. Without holding my breath too much, I replied to the thread in the hopes of getting a definitive answer, which I received in almost record time:
Yes we did, we got a fix from Microsoft: https://go.microsoft.com/fwlink/?linkid=837939. After installing the reports where opening fine.
Not wishing to look a gift horse in the mouth at all, I did first double check the contents of the link to verify it - and it turned out to be 17.0 RC2 of SQL Server Data Tools for Visual Studio 2015. What’s worth noting is that the first hit on Google for SQL Server Data Tools Visual Studio 2015 is the download page for version 16.5 and not the following page that contains links to both versions:
https://docs.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt
Those who have already read through the TechNet thread will know how things panned out in the end, but just to summarise - installing this fixed the issue. So major credit to Erwin de Kreuk for doing all of the “hard work” to finding the solution in this unusual case and in responding so quickly to my forum post. This is definitely a great example of the old adage “You don’t ask, you don’t get” and how the wider community can often prove invaluable when resolving an especially troublesome IT issue.
So what should you do if you are planning to upgrade SSDT from Visual Studio 2013 to Visual Studio 2015?
The key takeaway from the above should be the fact that a release-candidate version of SSDT provided a resolution to the problem at hand. It would, therefore, be foolhardy to recommend a general upgrade from VS 2013 whilst 17.0 remains at a release-candidate version. Given that this version was released at the start of the year, it is highly likely to expect that a production-ready version of 17.0 will be released in the very near future. I would recommend holding off on your upgrade if your organisation works with a large number of SSRS reports, lest you also fall foul of this surprisingly strange bug.