Ding, Dong – SQL Server’s Dependency on .NET Framework 3.5x is Dead
Hello everyone. I’ve been pretty heads down with a lot of customer work, teaching my Mission Critical SQL Server class (with Philly on the way in June), preparing for three upcoming conferences in Europe (including three pre- or post-conference sessions, one of which will have updated labs), and working on the book. Yes, I’ve really been working on it and you’ll see some things shortly. You may have noticed our site got hacked, and I’ll probably do a post about that at a later date, so that’s taken up some time as well. I did lose the post on Distributed Availability Groups which I will rewrite soon. Needless to say, blogging has not been my Number 1 priority. I would rather put that energy into my customers, the book ,and making sure my upcoming speaking appearances go off without a hitch.
Having said that, SQL Server 2016 RC3 was publicly released today and I felt this was important to put out there. There is a major change that actually came in with RC2 that no one seemed to notice. I already talked about how from a server perspective, SQL Server 2016 is 64-bit only and I had a lot to do with that. That was a massive change to SQL Server. This next one is also just as big. Many of us (not just me) have been asking to remove the reliance on the older version of .NET Framework (3.5x), and it’s finally happened. Starting with SQL Server 2016, it is no longer a requirement.
Let me give you a little bit of backstory. For every version of SQL Server from 2008 through 2014, SQL Server required that .NET Framework 3.5x was installed (or enabled as the case may be depending on your version of Windows Server). How to enable .NET Framework 3.5x on Window Server 2012 or later is not apparent to everyone. I even wrote two blog posts (one and two) on how to get this task done. There is also a lot of confusion on why the older .NET Framework version is needed if the later version in the 4.x tree is installed. The short answer is that 3.x (which is the same branch as 2.x and 1.x) is different than the 4.x branch. Parts of the engine still relied on the old .NET Framework so the SQL Server development team could not just rip it out easily.
Some of us knew this was coming, and when I pinged someone around the time of RC1, I was told it would definitely be in RTM. We got it a little bit earlier. This was some hard work on the dev team’s part. If you think this is a hoax, it is not. Figure 1 shows all of the SQL Server features selected but look at the highlighted section – the only dependency is .NET Framework 4.6.
In Figure 2, the Command Prompt window is showing sqlcmd running a SELECT @@VERSION command with its output (RC3), and imposed on it, the output of showing that the older .NET Framework is not installed, yet SQL Server 2016 is running. Huzzah!
Couple that with the other changes to Setup introduced in the RCs by splitting out the tools install, installing a SQL Server instance is a more streamlined process … and much, much quicker. Getting an instance up and running is almost a pleasant experience. I have my issues with the new tools install, but I’ll take that as a first world problem.
Now if only we could get Microsoft to do the same for “Microsoft Visual C++ Redistributable”s. With SQL Server 2016 RC3 and SSMS April Preview installed there are 3 versions of the x64 and x86 redistributables.
So 2 each for versions 2010, 2013 and 2015.
I wonder how many more redistributables, etc will be installed if I further install SSDT?
Tell Microsoft to clean up their act (install) Allan!
Our DBA’s are upgrading one of our Windows 2014 SQL Server to 2016. We’re running the SQL upgrade adviser tomorrow. But curious if you have any recommendations on ensuring Application compatibility checks with SQL 2016 coming from SQL 2014 hosted on a Windows 2012 R2 server. Dominant application is TFS (Team Foundation), Team City and application IIS servers running .Net 4.0-4.7. Thanks!