Tenga en cuenta que la solución a continuación es específica al marco .NET 4.0, el TargetFrameworkAttribue
es nuevo a 4,0.
Recopilé dos aplicaciones, una contra Client Framework, la otra contra el completo. Los abrí ambos en ildasm.exe y noté que ambos tenían un TargetFrameworkAttribute
aplicado. Usted puede simplemente utilizar la reflexión para ver el valor:
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();
}
}
Actualización: Sí, efectivamente, la compilación de una demanda contra el "Perfil de .NET Framework 3.5 Client" hace no incluyen ese atributo (el código puede ya no lo veo y ildasm no lo incluye). No tengo ninguna pista, aparte de la otra respuesta que vinculó, sobre cómo determinar el marco objetivo en esta situación.
Para guardar imponer lo que ver limitaciones como sin sentido en su base de código, me gustaría hacer la vida más fácil y simplemente apuntar el marco completo. Si el cliente tiene permisos para instalar el Perfil del cliente, entonces lo mismo es cierto para el marco completo: es un poco más grande (detecté una fuente que decía que solo era un 15% más grande, anulando gran parte del beneficio del "paquete de cliente más pequeño"). , 41MB en comparación con 48MB). Tu llamada.
Puede verificar manualmente las referencias de las que no están incluidas con el Perfil del cliente (o escribir una herramienta para hacer esto por usted). No estoy seguro de una forma de salir de la caja. –
AFAIK, cuando solo se utilizan los ensamblados, solo se necesita el perfil de cliente, se requiere .NET Framework completo para fines de desarrollo/depuración. –
Cualquier solución funcionará, no tiene que ser solo un código. – Evan