Die vordefinierten Binärdateien für das F # PowerPack werden mit der .NET 2.0-Laufzeit kompiliert. Wenn ich ein .NET 4.0-Projekt habe, ist es von Vorteil, die PowerPack-Quelle für die .NET 4-Laufzeit zu kompilieren?F # PowerPack Target Runtime
Antwort
Ich habe .NET 2.0 Version von F # PowerPack in F# snippets web site, die ein .NET 4.0 ASP.NET-Projekt ist. Der einzige Nachteil der Verwendung von Version 4.0 war, dass ich Konfiguration hinzufügen musste, um Version 4.0 von FSharp.Core.dll
zu laden, wenn ich nach 2.0-Version suche (auf die die Version 2.0 von PowerPack verweist).
Ich hatte so etwas wie die folgenden hinzuzufügen und es funktionierte dann ganz gut:
<configuration>
<!-- ... -->
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" />
<bindingRedirect oldVersion="2.0.0.0" newVersion="4.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Es gibt also einen Vorteil, aber keinen enormen. Da F # jedoch als Teil von VS 2010 veröffentlicht wurde, scheint es seltsam, dass der standardmäßige Binärdownload von PowerPack solche Problemumgehungen erfordert. –
Ich hatte gerade ein Problem mit einer asp.net mvc 3 Seite mit fsharp und fsharp powerpack. Fehler bei der Ausnahmebedingungsnachricht: Die Datei oder Assembly 'FSharp.Core, Version = 2.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die Manifestdefinition der lokalisierten Assembly stimmt nicht mit der Assemblyreferenz überein. (Ausnahme von HRESULT: 0x80131040). Ich habe ein dependantAssembly-Element wie oben erwähnt hinzugefügt und das hat es sortiert. – Kit
@Kit Das war vor einiger Zeit, also kenne ich die Details nicht mehr :-). Ich denke, es könnte einfacher sein, F # PowerPack für .NET 4.0 (mit dem Quellcode) neu zu kompilieren. –
Meine app.config für älteren .NET ist
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
</configuration>
aber Netzteil installiert und funktioniert auf gut VS2010 und .NET4 fsproj
- 1. "Target F # Runtime" ausgegraut - warum?
- 2. "CompileAssemblyFromSource" in f # PowerPack codeDom
- 3. Iterate durch DataRepeater (VB.Net PowerPack)
- 4. Neben FSharpCodeProvider (von PowerPack), was sonst wird benötigt, um F # Code im laufenden Betrieb zu kompilieren?
- 5. F # int64 zu int
- 6. Java Runtime pg_dump mit log
- 7. Was ist der Unterschied zwischen target = "_ blank" und "target = blank"?
- 8. "Dual-Target" MinGW-W64 ist nicht wirklich Dual-Target?
- 9. jQuery '#' + Daten ("target") Muster
- 10. Target Framework Mismatch
- 11. Target auf genymotion
- 12. CSS3 Target Selector Ausgabe
- 13. java.io.FileNotFoundException: /target/test.log
- 14. : nicht (: target) Wahl Css
- 15. Target KeyboardInterrupt zu Subprozess
- 16. Target IE7 mit jQuery
- 17. ReactJS - Target zufälliges Element
- 18. Warum funktioniert target = "blank"?
- 19. Build Target Tools Pfad
- 20. Target Smooth Following
- 21. ANTLR JavaScript Target
- 22. F # Endlosschleifen in F #
- 23. Android RunTime Berechtigungen
- 24. Runtime 1004 Problemumgehung - Schutz/Schutz in Worksheet_Change
- 25. F # NLog Konfigurationsdatei
- 26. <f: propertyActionListener> Tag nicht gefunden
- 27. Interop zwischen F # und C# lambdas
- 28. Imprädikativer Polymorphismus in F #
- 29. Xcode Target Phase Python Skript
- 30. Spark Target-Protokolldatei existiert bereits
Wenn jemand F # PowerPack Binaries gegen .NET 4.0 mit dem F # v2 SP1 Compiler gebaut haben will, habe ich sie gehostet [hier] (http://dl.dropbox.com/u/10282384/FSPowerPac kCLR4SP1.7z). – ildjarn
Was wirklich nett ist, ist ein offizielles NuGet Paket, das sowohl .NET 2 als auch .NET 4 Binärdateien enthält. –