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.
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.
In fact, the package I used for the compiler binaries contains the csc + vbc compilers, so it's literally just shoveling some command line arguments down the pipe.
It's definitely on my to-do list. :)
Annoyingly it seems to work differently to how DNX builds. With my project [1] I have spent what felt like an age setting up a .NET Core supported project.json that builds with 'dnx build'; the result is horror slow compilation and maxed out CPU usage whenever I build in VS2015, even if nothing has changed - actually borderline unusable. I have rebuilt all of the csproj files and the sln that I originally deleted to make way for the project.json and xproj files. So I now have:
* project.json per folder
* <project name>.project.json per folder
* <project name>.csproj per folder
* <project name>.xproj per folder
* <project name>.sln per folder
So I thought I'd give this (dotnet CLI) a go. I can't run from the root because there's not a project.json there. If I go into the Core project then it compiles OK (on OSX with no issues), but builds in the <project>/bin folder like MSBuild. That means the other projects in the repo can't find their references like they can with the DNX artifact system. It seems to me that it should support the same DNX project.json/global.json dependency system.
Whilst I support the general direction MS is taking with DNX and 'dotnet'. The whole system is a buggy inconsistent mess and has recently lost me weeks of time trying to figure out the magic combination of settings that are needed to support cross-platform builds (actually most of the time has been spent waiting for builds, waiting for VS2015 to stop locking up, or giving VS2015 enough 'lock up time' before killing it from the Task Manager and starting again).
I'm also not sure MS has quite prepared itself for the public evolution of their tools and source. It has lead to a trail of misinformation throughout the web - and I for one have found the process incredibly difficult to follow. Trying to piece together what is going-on through github issues on the aspnet/dnx/fsprojects repos is tedious. I still don't really know if I'm doing it right and the 'official' help is light on details at best.
The dotnet-cli stuff is super new so a lot of the tooling is incompatible right now. As things start to settle out more in the next few weeks a plan to write a series of blog posts about how things work, general development approaches, and where you can expect to hit rough edges.
Thanks for the feedback, though! We're definitely a bit new to this style of development.
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/BrainstormingDevelopmentWorkfl...
I doubt a bright person such as David Nolen would like to work with TypeScript as it is right now.
IMHO of course.
MS gets the Clojure (and maybe more importantly the CLJS userbase), Cognitect gets massive reach (CLJS is subsidized solely by the licensing of Datomic by strict revenue), MS' corporate customers get Datomic. Just going by the direction MS has been in lately ("embrace & extend") under the new anti-Ballmer role, floating an offer of 300-500 million would be beneficial to everyone involved. Let's say there are conservatively 100k Clj(s) users out there right now using Clojure + Sun's JVM. At 300 million that's 3k per active developer acquired right off the bat. You'll lose maybe 10% of the users who live-by-their-Macbook-and-die-by-their-iPhone. Even at 600 million, that's still a cheap price to pay.