12 ms·

Exploring the new .NET “dotnet” CLI

193 points by Nelkins 11y ago

Nelkins 11y ago
I think the most exciting thing about this is the AOT compilation into a single binary (Go-style), something I've wanted for a long time [1]. [1] https://news.ycombinator.com/item?id=9590213 https://news.ycombinator.com/item?id=9590213
- frik 11y ago
  Aren't the plans for AOT to work only with WinStore apps?
  - math 11y ago
    no - they first mentioned plans for cross platform go-style single binary compilation at connect (one of the videos here I believe: https://channel9.msdn.com/Events/Visual-Studio/Connect-event-2015/ https://channel9.msdn.com/Events/Visual-Studio/Connect-event...) and I'm pretty sure they've subsequently talked about it in more detail in one of the community standups.
    - mintplant 11y ago
      What's the difference between a "go-style" binary and any other statically-linked binary?
      - pjmlp 11y ago
        None, but apparently many seem to only ever seen static linked binaries in Go. So many write "go-style" as if it was something that was just invented by the Go team. So is the knowledge in our industry.
        iheartmemcache 11y ago
        Now now, there are plenty of people in our industry who would cringe at even the term "go-style" as a description for statically linking libs in, though most of them have long since left HN by now. Finally got around to reading that PARC/Cedar doc you linked out a while back, last weekend. Interesting stuff. Thanks again.
        pjmlp 11y ago
        Glad you liked it.
        rayiner 11y ago
        I imagine even grognards would describe many things as C/UNIX-style that actually have their roots in earlier systems.
        qwertyuiop924 11y ago
        Just ask pjlmp about it. He seems to still be bitter that the lispm and wirth's stuff lost to C and unix.
        qwertyuiop924 11y ago
        EDIT: pjmlp. I don't make a habit of getting people's usernames wrong, but that one's hard to read.
        pjmlp 11y ago
        No problem. :)
      - math 11y ago
        I wrote go-like because I think of C#/.NET and go as somewhat comparable and I'm not aware of any other language in a similar class that produces statically-linked binaries. However I'm pretty ignorant, so would not be surprised if there are many ... examples?
        pjmlp 11y ago
        Any programming language that has AOT compilation to native code among its implementation choices. There are plenty to choose from, but if you want a list: PL/I, Algol, PL/M, Quick Basic, Turbo Basic, Quick Pascal, Turbo Pascal, C, C++, Ada, Eiffel, Haskell, Objective-C, OCaml, Delphi, Oberon, Oberon-2, Component Pascal, Mesa, Modula-2, Modula-2+, Modula-3,...
        qwertyuiop924 11y ago
        Do all of those support static linking with the default tooling? (That is to say, not just hypothetical support, but actual support) Jeez.
        pjmlp 11y ago
        Of course, once upon a time static linking was the only way. It is dynamic linking that is hard to implement, not the other way around.
        qwertyuiop924 11y ago
        I KNOW that. I just wanted to know if the native compilers for the languages you mentioned supported static compilation either through a switch or by default, or if it's something that somebody else would have to write.
        pjmlp 11y ago
        Initially by default, many of them are older than OSes with dynamic linking support. The ones with compilers that also support dynamic linking, either via a switch or via explicit dynamic modules.
      - nolok 11y ago
        A lot of today's developer have never done it with another language before and so knows it as "the thing that go does".
  - KirinDave 11y ago
    They demoed it for Linux command line and touted that, so I doubt it.
    - jimmcslim 11y ago
      I'm hoping that Winforms/WPF apps are supported at some time soon.
      - JamesNK 11y ago
        You probably won't. This is .NET Core only. .NET Core is a cross platform slimmed down version of .NET and doesn't run Winforms or desktop WPF. Windows Store WPF is supported.
        moonchrome 11y ago
        If they really wanted to they could open source Silverlight GUI framework. That was basically WPF lite. They can take out the video/DRM stuff and just put the GUI layer out there - it was ported to OSX so it's at least somewhat portable. It would be nice to have something like JavaFX for .NET - resurrected Silverlight could be it.
      - tonyedgecombe 11y ago
        and drivers.
      - iheartmemcache 11y ago
        What I've been doing is in my solutions is adopting the Adobe approach and keeping a separate project for QT with all of the UI 100% abstracted out into that. Cross-platform builds are pretty easy, I get all of the safety of C# along with all of the tooling on NuGet crossplatform, and native UI interfaces on all 3 platforms with QT. The only time I come close to touching Winforms/Silverlight or WPF is if a client is dead-set on using Telerik or whatever.
  - deleted 11y ago
    [deleted]
  - JamesNK 11y ago
    No. Currently .NET Native (AOT) is used with WinStore apps - in fact every Win10 .NET application in the store and on your computer HAS to be .NET Native - but the plan is to make compiling a native DLL possible for all .NET Core applications.
