Wie NET NET-Anwendung während der Installation ordnungsgemäß zu

Question

Ich verwende Inno Setup, um Setup-Programm für meine Anwendung zu generieren, und ich möchte ein Skript zu NGen meine Anwendung während der Installation schreiben. Ich möchte, dass der Code NGen Dateien Targeting x86, x64 oder AnyCPU kann. Ich möchte in der Lage NGen auf 32bit und 64bit Systeme sein. Wie kann ich das erreichen?

Ich habe ein paar hilfreiche Links gefunden:
Getting the .NET Framework directory path
http://nsis.sourceforge.net/Get_directory_of_installed_.NET_runtime
Wo ich gefunden habe, es ist ein ziemlich komplexes Problem - es können bis zu 4 verschiedene Versionen von NGen Anwendung sein:

1. für CLR 2.0 und 32-Bit-Systeme
2. für CLR 2.0 und 64-Bit-Systeme
3. für CLR 4.0 ein nd 32-Bit-Systeme
4. für CLR 4.0 und 64-Bit-Systeme

Und es wird noch komplizierter durch die Tatsache, die Anwendung kann 32-Bit-CPU-Ziel und auf 64-Bit-System laufen.

---

Also, was mir in den Sinn kam, sucht eine Funktion wie das war:

function NGenFile(file: String; targetCPU: TTargetCPU; targetCLR: TTargetCLR): Boolean; 

und es irgendwo nach erfolgreicher isntallation in [Code] nennen:

NGenFile(ExpandConstant('{app}\application.exe'), tcpu64, tclr20); 
NGenFile(ExpandConstant('{app}\library1.dll'), tcpu64, tclr40); 
NGenFile(ExpandConstant('{app}\library2.dll'), tcpu32, tclr20); 
NGenFile(ExpandConstant('{app}\library3.dll'), tcpu32, tclr40); 
NGenFile(ExpandConstant('{app}\library4.dll'), tcpuAny, tclr20); 
NGenFile(ExpandConstant('{app}\library5.dll'), tcpuAny, tclr40); 

Und es würde so arbeiten :

1. anwendung.exe (tcpu64, tclr20)
   Auf 64-Bit-System würde es generieren nativer Bild 64bit CPU-Targeting und CLR 2.0, Ergebnis: = True
   Auf 32-Bit-System es nichts tun würde, Ergebnis: Falsch =

2. library1.dll (tcpu64, tclr40)
   Auf 64-Bit-System es nativen Bild Targeting-64-Bit-CPU und CLR 4.0, Ergebnis erzeugen würde: = True
   Auf 32-Bit-System nicht alles tun würde, Ergebnis: = Falsch

3. library2.dll (tcpu32, tclr20)
   Auf 64-Bit-System würde es generieren nativen Bild 32bit CPU-Targeting und CLR 2.0, Ergebnis: = True
   Auf 32-Bit-System ist es die gleiche wie auf die 64-Bit-System tun würde

4. library3.dll (tcpu32, tclr40)
   auf 64-Bit-System würde es nativer Bild Targeting 32bit CPU und CLR 4 erzeugen.0, Ergebnis: = True
   Auf 32-Bit-System ist es die gleichen

5. library4.dll wie auf die 64-Bit-System tun würde (tcpuAny, tclr20)
   Auf 64-Bit-System es nativen Bild Targeting-64-Bit-CPU erzeugen würde und CLR 2,0 Ergebnis: = True
   Auf 32-Bit-System würde es nativen Bild erzeugen 32bit CPU-Targeting und CLR 2.0, Ergebnis: = True

6. library5.dll (tcpuAny, tclr40)
   Auf 64-Bit-System, es würde g enerate nativen Bild 64-Bit-CPU-Targeting und CLR 4.0, Ergebnis: = True
   Auf 32-Bit-System würde es nativen Bild erzeugen 32bit CPU-Targeting und CLR 4.0, Ergebnis: = True

---

Also es funktioniert Ich muss 4 verschiedene Pfade zum .NET-Laufzeitverzeichnis kennen. Dies ist, was ich gefunden habe:

