I would like to compile an executable using the F# 3.0 command-line compiler, and then run it under Mono.
The code starts to execute, but Mono dies almost immediately complaining it cannot load System.Core. Googling this suggests that I should be targeting .net 3.5, and not version 4. Further Googling suggests that the F# compiler used to take option --cli-version, but it no longer seems to accept that.
I am sure there is a way, seeing as if I were to use MSVC there would be somewhere I could click to set the desired CLR version.
What should I do please? Many thanks.
EDIT:
I have tried targeting .net 3.5 on a simpler project developed in the MSVC GUI. The executable then asked for FSharp.Core 2.0.0, and got further than before. The F# 3 compiler seems to come with a .net 2.0 core library, so I would expect that it is supposed to be able to generate code compatible with obsolete versions of the framework. The question this leaves is "if the GUI can do it, how do I do the same thing from the command line", please?
If you're using F# 3.0 there's no reason not to use .NET 4.0 by default (unless, of course, you need to interoperate with existing .NET 2.0 or 3.5 assemblies).
Which version of Mono are you running on? F# 3.0 requires Mono 2.10 or newer, but I'd strongly suggest you use Mono 3.0 or newer.
Related
I used to program in .NET 4.7.2 (and still do), but my High School uses .NET 6
Currently we have started using C# console in .NET 6
I don't want to update to .NET 6 because i would also have to change my Unity editor version to one that supports VS2022
Is it possible to open .NET 6 projects in .NET 4.7.2, or am i gonna have to update Unity and reinstall VS, while scouring every part of my C:// partition to clean up junk/leftovers? I am very tight on free space especially on C://
No, you can't (if you mean anything more then editing text, cause for this you can use even notepad). But depending on language features used potentially you can copy-paste code into a .NET Framework 4.7.2 project and compile it. Or not, cause at least some newer features are not supported by older framework version.
Also you don't need full blown VS upgrade. You can look into installing just the .NET 6 SDK and VS Code (which requires less space compared to VS 2022).
Though I hugely recommend to extend your disk.
With the latest VS for mac installed (8.5 preview) and the latest net core sdk (3.1.200) F# 4.7 should be supported. When I run the dotnet fsi, indeed language features are supported and the FSI shows F# 4.7 as the F# version.
In VS for mac, in the preferences settings the exact command: /usr/local/share/dotnet/dotnet fsi is the path to the F# compiler.
However, when creating a new fix file and trying F# language features, it doesn’t work and the FSI in VS for mac doesn’t compile the code. Also, the FI for mac doesn’t show with F# version is used.
So, it is possible to use F# 4.7 features in Visual Studio for Mac?
The disappointing answer is, you can't. I have raised this issue months ago. But still no luck.
I have a few simple questions:
a) can I use mono on linux and osx to load the full .net framework like I would on windows by adding net46 to my project.json?
b) can I use mono as an alias like net46?
c) can I use mono with aspnet core 1.0 rtm projects on linux?
I have been looking at the dotnet docs, specifically the standard library and the table and the table with the platform support confuses me with the arrows and star under mono.
thanks
can I use mono on linux and osx to load the full .net framework like I would on windows by adding net46 to my project.json?
In theory, yes, that's exactly what you do: specify some version of net inside frameworks in your project.json and dotnet run will then use mono to run your application.
In practice, basic Hello World application works, but I'm not sure how well will more complicated applications work.
If you want to run dotnet build on the same machine, you will also need reference assemblies. The version I tested (mono 4.2.1) only contained reference assemblies up to .Net 4.5.1, so net451 works, but net46 doesn't.
can I use mono as an alias like net46?
I don't think you can, at least not without forking .Net Core SDK.
I don't understand why would you want to do that, but I believe doing so would require modifying DefaultFrameworkMappings in NuGet.Client.
can I use mono with aspnet core 1.0 rtm projects on linux?
I wasn't able to make a basic ASP.NET Core application run under mono. I don't know what the problem is, or how hard would it be to fix it. EDIT: I managed to work around the issue I encountered.
Mono is other thing. Yeah they developed mono like .net framework but you cannot use .net 4.6 on mono.
Read the following article. Click here
Micrsoft developed .net core a new framework to run .net on windows, linux, mac osx etc.
Well my third question on stack and again about same topic :-)
So I decided to upload my application built in websharper on appharbor but of course there is a problem. After trying to use visual studio 2012 and .net framework 4.5 and getting strange errors which were unsolvable for me (I didn't want to google all day) I decided to use vstudio 2010 and .NET framework 4.0.
Everything went fine (I copied typeproviders.dll) but there is compile error on appharbore. Here is a log. http://pastebin.com/r9MtegHH and if you are too lazy to click here is a problem line:
D:\temp\ovuxcbrh.4p1\input\borkfork\borkfork\Website\borkData.fs(19,102): error FS0010: Unexpected symbol '=' in type arguments. Expected ',', '>' or other token. [D:\temp\ovuxcbrh.4p1\input\borkfork\borkfork\Website\Website.fsproj]
It works fine on my vstudio 2010.
And line of code is:
type internal dbSchema = Microsoft.FSharp.Data.TypeProviders.SqlDataConnection<ConnectionString = #"Data Source=IRON;Initial Catalog=borkdorkfork;Integrated Security=True">
Maybe there is a problem because I didn't yet configure database overthere but it looks like something else. Well I am going to configure db overthere and see.
Code that uses type providers will run on .NET 4.0, providing that code has been compiled with the F# 3.0 compiler (targeting .NET 4.0) and references FSharp.Core and FSharp.Data.TypeProviders 4.3.0.0 with Copy Local set to True.
The problem in this case is that AppHarbor builds your code for you. Since they haven't updated to .NET 4.5 yet, your code is being compiled with the F# 2.0 compiler, which doesn't understand type providers.
If AppHarbor had a way for you to compile your own binaries and deploy those, that would work.
Edit:
I think this compiles for you on VS 2010 because .NET 4.5 is an in-place replacement for .NET 4.0. It must be replacing the F# compiler that VS 2010 uses, as well.
Type providers requires .NET 4.5. The error is the standard syntax error, because it expects you to close the triangle brackets, which it thinks are not type provider parameters, but generic parameters - the only use for triangle brackets in F# 2.0.
We have an MVC1.0 application that is compiled against and runs with .Net Framework 3.5.
The application was scanned for security and the scanning organisation reported
Microsoft ASP.NET ValidateRequest Filters Bypass Cross-Site Scripting
Vulnerability
https://community.qualys.com/docs/DOC-3495
What versions of Microsoft ASP.NET are vulnerable? Microsoft has
confirmed that ASP.NET versions 1 and 2 are both vulnerable.
Additionally, Qualys has confirmed that ASP.NET version 3 is also
vulnerable, as it includes the vulnerable component from version 2 by
default. We have tested this in our Labs and confirmed the exploit
works on a fully patched version 3.
We are already upgrading our application to MVC3, but that takes some more time to finish.
Is there any chance I can run and compile a MVC1.0 application against .NET 4.0?
This may arise compatibility issues, Even though there are very few dependencies over the .net framework.
You can refer the following posts.
Is ASP.NET MVC 1 forwards compatible with ASP.NET MVC 2?
ASP.Net MVC 1.0 in Visual Studio 2010
From what I understand, anything that runs on .NET 3.5 should function and complile just fine in .NET 4.0, with perhaps some warnings about depreciated functions, but they will still work.
In case you are still curious/not comfortable, there are some tools available to help verify dependencies and other items such at NDepend
Best recommendation... try it! I can't think of any other reason than what Tommy mentioned about deprecated functions. Also, you can update most of your references with
Update-Package
without arguments.
If it compiles fine, do a quick test run over the views. If nothing seems broken, then it probably isn't.