I would like to know how to run the f sharp compiler from the command line under .net core. I know I can create a .sln, then use dotnet restore etc. That works fine.
I am using the docker version of .net core (microsoft/dotnet), and note that fsc.exe is downloaded by nuget deep into /root/.nuget. However, there isn't any obvious way of running it from there.
I have a scripted build-process (for some command-line application) that runs under both MS .net and mono. The easiest way of adding .net core support is to just modify the compilation command in that script to run f sharp under docker/.net core. I guess I also need to know how to then run the produced executable (assuming it's non-obvious once I know how to run the compiler).
If the only way of compiling f# code under .net core involves the dotnet utility, can someone please tell me why it's necessary (i.e. why the usual flow available under .net/mono of just running fsc and getting an executable won't work)? Many thanks.
Related
I have a private server that I've been slowly setting up for personal projects, but I've run into a bit of a roadblock. My server is running Arch linux [I like bleeding edge and minimalistic installs in situations like this] and I have Jenkins running on it so that I can have it automatically build projects. I have a project that I've been working on that is currently targeting the Win32/64 platform using MSVC, but I can't seem to find any info anywhere about setting up a job on Jenkins for this situation. I was hoping that I could maybe setup a Docker instance that would be able to provide the MSVC toolchain, especially since Visual Studio Code is available for Linux, and that I could use that as part of my Jenkins setup to generate Win binaries for me to test on my main machine. I mention this because naturally, Visual Studio is not a command line utility, and currently my server is a pure headless setup that only provides cli interaction, so if possible, I would like to avoid directly adding GUI packages to the server, but if it is the only way, I'd be willing to do so. Is there really no way to achieve what I'm going for with this?
Sorry if this lacks important details or is formatted poorly, this is my first time asking a question here as it's very rare for me to not be able to find the info I'm looking for in an already existing question.
After research, this is not currently possible as it stems from a misunderstanding of exactly what docker provides. Docker simply uses the underlying OS to provide everything and does not provide any virtualization of foreign OSs. Without a version of the MSVC toolchain that can run on linux, or possibly the use of WINE, there is not a way to achieve this short of a VM. Since WINE is not perfect, the most reliable solution as it appears to me is the VM, but YMMV. The other advantage to using a VM is that I can keep the server headless.
I can't answer this question completely, but this topic is interesting to me too.
Note: Visual Studio Code is open-source, but that's an Electron-based editor. Visual Studio IDE and MSVC are proprietary Windows-only apps.
The website https://blog.sixeyed.com/how-to-dockerize-windows-applications/ suggests it's possible to dockerize Windows apps, including Visual Studio.
Docker images for Windows apps need to be based on microsoft/nanoserver or microsoft/windowsservercore, or on another image based on one of those.
Once you get that working, I'd use Visual Studio command-line builds, like devenv /build file.sln [optionally /project file.vcxproj ]. (https://learn.microsoft.com/en-us/visualstudio/ide/reference/devenv-command-line-switches?view=vs-2017 ).
Note that the VS2017 installer does not function on Wine. I recently filed a bug for this (https://bugs.winehq.org/show_bug.cgi?id=45749 followed by https://bugs.winehq.org/show_bug.cgi?id=45757 ).
I personally use Appveyor for auto-building MSVC apps. Appveyor is a Windows-based centralized cloud service, not a self-hosted CI system.
I want to create Kestrel stand alone .exe DotNetCore 2.0 MVC Web API application in Visual Studio 2017, however I can't find any documentation.
On how to compile it as a self contained .exe (not using dotnet run).
The Microsoft documentation here: https://learn.microsoft.com/en-us/dotnet/articles/core/deploying/deploy-with-vs only covers a console application, and following the modifications to the .csproj makes no difference
<RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
(note this is not a .NET Core 1.x question)
dotnet publish command is responsible for packing deployable .Net Core application. It will build the application and copy all its dependencies to the output directory.
The easisest way to run it is to switch to the project directory (the one where csproj resides) and execute:
dotnet publish --configuration Release --runtime win-x64
Change the build configuration and runtime version accoring to your needs. You could learn other command line settings on the doc I have referenced.
According to this answer:
At the moment, there are no fail-safe methods to create a single executable file. Since there are a lot of type-forwarding dll files involved, even ILMerge and similar tools might not produce correct results (though this might improve, the problem is that those scenarios haven't undergone extensive testing, esp. in production applications)
There are currently two ways to deploy a .NET Core application:
As a "portable application" / "framework-dependent application", requiring a dotnet executable and installed framework on the target machine. Here, the XYZ.runtimeconfig.json is used to determine the framework version to use and also specifies runtime parameters. This deployment model allows running the same code on various platforms (windows, linux, mac)
As a "self-contained application": Here the entire runtime is included in the published output and an executable is generated (e.g. yourapp.exe). This output is specific to a platform (set via a runtime identifier) and can only be run on the targeted operating system. However, the produced executable is only a small shim that boots the runtime and loads the app's main dll file. This also allows an XYZ.runtimeconfig.json to set additional runtime properties like garbage collection settings.(think of it as a "new" app.config file)
In the future, the CoreRT runtime – which is still under development at the time of writing – aims to allow creating a single pre-compiled native executable that is specific to a runtime and does not require any other files.
Although that question was asked (by yours truly) more than 6 months ago, it looks like CoreRT is still a work in progress.
Pros and Cons of a Self-Contained Deployment
Deploying a Self-contained deployment has two major advantages:
You have sole control of the version of .NET Core that is deployed with your app. .NET Core can be serviced only by you.
You can be assured that the target system can run your .NET Core app, since you're providing the version of .NET Core that it will run on.
It also has a number of disadvantages:
Because .NET Core is included in your deployment package, you must select the target platforms for which you build deployment packages in advance.
The size of your deployment package is relatively large, since you have to include .NET Core as well as your app and its third-party dependencies.
Deploying numerous self-contained .NET Core apps to a system can consume significant amounts of disk space, since each app duplicates .NET Core files.
I realize you already found that Microsoft deployment document, but if you go through the walkthroughs for command line and for Visual Studio deployments, you will note they are telling you to use dotnet publish in the procedure. This is exactly the same as with ASP.NET Core applications because they can be deployed as console applications.
In short, it is possible to make a self-contained deployment package with a .exe file, but it is NOT (yet) possible to make a self-contained EXE on .NET Core.
I have installed .net core on my Linux Box (Ubuntu) and created the ubiquitous "Hello World" app as follows:
dotnet new console -lang F# -o HelloWorld
The previous command followed by a dotnet restore and dotnet run is all I needed to run the app. Then I decided to use Visual Studio Code as a convenient Editor/Debugging environment. After some googling it turns out that I need the Ionide plugin in order to use Visual Studio Code with F# (and the plugin in turn relies on mono).
Is there an alternative to this (without requiring mono?)
Ionide is the plugin all the F#ers rave over, so, don't think there is many alternatives to it
However looks like it might go to .net core http://github.com/ionide/ionide-vscode-fsharp/issues/78
It's not actually needed to do .net core development, it's a plugin to vscode that gives lots of great toys for F#, it grew up in the mono world, so needs to be ported. (for instance, you could use Vim to write code instead )
I have Python 2.7 installed in "C:\Python27". Now I run 1st demo of Python4delphi with D7, which somehow uses my Py2.7 install folder. If I rename Python folder, demo can't run (without error message). I didn't change properties of a demo form.
What part/file does py4delphi use from my Python folder?
python4delphi is a loose wrapper around the Python API and as such relies on a functioning Python installation. Typically on Windows this comprises at least the following:
The main Python directory. On your system this is C:\Python27.
The Python DLL which is python27.dll and lives in your system directory.
Registry settings that indicate where your Python directory is installed.
When you rename the Python directory, the registry settings refer to a location that no longer exists. And so the failure you observe is entirely to be expected.
Perhaps you are trying to work out how to deploy your application in a self-contained way without requiring an external dependency on a Python installation. If so, then I suggest you look in to one of the portable Python distributions. You may need to adapt python4delphi a little to find the Python DLL which will be located under your application's directory. But that should be all that's needed. Take care of the licensing issues too if you do distribute Python with your application.
Is it possible to get Z3 running on a system providing posix API without having python installed?
I have seen the new version 4.3 uses python already in the build-process (scripts/mk_make.py).
Whats about older versions like 4.1? Is it imaginable to get it to run on posix without python?
Is Python not available in your system?
Python was always used to automatically generate some parts of the Z3 code base. In the first source code release, we have included the automatically generated code. Actually, at that time, we were using a combination of python + sed + awk + grep to generate these parts of the code. Another problem with the first release is that the build system for Windows (+ Visual Studio) was completely different from the build system for the other platforms. The Makefiles for Linux and OSX were derived from Visual Studio Project files. Some users also started to report problems with the build system for Linux and OSX. So, to reduce these problems and have a uniform build system, we decided to use python (and python only) to:
Automatically generate code (for bindings for different languages, API logging support, etc)
Check the system for requirements
Generate the Makefiles
And any other form of automation
Python is very attractive for us because it works in most systems (even non posix compliant ones). We can easily write portable scripts. Moreover, after we made the switch, we can compile Z3 in more platforms. We successfully compiled it on Windows, Linux (Mint, Ubuntu, Suse, etc), OSX, Cygwin, and FreeBSD.
In the "unstable" (aka working-in-progress) branch, we don't even require autoconf anymore, we use python to do all system specific configuration. To build Z3, we just need: python, C++ compiler (Visual Studio C++, g++ or clang++), ar (on non-windows platform), make (or nmake). This is very small set of requirements. Python is available in most platforms by default.
That being said, is it possible to remove the python requirement? Yes, it is, but it would have to replace python with something else. Something, that would allows us to perform all tasks described above. Take a look in the directory scripts at http://z3.codeplex.com/SourceControl/changeset/view/0c1f2a82818a,
we would have to port all these automation scripts to something that can be used on all platforms we support.