1. 32bit System CLR 2.0
   Get Wert von "InstallRoot" in "HKLM \ Software \ Microsoft \ .NETFramework",
   Erhalten Namen zuerst Wert1 speichern Wert in "HKLM \ Software \ Microsoft \. NETFramework \ Policy \ v2.0", Speichern in Wert2 Wert1 + "v2.0."
   + value2 + "\ ngen.exe" => win
   Beispiel: "c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ ngen.exe"
   Ich nehme an, dass dies auf 32-Bit- und 64-Bit-Systemen funktioniert

2. 32bit System CLR 4.0
   Get Wert von "InstallRoot" in "HKLM \ Software \ Microsoft \ .NETFramework", speichert
   Get Namen in „HKLM \ Software \ Microsoft \ des ersten Wertes Wert1. NETFramework \ Policy \ v4.0 ", Speichern in Wert2
   Wert1 +" v4.0. " + value2 + "\ ngen.exe" => win
   Beispiel: "c: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ ngen.exe"
   Ich nehme an, dass dies auf 32-Bit- und 64-Bit-Systemen funktioniert

3. 64bit System CLR 2.0
   Wie InstallRoot für 64-Bit .NET Framework bekommen?
   Beispiel: "c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ ngen.exe"

4. 64bit System CLR 4.0
   Wie InstallRoot für 64-Bit .NET Framework bekommen?
   Beispiel: "c: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ ngen.exe"

ich eigentlich bin nicht sicher, ob der "InstallRoot" Wert auf 64-Bit-Systemen zu InstallRoot zeigen würde von 32bit .NET oder 64bit .NET, sind also die ersten 2 Methoden für jedes System zuverlässig? Und wie würden die zweiten 2 Methoden aussehen? Gibt es einen einfacheren Weg, all das zu erreichen?

Answer 1

Welche Version von InnoSetup verwenden Sie? In der von mir verwendeten Version (5.4.0a) gibt es bereits Konstanten, um das .NET-Wurzelverzeichnis zu finden. Von der InnoSetup-Hilfe:

{dotnet20} .NET Framework Version 2.0-Stammverzeichnis. {dotnet20} ist entspricht {dotnet2032}, es sei denn, die Installation wird im 64-Bit-Modus ausgeführt. In diesem Fall entspricht sie {dotnet2064}.

Eine Ausnahme wird ausgelöst, wenn versucht wird, diese -Konstante auf einem System ohne .NET Framework Version 2.0 zu erweitern.

{dotnet2032} 32-Bit-.NET Framework-Stammverzeichnis der Version 2.0.

Eine Ausnahme wird ausgelöst, wenn versucht wird, diese -Konstante auf einem System ohne .NET Framework Version 2.0 zu erweitern.

{dotnet2064} Nur 64-Bit-Windows: 64-Bit-.NET Framework-Version 2.0 Stammverzeichnis.

Eine Ausnahme wird ausgelöst, wenn versucht wird, diese -Konstante auf einem System ohne .NET Framework Version 2.0 zu erweitern.

{dotnet40} .NET Framework Version 4.0-Stammverzeichnis. {dotnet40} ist entspricht {dotnet4032}, es sei denn, die Installation wird im 64-Bit-Modus ausgeführt. In diesem Fall entspricht sie {dotnet4064}.

Eine Ausnahme wird ausgelöst, wenn versucht wird, diese -Konstante auf einem System ohne .NET Framework Version 4.0 zu erweitern.

{dotnet4032} 32-Bit-Stammverzeichnis von .NET Framework Version 4.0.

Eine Ausnahme wird ausgelöst, wenn versucht wird, diese -Konstante auf einem System ohne .NET Framework Version 4.0 zu erweitern.

{dotnet4064} Nur 64-Bit-Windows: 64-Bit-.NET Framework, Version 4.0 Stammverzeichnis.

Eine Ausnahme wird ausgelöst, wenn versucht wird, diese -Konstante auf einem System ohne .NET Framework Version 4.0 zu erweitern.