20

How can I tell from the assembly name, or assembly class (or others like it), whether an assembly is part of the .NET framework (that is, System.windows.Forms)?

So far I've considered the PublicKeyToken, and CodeBase properties, but these are not always the same for the whole framework.

The reason I want this information is to get a list of assemblies that my EXE file is using that need to be on client machines, so I can package the correct files in a setup file without using the Visual Studio setup system. The problem is, I don't want to pick up any .NET framework assemblies, and I want it to be an automatic process that is easy to roll out whenever a major update is finished.

The ultimate solution would be that there is an IsFramework property... :)

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Dave Arkell
  • 3,920
  • 2
  • 22
  • 27
  • How automatic does this need to be? It's pretty easy to pick out which ones are from MS. – RQDQ Apr 03 '12 at 16:37

7 Answers7

11

No, it doesn't begin with "System". You could check "WindowsBase" which is a framework assembly.

You can't also check the PublicKeyToken, because there are other Microsoft assemblies signed with the "default" keys, but they are not part of the .NET Framework (Visual Studio assemblies).

The best way of doing it is to get a collection of installed .NET frameworks and check if the target assembly is part of their RedistList (RedistList\FrameworkList.xml).

FrameworkList.xml can be found in:

  • .NET 2.0: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\RedistList
  • .NET 3.x: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\vVersionNumber\RedistList
  • .NET 4.x: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\vVersionNumber\RedistList
  • .NET Core: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETCore\vVersionNumber\RedistList
Joe White
  • 94,807
  • 60
  • 220
  • 330
5

To accomplish this I'm using the Product Name embedded within the assembly through the AssemblyProductAttribute.

var attribute = assembly.GetCustomAttributes(typeof(AssemblyProductAttribute), false)[0] as AssemblyProductAttribute;
var isFrameworkAssembly = (attribute.Product == "Microsoft® .NET Framework");

I'm using this technique to group assemblies by product under the About screen of the application and it seems to work just fine for me.

jpierson
  • 16,435
  • 14
  • 105
  • 149
4

I have had to deal with the exact same issue. Unfortunately, all answers given so far are insufficient to safely determine if an assembly is part of the .NET Framework.

Microsoft puts a class named FXAssembly into the global namespace of each framework assembly with a const string indicating the version:

.class private abstract auto ansi sealed beforefieldinit FXAssembly
    extends [mscorlib]System.Object
{
    .field assembly static literal string Version = string('2.0.0.0')

}

Use this "marker" to check if an assembly is a framework assembly. Checking the public key too won't hurt either.

Johannes Rudolph
  • 35,298
  • 14
  • 114
  • 172
  • 1
    Unfortunately, this isn't true for all Framework assemblies :( Example: System.Data Version 2.0.0.0 does not have that class even though it was part of .net Framework 2.0. Checking for a public key token of `b77a5c561934e089` still seems to be most promising – Michael Stum Apr 20 '11 at 22:00
  • 1
    Aside of `b77a5c561934e089` there are at least 3 more: `31bf3856ad364e35` (e.g PresentationCore.dll), `b03f5f7f11d50a3a` (e.g System.Drawing.dll) and `89845dcd8080cc91` (e.g System.Data.SqlServerCe.dll) – VitalyB Nov 03 '11 at 11:10
3

I suspect that the method both most reliable and most general is going to be the PublicKeyToken. Yes, there's more than one, but it's going to be a finite list and one that doesn't change very often.

For that matter, you could just have a whitelist of assembly names -- that list, too, will be both finite and static between versions of the framework.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Curt Hagenlocher
  • 20,680
  • 8
  • 60
  • 50
  • I wonder if you can query some Microsoft service for the public key tokens... like the way they provide a remote symbol server. That way you don't have to track it manually. – Anthony Mastrean Sep 09 '08 at 15:33
2

When you install Visual Studio, you get the reference assemblies in various subfolders of the form C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\{FrameworkName}\{FrameworkVersion} - the most interesting thing could be the RedistList\FrameworkList.xml file that contains a list of all assembly names that were shipped with the given framework version.

E.g. C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\RedistList\FrameworkList.xml seems to contain a list of all of .NET 4.0's Framework assemblies.

You could easily use these files to establish static white lists of assemblies.

Jean Hominal
  • 16,518
  • 5
  • 56
  • 90
1

If you know that none of your DLLs will be in the GAC you could check whether each assembly is in the GAC or not. If it is, don't copy it. If it isn't, then do copy it. There is a property on the Assembly class called GlobalAssemblyCache. This would obviously work better in some situations than in others.

Jon Turner
  • 2,932
  • 3
  • 22
  • 20
1

You could use reflection to look at the publisher of the assembly, and coordinate that with the assembly's path. If you find an assembly whose publisher is Microsoft, and which exists somewhere below C:\Windows\Microsoft.NET\Framework it's a safe bet it's part of the runtime.

On second thought, the publisher may not even be necessary. Anything under that path should be part of the runtime (barring a misbehaving application that's diddling where it shouldn't be).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
TheSmurf
  • 15,337
  • 3
  • 40
  • 48