The accepted answer, while seeming to resolve the O.P.'s issue, is only partially correct and presents an overly simplistic explanation of the underlying cause, which could lead other people with a similar problem in the wrong direction.
The problem with the accepted answer is a misunderstanding of the .NET environment, and that same misunderstanding can also be seen in the Question itself. Within .NET, the CLR and the Framework are two separate things, each with their own versions.
The CLR (Common Language Runtime) is what executes managed code. This is not updated nearly as often as the Framework. The .NET Framework is a collection of libraries that provide the basic means of interacting with a particular version of the CLR.
A single version of the CLR typically has multiple versions of the Framework that it works with. A single version of the Framework, however, only works with one specific version of the CLR. For example, CLR version 2.0 works with Framework version 2.0, 3.0, and 3.5, while CLR version 4.0 works with all of the 4.x versions of the .NET Framework (i.e. 4.0, 4.5, 4.5.1, 4.5.2, 4.6, etc). To see the chart of CLR verion to Framework version relationships, see the MSDN page for .NET Framework Versions and Dependencies.
With regards to SQLCLR code, SQL Server only works with a single version of the CLR, and the specific version depends upon the version of SQL Server. SQL Server 2005, 2008, and 2008 R2 work only with CLR version 2. Since CLR version 2 only works with .NET Framework versions 2.0, 3.0, and 3.5, this means that SQL Server 2005, 2008, and 2008 R2 only work with .NET Framework versions 2.0, 3.0, and 3.5. Of course, SQL Server 2005 only included .NET Framework version 2.0 so there are a couple of newer libraries in .NET Framework version 3.0 and 3.5 that don't work in SQL Server 2005 without manually importing them (i.e. System.Core and System.Xml.Linq). Along those same lines, SQL Server 2012, 2014, and 2016 are statically linked to CLR version 4, which works with .NET Framework versions 4.0, 4.5, 4.5.1, 4.5.2, 4.6.
With regards to the information returned from both System.Environment.Version
(in the Question) and sys.dm_clr_properties.version
(in the accepted answer), they are reporting the CLR version, not the Framework version. So be careful not to confuse those two things reporting 2.0 or 4.0 as meaning you can only use Framework version 2.0 or 4.0.
And fortunately, due to backwards compatibility, code compiled against the CLR 2 Framework versions (2.0, 3.0, and 3.5) will run without needing to be recompiled in SQL Server 2012 and newer, even though they are on CLR version 4.
So, you generally cannot go wrong with using a Target Framework Version of 2.0, but you most certainly can use Framework versions beyond 2.0.
For a more in-depth look at developing SQLCLR code, check out the following article (and the series in general), which I wrote:
Stairway to SQLCLR Level 5: Development (Using .NET within SQL Server)