2008-12-17 36 views

Respuesta

171

La ruta de acceso al directorio de instalación del CLR activo para la aplicación .NET corriente puede ser obtenido usando el siguiente método :

System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeDirectory() 

lo haría fuertemente consejos en contra de leer el registro directamente. Por ejemplo, cuando una aplicación .NET se ejecuta en sistemas de 64 bits, la CLR puede cargarse desde "C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727" (AnyCPU, destinos de compilación x64) o desde "C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 "(objetivo de compilación x86). El registro de lectura indicará cuál de los dos directorios fue utilizado por el CLR actual.

Otro hecho importante es que "el CLR actual" será "2.0" para las aplicaciones .NET 2.0, .NET 3.0 y .NET 3.5. Esto significa que la llamada GetRuntimeDirectory() devolverá el directorio 2.0 incluso dentro de las aplicaciones .NET 3.5 (que cargan algunos de sus ensamblajes desde el directorio 3.5). Dependiendo de su interpretación del término "ruta del directorio de .NET Framework", GetRuntimeDirectory podría no ser la información que está buscando ("directorio CLR" versus "directorio del que provienen los ensamblados 3.5").

+2

Creo que esta es la respuesta correcta y debería ser la seleccionada. Gracias por aclarar el hecho de que GetRuntimeDirectory siempre devuelve la carpeta 2.0 incluso en aplicaciones de 3.0 o 3.5. Este es el comportamiento correcto en la mayoría de los casos, donde desea acceder a las herramientas de framework, que están en 2.0 (pero no en 3.0 3.5). – DSO

+0

¿Cómo puedo obtener InstallRoot para marcos x86 y x64 .NET en sistemas de 64 bits? ¿Está "[HKLM] \ Software \ Microsoft.NetFramework \ InstallRoot" apuntando siempre a la versión x86 de .NET, incluso en sistemas de 64 bits? Necesito obtener una ruta a esta carpeta con una aplicación no administrada, por lo que no puedo usar el método que mencioné anteriormente. Gracias. – Paya

+1

Probablemente lo más fácil sería crear pequeñas aplicaciones .NET, una compilada para x86 (por ejemplo, 'getdotnetpath32.exe') y otra compilada para x64 (por ejemplo, 'getdotnetpath64.exe'). La aplicación administrada usaría la llamada GetRuntimeDirectory() y la escribiría en STDOUT (Console.Output).La aplicación no administrada iniciaría entonces un proceso hijo para x86 (getdotnetpath32.exe), conectando su STDOUT a su flujo en memoria y leyendo lo que produce el proceso. Luego, iniciaría un proceso hijo para x64 (getdotnetpath64.exe), conectando su STDOUT a su flujo en memoria y leyendo lo que produce el proceso –

2

lo pueda levantar desde el registro de Windows:

using System; 
using Microsoft.Win32; 

// .. .

public static string GetFrameworkDirectory() 
{ 
    // This is the location of the .Net Framework Registry Key 
    string framworkRegPath = @"Software\Microsoft\.NetFramework"; 

    // Get a non-writable key from the registry 
    RegistryKey netFramework = Registry.LocalMachine.OpenSubKey(framworkRegPath, false); 

    // Retrieve the install root path for the framework 
    string installRoot = netFramework.GetValue("InstallRoot").ToString(); 

    // Retrieve the version of the framework executing this program 
    string version = string.Format(@"v{0}.{1}.{2}\", 
    Environment.Version.Major, 
    Environment.Version.Minor, 
    Environment.Version.Build); 

    // Return the path of the framework 
    return System.IO.Path.Combine(installRoot, version);  
} 

Source

+11

Recomiendo encarecidamente no tener acceso al registro directamente (en un sistema operativo de 64 bits esto puede dar una respuesta incorrecta). Ver mi respuesta a continuación para más detalles. –

+1

De acuerdo con @Milan: definitivamente no es recomendable. –

+0

@CMS quiero hacer lo mismo que la versión silvetlight. y si elimino la clave de registro significa que el software también se desinstala del sistema. Gracias –

-3

Leer valor de la [HKLM] \ n del software son \ Microsoft.NetFramework \ InstallRoot clave - obtendrá "C: \ WINDOWS \ Microsoft.NET \ Framework". A continuación, agregue la versión de marco deseada.

39

Una forma más fácil es incluir los Microsoft.Build.Utilities montaje y el uso

using Microsoft.Build.Utilities; 
ToolLocationHelper.GetPathToDotNetFramework(
     TargetDotNetFrameworkVersion.VersionLatest); 
+0

Eso suena mucho mejor, especialmente cuando se trabaja en herramientas que afectan el proceso de compilación. –

Cuestiones relacionadas