deleted 11y ago
[deleted]
tomcam 11y ago
Preach it, brother. That would get this former Microsoftie back to the fold.
csours 11y ago
.Net CLI, so ... powershell? This looks pretty cool. I wish powershell were slightly easier to set up and use, and that there was a repo for extensions other than "google it and then download".
- travem 11y ago
  Have you seen the capabilities enabled by the PowerShell Gallery[1] (script and module repository) and the PowerShellGet cmdlets[2] (for interacting with repositories like PowerShell Gallery)? It looks like a useful approach to solving this particular issue. [1] https://technet.microsoft.com/en-us/library/dn807169.aspx https://technet.microsoft.com/en-us/library/dn807169.aspx [2] https://www.powershellgallery.com/ https://www.powershellgallery.com/
- derefr 11y ago
  One of the major tenets of this is (from what I can tell) its multiplatform-ness: it would be able to ship as the tooling in the .NET Core release for any platform. Powershell is certainly a cool shell, but it is a shell, and that makes it much less likely to be ported+packaged everywhere (Pash exists, but I don't know whether it exists as, say, an Ubuntu PPA.) Whereas, when you release a language, you kind of want its tooling to go wherever it goes.
- chadzawistowski 11y ago
  Powershell is a shell that runs on the .Net virtual machine. Scott is showing off command-line tools for creating and compiling C# projects.
- JamesNK 11y ago
  No .NET CLI is a set of cross platform command line tools for making .NET applications.
donatj 11y ago
Dumb question, but if I install this on OS X does it support VB.Net or just C#? I have a ton of old CLI apps I wrote in VB.Net 10 years or so ago and it would be interesting to port them. Mono's support for VB.Net last I tested was not good.
- iheartmemcache 11y ago
  This looks like it includes C#, VB.NET, F#, and any other language that targets the CLR (Common Language Runtime, i.e., Microsoft's JVM). edit: Apparently not. Mea culpa! Also, I don't know how long ago you tried Mono + VB, but especially since MS started collaborating with Mono and offering upstream first-party support (~2 years), support for the IL has been almost production quality. (Now it is production quality - I'm running some of my customer ASP.NET applications which was built around the NHibernate rather than EF/MS SQL on full Linux infrastructure). Satya is making a ton of bold moves that are basically antithetical compared to the Ballmer-era MS. Visual Studio Code (yet-another-electron-based-editor) and Community, along with the ridiculous amount of open stuff on Github has effectively eliminated the vendor-lock-in stronghold that Microsoft previously had. Residual Office renewals and upgrades on the MS SQL stack will only get them so far. They're going full Docker[1] support on the new Windows Server stack, as well as full .NET support off the Windows stack, which is interesting to say the least. I wonder if we'll start seeing them buying out companies that are traditionally aligned with more-open-sourcey. A bold move they could make would be buying out Cognitect. Datomic could be a perfect fit for them. Integrate Visual Studio support (e.g. as good as IntelliJ/Cursive) and give CLJS first-party support (let Nolen take a lead spot on the TypeScript team) in VS and it could be a steal at even a few hundred million dollars. The talent (Hickey+Nolen) the developers who they bring over + the perception shift within the dev community + the Datomic itself is likely worth a half a billion to MS. [1] http://www.hanselman.com/blog/BrainstormingDevelopmentWorkflowsWithDockerKitematicVirtualBoxAzureASPNETAndVisualStudio.aspx http://www.hanselman.com/blog/BrainstormingDevelopmentWorkfl...
  - donatj 11y ago
    It was maybe 2 or 3 years ago I poked around in it and failed to get much to run.
dcw303 11y ago
It's a nice idea, and anything that gives .NET developers more power at the command line is going to get a thumbs up from me. But "one command to rule them all" does feels a little broad. To take a ruby/rails/linux equivalent, this is apt-get, ruby, irb, rails and gem all rolled up together. Perhaps I'm just overly familiar with the unix small tools philosophy.
- alkonaut 11y ago
  > To take a ruby/rails/linux equivalent, this is apt-get, ruby, irb, rails and gem all rolled up together Once you have fetched ruby I'd be much happier if it was all one command "ruby" for fetching packages, building, running etc. That doesn't mean it can't be several pieces of code running in the end, but from the end user perspective one top level util for one set of tasks makes sense. Compare "git lfs foo baz" with "git-lfs foo baz". I think the first is a lot better, even if what happens is closer to the second.
- enricosada 11y ago
  there are multiple executables the dotnet is like git, so `dotnet compiler` just call `dotnet-compiler` the first level tools ( dotnet-compile, dotnet-restore ) read the project json ( the only supported project file atm ) and pass argument to second level tools. for example: - dotnet compiler call dotnet-compile - dotnet-compile read source files, references, defines from project.json and call dotnet-compile-csc with the source files as arguments. - dotnet-compile-csc call csc - if --native, another .net bytecode to native tools is called and csc (csharp compiler) is bundled with the dotnet cli package.
alpb 11y ago
In case you missed: "dotnet compile --native" is basically like the Go compiler, it statically links all the DLLs and produces a single PXE/ELF executable. This is the most exciting thing for me in the new dotnet CLI as a person writing Go full-time at Microsoft. Most developers will be able to take advantage of single-binary shipping, they'll just put that in a Docker container and happily run everywhere.
- pjmlp 11y ago
  Why does everyone need to bring up Go for what is a standard feature from AOT compilers to native code?
  - KirinDave 11y ago
    Because it is 2016 I guess? So many languages did this for so long and then VMs got in vogue. Go not doing it was, for many people, a reminder it could be done. But for a managed language runtime like the CLR to start supporting it is a big deal.
    - pjmlp 11y ago
      I guess this tells how much mono-culture is still prevalent in the industry, with silo language programming and no CS knowledge. But I do agree it is a big deal, specially for getting more developers to adopt safer programming languages.
    - Skinney 11y ago
      Well, mono has supported this for a while now. This is what Xamarin.iOS is based on.
      - justncase80 11y ago
        This is true. It's funny because the api's have always existed in the Microsoft compliers but they would litterally throw not implemented errors when run. Mono actually implemented them.
jmspring 11y ago
I learn a lot from Hanselman, and as someone bridging multiple languages, platforms, and sdks while at MSFT, this is a new one for me. I'm adding this to my list for potential 20% time project exploration. Cross platform and cross language have their interesting aspects...
m0dest 11y ago
I'm so happy to see arguments specified with "-" and "--" (UNIX-style) instead of "/" (DOS-style). The DOS-style CLI arguments used by Microsoft's other command line tools seem like such a stubborn throwback to a long-lost war. "/" won the battle for folder path separators (see: URLs) and "-" won the battle for argument delimiters.
- david-given 11y ago
  Fun fact: most MS kernels, including DOS, supported "/" as a path separator. They were just filtered out of the command lines by the argument passing code. There was a system call which would tell the argument parser that you wanted a different switch character, and if you changed it to, say, "-", then "/" would work. Of course, not everything used the standard argument parser, so if you did change this you ended up in a world of pain because your tools would start behaving inconsistently, but it was theoretically possible. I've seen references to this code existing as late as XP, but I don't do Windows any more, so can't comment on later versions.
  - userbinator 11y ago
    https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why-is-the-dos-path-character/ https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh... http://www.htl-steyr.ac.at/~morg/pcinfo/hardware/interrupts/inte2zxs.htm http://www.htl-steyr.ac.at/~morg/pcinfo/hardware/interrupts/...
  - nolok 11y ago
    In terms of file path, windows seems to always support \\ or /, both in API or in software like Explorer. That's still true for Windows 10. That leads to some interesting answers on stackoverflow sometimes about cross compatibility, where the correct answer of "use whatever constant your language has for directory separator" gets down-voted in favor of "use forward slash everywhere".
    - pjmlp 11y ago
      Because it isn't the correct answer. Many applications assume \ and deal with paths directly, instead of using the Windows APIs for path manipulation. This means the moment your application gives a / to another application, there is a high probability that it will break, regardless of what the Windows API supports. Even cmd doesn't handle / properly.
simula67 11y ago
> I think folks using and learning .NET should have the same experience as with Go or Ruby. > Easy Compile and Run > Just "dotnet run" and it compiles AND executes As someone who does not follow the .NET landscape that closely can anyone explain why this is a big deal ? Java has been able to do 'javac Hello.java; java Hello' for as long as I can remember. If this was so important why are they getting around to it only now ?
- luchs 11y ago
  Do you actually use Java like this on any non-trivial project? This is intended to be a high-level tool that can be used as an alternative to IDEs.
- alkonaut 11y ago
  If java did the same it would be "java Hello" regardless of whether it was built or not. It would compile and run, or just run if it was already compiled. Not sure why that is a big deal but I do think the separation between jre and sdk in java is mostly a headache. I understand the end user doesn't need all the docs etc., but shipping the compiler with the runtime, why not?
  - pjmlp 11y ago
    It is been done for years by third party JVM vendors, but apparently many are too focused on the OpenJDK. Also, since Java 8 you can package everything together with the reference JDK, no need for third party tools any longer. This will be improved with the Java 9 modularity and possible AOT compilation in Java 10.
- nolok 11y ago
  Learning the tooling is a very hard barrier to entry. Not that it's difficult per se, but a lot of people will try something to "see how it is", and being able to just get it to run, right now, no multiple command no nothing, that let them concentrate on the interesting parts.
- maxlybbert 11y ago
  This is more along the lines of gcj than javac.
merb 11y ago
Oh my god. That is more than promising. That is really really awesome. Finally Microsoft will put something of that is useful for everybody.
recursive 11y ago
C# has had a command line compiler since... forever. Is the big news just --native mode?
- enricosada 11y ago
  the --native already exists, it's not a dotnet cli thing dotnet is a wrapper ( like git command ) for multiple executable, to replace msbuild as project file + build tool and add some new functionalities ( restore nuget packages, etc ) i think the real news is having a dumb project.json (nuget deps,source files,etc) and a xplat tool ( dotnet ) who read this project.json, and can restore packages, compile ( --native too ), publish, packages as another nuget package, etc. All that xplat and multiple language. c# works, F# got merged last week, other coming next. Some example commands: - `dotnet new` scaffold a new project ( really simple atm ) - `dotnet restore` read dependencies from the project.json and download nuget packages - `dotnet compile` call the csc compiler ( with a wrapper `dotnet-compile-csc` ) with source files, defines, references from project.json, etc There is a good split of responsabilities, you can call dotnet-compile-csc if you want. dotnet cli bundle the roslyn compiler ( c#, vb ) and f# compiler, so ready to go for example `dotnet compile`. dotnet compile read project.json and call ( for c# ) the `dotnet-compile-csc` passing source list, defines, references, etc. dotnet-compile-csc doenst know about project.json, and call csc ( the c# compiler ). if --native, the `dotnet compile` then call a compiler from .net bytecode to native code It's more like a replacement for msbuild, with a really good command line story, and a common project file ( project.json ) who can be used from visual studio or vs code, or others ide ( it's a json file, dumb )
  - iheartmemcache 11y ago
    Completely off topic but I think I saw some of your work in the F# repo being merged upstream. Congratulations if I'm not confusing you with someone else!
    - enricosada 11y ago
      thx
pedrow 11y ago
Can anyone clarify - does this support any .NET language (C#, F#, mixed language)? In the 'fabulous' example, I can't see where the source code for "Hello World" actually is.
- bjg 11y ago
  Looks like they have compiler support for only C# (csc), and F# (fsc) right now. https://github.com/dotnet/cli/tree/master/src/Microsoft.DotNet.Tools.Compiler.Csc https://github.com/dotnet/cli/tree/master/src/Microsoft.DotN... https://github.com/dotnet/cli/tree/master/src/Microsoft.DotNet.Tools.Compiler.Fsc https://github.com/dotnet/cli/tree/master/src/Microsoft.DotN...
  - enricosada 11y ago
    dotnet cli is a new project. It use some good ideas from aspnet/dnx like project.json, but it's more easy to work with, less magic, more language agnostic. c# is used to bootstrap all tools, so it's the first supported language and the default. Nightly, dev build have f# support, but it's a beta ( merged last week, but it's ok ). f# dotnet cli (the wrapper for f# compiler) is a beta, but moving fast, not much todo. For example the f# support in dotnet new is in a pull request. The F# compiler built for coreclr ( bundled with dotnet cli, so ready to go ) is working pretty much, some stuff missing ( portable pdb for example ), f# coreclr is open source https://github.com/Microsoft/visualfsharp https://github.com/Microsoft/visualfsharp
- enricosada 11y ago
  mixed in same project ( project.json ), no you cannot do that (i mean c# source and f# source in same project ). You can have multiple project (same repo, different directories ) and reference one from another you can have each project.json use a different compiler setting the compilerName property ( csc for c#, or fsc for f# ) . A project can reference another project, so you can reference a F# project in a c# project, or the other way around. like now in .net with msbuild or other tools
  - tracker1 11y ago
ZenoArrow 11y ago
For those interested in projects like this, would recommend following the development of Xebec, it's a very new project (no code releases yet), but aims to offer a much simpler build system for F# projects: http://7sharpnine.com/Xebec/ http://7sharpnine.com/Xebec/

193 points by Nelkins 11y ago

I think the most exciting thing about this is the AOT compilation into a single binary (Go-style), something I've wanted for a long time [1]. [1] https://news.ycombinator.com/item?id=9590213 https://news.ycombinator.com/item?id=9590213

frik 11y ago
Aren't the plans for AOT to work only with WinStore apps?
- math 11y ago
  no - they first mentioned plans for cross platform go-style single binary compilation at connect (one of the videos here I believe: https://channel9.msdn.com/Events/Visual-Studio/Connect-event-2015/ https://channel9.msdn.com/Events/Visual-Studio/Connect-event...) and I'm pretty sure they've subsequently talked about it in more detail in one of the community standups.
  - mintplant 11y ago
    What's the difference between a "go-style" binary and any other statically-linked binary?
    - pjmlp 11y ago
      None, but apparently many seem to only ever seen static linked binaries in Go. So many write "go-style" as if it was something that was just invented by the Go team. So is the knowledge in our industry.
      - iheartmemcache 11y ago
        Now now, there are plenty of people in our industry who would cringe at even the term "go-style" as a description for statically linking libs in, though most of them have long since left HN by now. Finally got around to reading that PARC/Cedar doc you linked out a while back, last weekend. Interesting stuff. Thanks again.
        pjmlp 11y ago
        Glad you liked it.
      - rayiner 11y ago
        I imagine even grognards would describe many things as C/UNIX-style that actually have their roots in earlier systems.
        qwertyuiop924 11y ago
        Just ask pjlmp about it. He seems to still be bitter that the lispm and wirth's stuff lost to C and unix.
        qwertyuiop924 11y ago
        EDIT: pjmlp. I don't make a habit of getting people's usernames wrong, but that one's hard to read.
        pjmlp 11y ago
        No problem. :)
    - math 11y ago
      I wrote go-like because I think of C#/.NET and go as somewhat comparable and I'm not aware of any other language in a similar class that produces statically-linked binaries. However I'm pretty ignorant, so would not be surprised if there are many ... examples?
      - pjmlp 11y ago
        Any programming language that has AOT compilation to native code among its implementation choices. There are plenty to choose from, but if you want a list: PL/I, Algol, PL/M, Quick Basic, Turbo Basic, Quick Pascal, Turbo Pascal, C, C++, Ada, Eiffel, Haskell, Objective-C, OCaml, Delphi, Oberon, Oberon-2, Component Pascal, Mesa, Modula-2, Modula-2+, Modula-3,...
        qwertyuiop924 11y ago
        Do all of those support static linking with the default tooling? (That is to say, not just hypothetical support, but actual support) Jeez.
        pjmlp 11y ago
        Of course, once upon a time static linking was the only way. It is dynamic linking that is hard to implement, not the other way around.
        qwertyuiop924 11y ago
        I KNOW that. I just wanted to know if the native compilers for the languages you mentioned supported static compilation either through a switch or by default, or if it's something that somebody else would have to write.
        pjmlp 11y ago
        Initially by default, many of them are older than OSes with dynamic linking support. The ones with compilers that also support dynamic linking, either via a switch or via explicit dynamic modules.
    - nolok 11y ago
      A lot of today's developer have never done it with another language before and so knows it as "the thing that go does".
- KirinDave 11y ago
  They demoed it for Linux command line and touted that, so I doubt it.
  - jimmcslim 11y ago
    I'm hoping that Winforms/WPF apps are supported at some time soon.
    - JamesNK 11y ago
      You probably won't. This is .NET Core only. .NET Core is a cross platform slimmed down version of .NET and doesn't run Winforms or desktop WPF. Windows Store WPF is supported.
      - moonchrome 11y ago
        If they really wanted to they could open source Silverlight GUI framework. That was basically WPF lite. They can take out the video/DRM stuff and just put the GUI layer out there - it was ported to OSX so it's at least somewhat portable. It would be nice to have something like JavaFX for .NET - resurrected Silverlight could be it.
    - tonyedgecombe 11y ago
      and drivers.
    - iheartmemcache 11y ago
      What I've been doing is in my solutions is adopting the Adobe approach and keeping a separate project for QT with all of the UI 100% abstracted out into that. Cross-platform builds are pretty easy, I get all of the safety of C# along with all of the tooling on NuGet crossplatform, and native UI interfaces on all 3 platforms with QT. The only time I come close to touching Winforms/Silverlight or WPF is if a client is dead-set on using Telerik or whatever.
- deleted 11y ago
  [deleted]
- JamesNK 11y ago
  No. Currently .NET Native (AOT) is used with WinStore apps - in fact every Win10 .NET application in the store and on your computer HAS to be .NET Native - but the plan is to make compiling a native DLL possible for all .NET Core applications.

deleted 11y ago

[deleted]

tomcam 11y ago

Preach it, brother. That would get this former Microsoftie back to the fold.

csours 11y ago

.Net CLI, so ... powershell? This looks pretty cool. I wish powershell were slightly easier to set up and use, and that there was a repo for extensions other than "google it and then download".

travem 11y ago
Have you seen the capabilities enabled by the PowerShell Gallery[1] (script and module repository) and the PowerShellGet cmdlets[2] (for interacting with repositories like PowerShell Gallery)? It looks like a useful approach to solving this particular issue. [1] https://technet.microsoft.com/en-us/library/dn807169.aspx https://technet.microsoft.com/en-us/library/dn807169.aspx [2] https://www.powershellgallery.com/ https://www.powershellgallery.com/
derefr 11y ago
One of the major tenets of this is (from what I can tell) its multiplatform-ness: it would be able to ship as the tooling in the .NET Core release for any platform. Powershell is certainly a cool shell, but it is a shell, and that makes it much less likely to be ported+packaged everywhere (Pash exists, but I don't know whether it exists as, say, an Ubuntu PPA.) Whereas, when you release a language, you kind of want its tooling to go wherever it goes.
chadzawistowski 11y ago
Powershell is a shell that runs on the .Net virtual machine. Scott is showing off command-line tools for creating and compiling C# projects.
JamesNK 11y ago
No .NET CLI is a set of cross platform command line tools for making .NET applications.

donatj 11y ago

Dumb question, but if I install this on OS X does it support VB.Net or just C#? I have a ton of old CLI apps I wrote in VB.Net 10 years or so ago and it would be interesting to port them. Mono's support for VB.Net last I tested was not good.

iheartmemcache 11y ago
This looks like it includes C#, VB.NET, F#, and any other language that targets the CLR (Common Language Runtime, i.e., Microsoft's JVM). edit: Apparently not. Mea culpa! Also, I don't know how long ago you tried Mono + VB, but especially since MS started collaborating with Mono and offering upstream first-party support (~2 years), support for the IL has been almost production quality. (Now it is production quality - I'm running some of my customer ASP.NET applications which was built around the NHibernate rather than EF/MS SQL on full Linux infrastructure). Satya is making a ton of bold moves that are basically antithetical compared to the Ballmer-era MS. Visual Studio Code (yet-another-electron-based-editor) and Community, along with the ridiculous amount of open stuff on Github has effectively eliminated the vendor-lock-in stronghold that Microsoft previously had. Residual Office renewals and upgrades on the MS SQL stack will only get them so far. They're going full Docker[1] support on the new Windows Server stack, as well as full .NET support off the Windows stack, which is interesting to say the least. I wonder if we'll start seeing them buying out companies that are traditionally aligned with more-open-sourcey. A bold move they could make would be buying out Cognitect. Datomic could be a perfect fit for them. Integrate Visual Studio support (e.g. as good as IntelliJ/Cursive) and give CLJS first-party support (let Nolen take a lead spot on the TypeScript team) in VS and it could be a steal at even a few hundred million dollars. The talent (Hickey+Nolen) the developers who they bring over + the perception shift within the dev community + the Datomic itself is likely worth a half a billion to MS. [1] http://www.hanselman.com/blog/BrainstormingDevelopmentWorkflowsWithDockerKitematicVirtualBoxAzureASPNETAndVisualStudio.aspx http://www.hanselman.com/blog/BrainstormingDevelopmentWorkfl...
- donatj 11y ago
  It was maybe 2 or 3 years ago I poked around in it and failed to get much to run.

dcw303 11y ago

It's a nice idea, and anything that gives .NET developers more power at the command line is going to get a thumbs up from me. But "one command to rule them all" does feels a little broad. To take a ruby/rails/linux equivalent, this is apt-get, ruby, irb, rails and gem all rolled up together. Perhaps I'm just overly familiar with the unix small tools philosophy.

alkonaut 11y ago
> To take a ruby/rails/linux equivalent, this is apt-get, ruby, irb, rails and gem all rolled up together Once you have fetched ruby I'd be much happier if it was all one command "ruby" for fetching packages, building, running etc. That doesn't mean it can't be several pieces of code running in the end, but from the end user perspective one top level util for one set of tasks makes sense. Compare "git lfs foo baz" with "git-lfs foo baz". I think the first is a lot better, even if what happens is closer to the second.
enricosada 11y ago
there are multiple executables the dotnet is like git, so `dotnet compiler` just call `dotnet-compiler` the first level tools ( dotnet-compile, dotnet-restore ) read the project json ( the only supported project file atm ) and pass argument to second level tools. for example: - dotnet compiler call dotnet-compile - dotnet-compile read source files, references, defines from project.json and call dotnet-compile-csc with the source files as arguments. - dotnet-compile-csc call csc - if --native, another .net bytecode to native tools is called and csc (csharp compiler) is bundled with the dotnet cli package.

alpb 11y ago

In case you missed: "dotnet compile --native" is basically like the Go compiler, it statically links all the DLLs and produces a single PXE/ELF executable. This is the most exciting thing for me in the new dotnet CLI as a person writing Go full-time at Microsoft. Most developers will be able to take advantage of single-binary shipping, they'll just put that in a Docker container and happily run everywhere.

pjmlp 11y ago
Why does everyone need to bring up Go for what is a standard feature from AOT compilers to native code?
- KirinDave 11y ago
  Because it is 2016 I guess? So many languages did this for so long and then VMs got in vogue. Go not doing it was, for many people, a reminder it could be done. But for a managed language runtime like the CLR to start supporting it is a big deal.
  - pjmlp 11y ago
    I guess this tells how much mono-culture is still prevalent in the industry, with silo language programming and no CS knowledge. But I do agree it is a big deal, specially for getting more developers to adopt safer programming languages.
  - Skinney 11y ago
    Well, mono has supported this for a while now. This is what Xamarin.iOS is based on.
    - justncase80 11y ago
      This is true. It's funny because the api's have always existed in the Microsoft compliers but they would litterally throw not implemented errors when run. Mono actually implemented them.

jmspring 11y ago

I learn a lot from Hanselman, and as someone bridging multiple languages, platforms, and sdks while at MSFT, this is a new one for me. I'm adding this to my list for potential 20% time project exploration. Cross platform and cross language have their interesting aspects...

m0dest 11y ago

I'm so happy to see arguments specified with "-" and "--" (UNIX-style) instead of "/" (DOS-style). The DOS-style CLI arguments used by Microsoft's other command line tools seem like such a stubborn throwback to a long-lost war. "/" won the battle for folder path separators (see: URLs) and "-" won the battle for argument delimiters.

david-given 11y ago
Fun fact: most MS kernels, including DOS, supported "/" as a path separator. They were just filtered out of the command lines by the argument passing code. There was a system call which would tell the argument parser that you wanted a different switch character, and if you changed it to, say, "-", then "/" would work. Of course, not everything used the standard argument parser, so if you did change this you ended up in a world of pain because your tools would start behaving inconsistently, but it was theoretically possible. I've seen references to this code existing as late as XP, but I don't do Windows any more, so can't comment on later versions.
- userbinator 11y ago
  https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why-is-the-dos-path-character/ https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh... http://www.htl-steyr.ac.at/~morg/pcinfo/hardware/interrupts/inte2zxs.htm http://www.htl-steyr.ac.at/~morg/pcinfo/hardware/interrupts/...
- nolok 11y ago
  In terms of file path, windows seems to always support \\ or /, both in API or in software like Explorer. That's still true for Windows 10. That leads to some interesting answers on stackoverflow sometimes about cross compatibility, where the correct answer of "use whatever constant your language has for directory separator" gets down-voted in favor of "use forward slash everywhere".
  - pjmlp 11y ago
    Because it isn't the correct answer. Many applications assume \ and deal with paths directly, instead of using the Windows APIs for path manipulation. This means the moment your application gives a / to another application, there is a high probability that it will break, regardless of what the Windows API supports. Even cmd doesn't handle / properly.

simula67 11y ago

> I think folks using and learning .NET should have the same experience as with Go or Ruby. > Easy Compile and Run > Just "dotnet run" and it compiles AND executes As someone who does not follow the .NET landscape that closely can anyone explain why this is a big deal ? Java has been able to do 'javac Hello.java; java Hello' for as long as I can remember. If this was so important why are they getting around to it only now ?

luchs 11y ago
Do you actually use Java like this on any non-trivial project? This is intended to be a high-level tool that can be used as an alternative to IDEs.
alkonaut 11y ago
If java did the same it would be "java Hello" regardless of whether it was built or not. It would compile and run, or just run if it was already compiled. Not sure why that is a big deal but I do think the separation between jre and sdk in java is mostly a headache. I understand the end user doesn't need all the docs etc., but shipping the compiler with the runtime, why not?
- pjmlp 11y ago
  It is been done for years by third party JVM vendors, but apparently many are too focused on the OpenJDK. Also, since Java 8 you can package everything together with the reference JDK, no need for third party tools any longer. This will be improved with the Java 9 modularity and possible AOT compilation in Java 10.
nolok 11y ago
Learning the tooling is a very hard barrier to entry. Not that it's difficult per se, but a lot of people will try something to "see how it is", and being able to just get it to run, right now, no multiple command no nothing, that let them concentrate on the interesting parts.
maxlybbert 11y ago
This is more along the lines of gcj than javac.

merb 11y ago

Oh my god. That is more than promising. That is really really awesome. Finally Microsoft will put something of that is useful for everybody.

recursive 11y ago

C# has had a command line compiler since... forever. Is the big news just --native mode?

enricosada 11y ago
the --native already exists, it's not a dotnet cli thing dotnet is a wrapper ( like git command ) for multiple executable, to replace msbuild as project file + build tool and add some new functionalities ( restore nuget packages, etc ) i think the real news is having a dumb project.json (nuget deps,source files,etc) and a xplat tool ( dotnet ) who read this project.json, and can restore packages, compile ( --native too ), publish, packages as another nuget package, etc. All that xplat and multiple language. c# works, F# got merged last week, other coming next. Some example commands: - `dotnet new` scaffold a new project ( really simple atm ) - `dotnet restore` read dependencies from the project.json and download nuget packages - `dotnet compile` call the csc compiler ( with a wrapper `dotnet-compile-csc` ) with source files, defines, references from project.json, etc There is a good split of responsabilities, you can call dotnet-compile-csc if you want. dotnet cli bundle the roslyn compiler ( c#, vb ) and f# compiler, so ready to go for example `dotnet compile`. dotnet compile read project.json and call ( for c# ) the `dotnet-compile-csc` passing source list, defines, references, etc. dotnet-compile-csc doenst know about project.json, and call csc ( the c# compiler ). if --native, the `dotnet compile` then call a compiler from .net bytecode to native code It's more like a replacement for msbuild, with a really good command line story, and a common project file ( project.json ) who can be used from visual studio or vs code, or others ide ( it's a json file, dumb )
- iheartmemcache 11y ago
  Completely off topic but I think I saw some of your work in the F# repo being merged upstream. Congratulations if I'm not confusing you with someone else!
  - enricosada 11y ago
    thx

pedrow 11y ago

Can anyone clarify - does this support any .NET language (C#, F#, mixed language)? In the 'fabulous' example, I can't see where the source code for "Hello World" actually is.

bjg 11y ago
Looks like they have compiler support for only C# (csc), and F# (fsc) right now. https://github.com/dotnet/cli/tree/master/src/Microsoft.DotNet.Tools.Compiler.Csc https://github.com/dotnet/cli/tree/master/src/Microsoft.DotN... https://github.com/dotnet/cli/tree/master/src/Microsoft.DotNet.Tools.Compiler.Fsc https://github.com/dotnet/cli/tree/master/src/Microsoft.DotN...
- enricosada 11y ago
  dotnet cli is a new project. It use some good ideas from aspnet/dnx like project.json, but it's more easy to work with, less magic, more language agnostic. c# is used to bootstrap all tools, so it's the first supported language and the default. Nightly, dev build have f# support, but it's a beta ( merged last week, but it's ok ). f# dotnet cli (the wrapper for f# compiler) is a beta, but moving fast, not much todo. For example the f# support in dotnet new is in a pull request. The F# compiler built for coreclr ( bundled with dotnet cli, so ready to go ) is working pretty much, some stuff missing ( portable pdb for example ), f# coreclr is open source https://github.com/Microsoft/visualfsharp https://github.com/Microsoft/visualfsharp
enricosada 11y ago
mixed in same project ( project.json ), no you cannot do that (i mean c# source and f# source in same project ). You can have multiple project (same repo, different directories ) and reference one from another you can have each project.json use a different compiler setting the compilerName property ( csc for c#, or fsc for f# ) . A project can reference another project, so you can reference a F# project in a c# project, or the other way around. like now in .net with msbuild or other tools
- tracker1 11y ago

ZenoArrow 11y ago

For those interested in projects like this, would recommend following the development of Xebec, it's a very new project (no code releases yet), but aims to offer a much simpler build system for F# projects: http://7sharpnine.com/Xebec/ http://7sharpnine.com/Xebec/