2008-09-09 15 views
15

¿Cómo puedo decir por el nombre del ensamblaje, o clase de ensamblaje (u otros similares), si un ensamblaje es parte del marco .NET (es decir, System.windows.Forms)?Determinar si un ensamblaje es parte del .NET framework

Hasta ahora he considerado las propiedades PublicKeyToken y CodeBase, pero estas no son siempre las mismas para todo el framework.

El motivo por el que quiero esta información es obtener una lista de ensamblados que utiliza mi archivo EXE que deben estar en máquinas cliente, para poder empaquetar los archivos correctos en un archivo de instalación sin utilizar el sistema de instalación de Visual Studio. El problema es que no quiero recoger ningún ensamblado de .NET Framework, y quiero que sea un proceso automático que sea fácil de implementar cada vez que se termine una actualización importante.

La última solución sería que no es una propiedad IsFramework ... :)

+0

¿Qué tan automático debe ser esto? Es bastante fácil elegir cuáles son de MS. – RQDQ

Respuesta

3

sospecho que el método más fiable y tanto más general va a ser el PublicKeyToken. Sí, hay más de uno, pero va a ser una lista finita y una que no cambia muy a menudo.

De hecho, podría tener una lista blanca de nombres de ensamblado; esa lista también será tanto finita como estática entre versiones del marco.

+0

Me pregunto si puede consultar algún servicio de Microsoft para los tokens de clave pública ... como la forma en que proporcionan un servidor de símbolos remoto. De esta forma, no es necesario que lo rastree manualmente. –

1

Puede usar la reflexión para ver el editor del ensamblaje y coordinarlo con la ruta del conjunto. Si encuentra un ensamblado cuyo editor es Microsoft y existe en alguna parte por debajo de C:\Windows\Microsoft.NET\Framework, es una apuesta segura que es parte del tiempo de ejecución.

Pensándolo bien, el editor puede que ni siquiera sea necesario. Cualquier cosa bajo esa ruta debe ser parte del tiempo de ejecución (salvo una aplicación que se comporta mal que está bromeando donde no debería).

+0

El problema aquí es que muchas cosas están en el GAC de acuerdo con AssemblyName y Assembly –

3

No, no comienza con "Sistema". Puede marcar "WindowsBase", que es un ensamblaje de marco.

Tampoco puede marcar PublicKeyToken, porque hay otros ensamblados de Microsoft firmados con las claves "predeterminadas", pero no son parte de .NET Framework (ensamblados de Visual Studio).

La mejor manera de hacerlo es obtener una colección de .NET frameworks instalados y comprobar si el conjunto de destino es parte de su RedistList (RedistList\FrameworkList.xml).

FrameworkList.xml se puede encontrar en:

  • .NET 2.0: C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ RedistList
  • .NET 3.x: C: \ archivos de programa (x86) \ Framework \ v VersionNumber \ RedistList
  • .NET 4.x Referencia Asambleas \ Microsoft \: C: \ archivos de programa (x86) \ Referencia Asambleas \ Microsoft \ Framework.NETFramework \ v VersionNumber \ RedistList
  • .NET Core: C: \ Archivos de programa (x86) \ Referencia Asambleas \ Microsoft \ Framework.NETCore \ v VersionNumber \ RedistList
+0

Necesita mucho más que +1. Esta es la respuesta real y autoritativa. –

1

Si sabe que ninguno de sus archivos DLL será en la GAC ​​se puede comprobar si cada ensamblaje está en el GAC o no. Si es así, no lo copie. Si no es así, entonces cópielo.Hay una propiedad en la clase Assembly llamada GlobalAssemblyCache. Obviamente, esto funcionaría mejor en algunas situaciones que en otras.

3

Para lograr esto, estoy utilizando el Nombre del producto incrustado en el conjunto a través de AssemblyProductAttribute.

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

estoy usando esta técnica para los conjuntos de grupos de producto en la pantalla Acerca de la aplicación y parece que funciona bien para mí.

4

He tenido que lidiar exactamente con el mismo problema. Desafortunadamente, todas las respuestas dadas hasta ahora son insuficientes para determinar de forma segura si un ensamblaje es parte de .NET Framework.

Microsoft pone una clase llamada FXAssembly en el espacio de nombres global de cada conjunto de marco con una cadena que indica la versión const:

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

} 

Utilice esta "marcador" para comprobar si un conjunto es un conjunto marco. Comprobar la clave pública tampoco le hará daño.

+1

Desafortunadamente, esto no es cierto para todos los ensamblados de Framework :(Ejemplo: System.Data Versión 2.0.0.0 no tiene esa clase aunque era parte de .NET Framework 2.0. Comprobando un token de clave pública de 'b77a5c561934e089' todavía parece ser el más prometedor –

+1

Aparte de 'b77a5c561934e089' hay al menos 3 más:' 31bf3856ad364e35' (por ejemplo, PresentationCore.dll), 'b03f5f7f11d50a3a' (por ejemplo, System.Drawing.dll) y' 89845dcd8080cc91' (por ejemplo, System.Data.SqlServerCe .dll) – VitalyB

1

Cuando instala Visual Studio, obtiene los ensamblados de referencia en varias subcarpetas del formulario C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\{FrameworkName}\{FrameworkVersion} - lo más interesante podría ser el archivo RedistList\FrameworkList.xml que contiene una lista de todos los nombres de ensamblados que se enviaron con la versión de marco dada.

E.g. C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\RedistList\FrameworkList.xml parece contener una lista de todos los ensamblados de Framework de .NET 4.0.

Puede usar fácilmente estos archivos para establecer listas blancas estáticas de conjuntos.

Cuestiones relacionadas