I'm trying to create portable F# library but it needs to target .NET 4.0 (company policy is that all portable libraries need to be compatible with Windows XP).
When I create (Visual Studio 2013) new project there is an option "Portable Library (Legacy)" with description saying "A project for creating an F# library (.dll) that can run on .NET Framework 4.0 and higher, Windows Store and Silverlight 5".
The problem is, when the project is actually created. When I go to project's properties "Target Framework" is set to ".NET Portable Subset (.NET Framework 4.5, Silverlight 5, Windows 8)".
I tried changing F# runtime version from 3.1 to 3.0 but it does not change anything. "3.0" and "3.1" are the only options. What happened to "2.0"?
Am I missing something?
EDIT: It seems like Grzegorz is right. I've created this F# PCL which is saying ".NET 4.5" and referenced it from .NET 4.0 C# application. No problems were reported.
Then, to be sure, I also referenced it from 3.5 application and... no problems were reported during compilation either, but it was crashing on runtime. So to be sure, I ran the "potentially 4.0" application on XP and it worked, which may be interpreted as: "Yes, F# PCL does not depend on 4.5 even it it says so".
Make it an answer so I can tick it.
The template file for "Portable Library (Legacy)" has TargetFrameworkVersion hardcoded as v4.0. If You'll create a project with this template it'll in fact target 4.0 version.
Probably, there's a bug in UI that keeps displaying target framework as 4.5 while in reality it uses previous one.
To be strict, the issue is related to legacy Portable Library. The non-legacy version seems to work correctly in forcing framework to be in 4.5 version.
update:
I submitted an issue about this to Visual F# Tools team:
https://visualfsharp.codeplex.com/workitem/95
Related
Just installed Visual Studio 15.5 Preview so that I can create an Azure Function targeting .NET Core. Without making any changes, I'm seeing a warning -- see below -- that reads:
Package Microsoft.AspNet.WebApi.Client 5.2.2 was restored using .NET
Framework version 4.6.1 instead of the project target framework .NET
Standard version 2.0. This package may not be fully compatible with
your project.
Any idea how to fix this or do I ignore this warning? As I said, this is a brand new Azure Function project I created with no changes at all.
Here's what the warning looks like:
You can pretty much ignore it, in this case.
Microsoft.AspNet.WebApi.Client targets "Portable Class Library (.NETFramework 4.5, Windows 0.0, WindowsPhone 8.0, WindowsPhone 8.1, WindowsPhoneApp 8.1)" (or net45+win8+win81 as it's the target framework moniker called), which means it's fully compatible with .NET Core and .NET Standard (>= 1.2).
The warning comes, because it do not target the netstandard1.x or netstandard2.x moniker specifically. It just tell you "this might not be compatible on .NET Core/.NET Standard".
Yes, you did nothing wrong: this is to be expected for now. Functions v2 are in beta now, so you'd have to live with this warning for a while. It should give you no functional issues.
I checked out http://msdn.microsoft.com/en-us/library/dd783499.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1. It should exist.
EDIT:
I tried it on vs2010 (different project, though), and it exists.
Enum.TryParse was added with .Net Framework 4.0.
You can easily tell this by looking at the Other Versions drop down menu in the documentation or the version Information:
.NET Framework
Supported in: 4.5, 4
.NET Framework Client Profile
Supported in: 4
Portable Class Library
Supported in: Portable Class Library
.NET for Windows Store apps
Supported in: Windows 8
So probably you're using an older .Net Framework version.
Do you have System Import?
Imports System
If you are in Visual Studio 2010, make sure you are targeting .NET Framework 4.0
According to MSDN documentation,
public static Assembly LoadFrom(string assemblyFile)
throws BadImageFormatException if
assemblyFile is not a valid assembly.
-or-
Version 2.0 or later of the common language runtime is currently loaded
and assemblyFile was compiled with a later version.
Actually, there is one extra case - loading assembly that is built for x86 from assembly that runs in x64 mode. Maybe it is included in "not a valid assembly" statement, I don't know. But this is reasonable cause of exception.
Ok, but in .NET 4.5 it doesn't! I have a .NET 4.5 WPF app, that loads different appliations for some reason. It is building for Any CPU and I'm starting it on x64 Win 7. I've been testing it on one executable, that is built for .NET 4.0 x86, and it worked fine. But when I switched my app to .NET 4.0 it began to crash on Assembly.Load method!
So, my question is, am I missing something? If not, then how did they do that - loading x86 assembly from x64 process in .NET 4.5? I'm lacking some understanding at this point.
Update
Thanks to Hans Passant, I've figured out my mistake. Actually the behavior of Assembly.Load is no different. It turned out, I didn't notice Prefer 32-bit option in project settings (or Prefer32Bit tag in .csproj file). That's why my process in .NET 4.5 ran in a 32-bit mode. This setting was true when I created WPF .NET 4.5 project. Then, when I swithced to .NET 4.0 it became inactive because there was no such an option in .NET 4.0. And when I switched back to .NET 4.5 it became false, which is so, I guess, for compatibility purpose.
Let's clear one assumption off the table quickly, there is no possible way to have different behavior on a machine that has .NET 4.5 installed. Targeting 4.0 makes no difference at runtime. The only thing that does is select a different set of reference assemblies, they prevent you from accidentally using a class that's available on .NET 4.5 but not on .NET 4.0.
There is no way to have both 4.0 and 4.5 installed on the same machine. .NET 4.5 is not a side-by-side version of the .NET framework, like 3.5 and 4.0 are side-by-side. Installing 4.5 replaces an installed 4.0 version. The CLR, the jitter, all the runtime assemblies plus the C# compiler.
It is best here to focus on the Platform target setting of your EXE project, that's the one that selects the bitness of the process. The kind of mistakes you can make is forgetting that the setting can be different for the Debug vs the Release build. And assuming that the "Active solution platform" combobox in Build + Configuration Manager has any effect. It doesn't, only the Project + Properties, Build tab, Platform target setting matters. This is a very awkward trap that many programmers have fallen into.
We have a large & complex system running under .Net 4.0. We want to start introducing code written for .Net 4.5, but can't (yet) assume that .Net 4.5 is installed on all the developer machines, build machines and test labs. So I'm looking for a way to compile certain projects in MSBuild using assemblies which are available on disk, on machines which have only .Net 4.0 installed.
Per the documentation it seems possible. The 4.5 reference assemblies are available in the msbuild environment, and I've been experimenting with the TargetFrameworkVersion, FrameworkPathOverride and TargetFrameworkMoniker attributes, but so far without success.
Any hints, suggestions or working samples would be most helpful.
To build a .NET Framework 4.5 application, you must also have the .NET Framework 4.5 reference assemblies.
Installation
The .NET Framework 4.5 replaces the common language runtime (CLR), targets, tasks, and tools of the .NET Framework 4 without renaming them. Essentially, it creates a modified and improved .NET Framework 4.
Can anyone tell me why when I create Monotouch projects in the latest drop of MonoDevelop it is targeting the 1.0 framework instead of 3.5, as my projects in earlier versions do? This causes it to not be loadable in VS2010, which I tend to use for coding, while building/testing in MonoDevelop. Here is the version info:
Release ID: 20509002
Git revision: 35a0397615c02f7830d46dfcd31a6c0cb86e9f85
Build date: 2011-04-06 03:37:58+0000
And here is the difference in the csproj files between versions:
Old:
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
New:
<TargetFrameworkVersion>v1.0</TargetFrameworkVersion>
The v3.5 was a bug; MonoTouch projects never targeted the .NET v3.5 framework. They target the MonoTouch framework, which is arbitrarily versioned as v1.0.
Improvements in MD 2.6 have allowed us to deal with custom .NET frameworks in a similar way to VS 2010. This means that instead of storing the "closest" .NET framework then internally switching it to the correct framework after the project is loaded, we can directly handle particular project types using a particular custom framework.
If you want to load MT project in VS, you already have to make changes to the project - temporarily remove the project flavor GUID (though a trivial VS addin could make that unnecessary). This framework version fix means that you also have to change the target framework to one that VS has. For MonoTouch 4, rather than using .NET 3.5, I would recommend using either Silverlight 4 or .NET 4.
The best solution would be to set VS to actually use the MonoTouch framework, so you'd get accurate code completion and compilation. In VS 2010 that's now possible. Simply set the TargetFrameworkIdentifier of the project to "MonoTouch", then install the custom framework by copying all the MonoTouch framework assemblies to C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoTouch\v1.0 and adding a FrameworkList.xml manifest in the RedistList subdirectory.
I've created a small open source project that enables you to build MonoTouch projects inside Visual Studio 2010. The readme for the project also explains how to get round the "v1.0" problem for the target framework version.
The project is available at https://github.com/follesoe/VSMonoTouch.
Since that's a Monotouch project, nobody expects it to work for Visual Studio or Windows.