No VB yet, but that's just because I haven't had time to do it yet -- VB is trivial to add support for.
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.
I hope you don't mind me replying here. I figure if you're working on the tools you might appreciate some feedback...
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
The per xproj sln is tedious just so I can tick a box saying 'Produce output', like I'd ever not want to produce output. Total mess.
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.
Totally understandable -- a lot of this stuff is really new, so we've fallen a bit behind on documentation, partially because we're not exactly sure how some stuff should work, so we don't want to mislead people.
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.
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. :)