Question: We have a number of assemblies that are compiled with either .NET 2.0 or .NET 3.5.

Is there a way, via an undocumented table, function, etc - that one could query the list of assemblies in a database and get the .NET version of the assembly?

We have queried `sys.assemblies` which does contain a variety of assembly information, but does not include the target framework version.

We are upgrading our 08R2 instance to Windows Server 2012 and need to understand which assemblies are currently targeting the .NET 2.0 framework, not the 3.5 framework, so we can target recompiling them (or replacing, as we have a number of assemblies from NuGet packages and it is not clear whether they target .NET 3.5 or not).

Answer: 
No, there is no mechanism for getting this info (at least not that I have ever seen or heard of). If this info is available via Reflection, then you could create a SQLCLR stored procedure or function to read the `content` column of `sys.assembly_files` and try to extract it from there.

HOWEVER, you might not need this info. If the only reason is to determine what might need recompilation as you transition from SQL Server 2008 R2 to SQL Server 2012, then:

1. there is no real distinction between what was compiled for 2.0 and the 3.5 targeted Assemblies. 2008 R2 is linked to CLR 2.0 which covers .NET Framework versions 2.0, 3.0, an 3.5, while 2012 and newer are linked to CLR 4.0 which uses .NET Framework versions 4.0 and newer. Hence, when you move to SQL Server 2012, both the Assemblies compiled for 2.0, and the ones using 3.5, are all linked to a CLR version that you won't be using. So, if you need to recompile the 2.0 Assemblies, you would probably also need to recompile the 3.5 Assemblies as well. BUT....
2. fortunately you most likely don't need to recompile anything at all. .NET has backwards compatibility for most classes so stuff that is compiled for 2.0 should still work across all future Framework versions. In fact, I use a target framework version of 2.0 for all but possibly one of the Assemblies in my [SQL#](http://www.SQLsharp.com/) project so that they will work across all SQL Server versions starting with 2005. I have yet to run into a problem running anything, and most of my initial testing is done on SQL Server 2012, while I do additional testing on 2014 and 2016 and no problems encountered yet. The biggest "issues" have been minor changes in default values or behaviors between Framework versions (such as the "enlist" Connection String keyword changing its default from `false` to `true` across one of the upgrades, and things like that).
You can check out the output of:

```
select * from sys.dm_clr_properties

```

You should get something like:

```
name        value
-----------------------------------
directory   C:\Windows\Microsoft.NET\Framework64\v4.0.30319\
version     v4.0.30319
state       CLR is initialized

```