5

When using third party assemblies I need a way to detect if they require full .NET 4 or just the .NET 4 Client Profile.

I've seen other ways to detect .NET version referenced Determine .NET Framework version for dll but the ways outlined in that question do not show how to detect Client Profile vs Full. Is it possible?

I'm looking for any solution, it doesn't have to be a code/runtime solution.

Community
  • 1
  • 1
Evan
  • 5,925
  • 6
  • 33
  • 35
  • You could manually check references for those which are not included with the Client Profile (or write a tool to do this for you!). I'm not sure of a way out of the box. – Rudi Visser Jun 26 '12 at 13:22
  • AFAIK, When using only the assemblies only Client Profile is needed, Full .net framework is required for development/debugging purposes. – Furqan Hameedi Jun 26 '12 at 13:23
  • Any solution will work, doesn't have to be code only. – Evan Jun 26 '12 at 13:30
  • @Furqan, that is not true, Client Profile is a slimmed down version that is sufficient to run most console/desktop applications. Full is typically needed for server applications even in production. For example, `System.Web` does not exist in Client Profile but does in Full. That is needed for anything related to any aspx/mvc/wcf/etc. – Samuel Neff Apr 17 '15 at 14:03

1 Answers1

2

Please note that the solution below is specific to the .NET 4.0 framework, the TargetFrameworkAttribue is new to 4.0.

I compiled two applications, one against the Client Framework, the other against the full. I opened them both in ildasm.exe and noticed they both had a TargetFrameworkAttribute applied. You can simply use reflection to see the value:

using System;
using System.Linq;
using System.Runtime.Versioning;

class Program
{
    static void Main(string[] args)
    {
        var a = System.Reflection.Assembly.GetExecutingAssembly();
        var att = a.GetCustomAttributes(false).OfType<TargetFrameworkAttribute>().Single();

        Console.WriteLine(att.FrameworkDisplayName);
        Console.Read();
    }
}

Update: Yes indeed, compiling an application against the ".NET Framework 3.5 Client Profile" does not include that attribute (the code can no longer see it and ildasm doesn't feature it). I have no clue, other than the other answer you linked, as to how to determine the target framework in this situation.

To save imposing what I see as pointless limitations on your code base, I would make life easier and simply target the full framework. If the client has permissions on installing the Client Profile, then the same is true for the Full framework - it is just slightly larger (I spotted a source saying it was only 15% larger, thereby negating much of the "smaller client package" benefit, 41MB as opposed to 48MB). Your call.

Adam Houldsworth
  • 63,413
  • 11
  • 150
  • 187