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 )
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 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.
In previous versions of .Net, there were some different methods of creating a project that could run as a console app or be installed as a service.
Things like TopShelf or other approaches like: .NET console application as Windows service
This is a nice convenience for development and later deployment. I put together a vNext console app using a similar approach to the accepted answer here: .NET console application as Windows service.
The issue is that vNext runs things in a different way. If you create output, it no longer gives you an exe to install. Instead you get a nuget package and a .cmd file that will tell dnx to host your application. The command file looks like:
dnx --appbase "$(dirname $0)" Microsoft.Framework.ApplicationHost My.vNext.Service $#
So my question is: Is there a way to install this thing as a Windows service given the new console application approach?
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.