Microsoft declares that new version of .Net and new alternative dev tool Visual Studio Code will be available for multiple platforms, including Linux.
In this post I will try to describe my Visual Studio Code usage experience. I will not describe .Net Code or DNX or Mono in details and focus on Visual Studio. I will use mono because .Net Core/DNX currently is incomplete and debugging using it is highly complicated under Linux. So I decided to use mono for now and switch to newer technologies later. I’m currently using Ubuntu 15.10 but all described things should work in the same way in 14.04 and any other Debian based on Linux.
First of all, you will need to setup latest mono version. In Canonical repository you always will find old version, not sure why maybe some stability consideration but I’m not sure that Canonical guys test mono 🙂
Any way to install latest mono go to http://www.mono-project.com/docs/getting-started/install/linux/#debian-ubuntu-and-derivatives and follow the instructions about how to add mono repository and install latest version.
Next let us install Visual Studio Code. You can download latest version here https://code.visualstudio.com/ Downloaded file is just archive with application no installation process required just unpack and start.
Also for some VS Code functionality you will need DNX. Install it according to http://docs.asp.net/en/latest/getting-started/installing-on-linux.html or run following commands to install DNX for mono:
curl -sSL https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.sh | DNX_BRANCH=dev sh && source ~/.dnx/dnvm/dnvm.sh
dnvm upgrade -r mono
There is no projects and solutions as it was in usual Visual Studio. General idea of visual studio code is that project folder contains all project related files and only project related files. Also all project related files are programs on some human readable language (C#, JS, JSON, etc.) no more magic files with magic GUIDs. Thus you can only open project folder not project file with VS code and configure you project with any text editor, you can merge project configuration with merge tool, you can parse project configuration with some automation tools or do any other task based on documented and clear configuration files.
We still need project description files
If you open folder with code and with no project files in VisualStudio, you will be able to use VS Code as smart text editor and nothing more. However any modern IDE should have code suggestions, code navigation, in-place error highlighting, debugging and so on. Be sure VisualStudio Code supports this features and support them on higher level than VS 2015 Community Edition. But to enable all these features you have to explain VS some details about your code – create project file.
What files can be used to configure project?
Old project and solution files
VS Code supports
*.sln and project files. You cannot open solution file but code parsing services will be able to locate and read solution/project files when you open solution folder.
File named project.json is the main project configuration file. You can have several subprojects in your project and configure every project separately with project.json, in case of .net every project file will produce an assembly. See example below.
"define": ["DEBUG", "TRACE"]
"define": ["RELEASE", "TRACE"],
This configuration file describes two configurations Debug and Release with different optimization settings and specific define directives, defines one framework – dnx451 with used framework assemblies and specifies required nuget packages in “dpendencies” section. Compile section says that project should include all *.cs files in all subdirectories (
/**/ – means any subdir).
Please note that project.json file is a part of DNX build system and you have to install DNX to make it work.
Full specification of project file can be found here https://github.com/aspnet/Home/wiki/Project.json-file.
If you have several projects, you can group them together and explain VS Code that all project.json should be treaded as parts of some solution with global.json file.
One of my
global.json file looks like following:
It just contains a list of all projects. You can find description of global.json file here http://docs.asp.net/en/latest/conceptual-overview/understanding-aspnet5-apps.html#the-global-json-file
Here is an example of tasks.json file of one of my real project that have mono back-end and typescript/html/less front-end.
"problemMatcher": ["$tsc", "$lessCompile",
"regexp": "(error)(ed after)",
As you can see, there are some global settings like command and args. Command in this file means what command should be executed to perform build actions. And yes, the command is global for all tasks. The command can be configured only once because with command you should specify build tool like msbuild, make or gulp in my case and every command is a target for build tools.
Actual command line will look like
Default task in my sample has isBuildCommand=true this means that VS Code should use this to build my project. You can execute build task by Ctrl+Shift+B shortcut.
To execute other tasks you can press F1 and then type
Run Task followed by Enter. This will list all available tasks. Select one and press Enter to execute the task.
To parse result of any task you can specify problemMatcher. Problem matcher is just a pattern to extract build errors, warning and any other messages. All extracted errors are shown as error list in VS Code and are shown in-place in your code as it was in usual VS. You can use one of existing problem matchers or define your own with regular expression pattern.
Some of available problem matchers
- $msCompile – Microsoft compiles (C# or C++)
- $lessCompile – Less files compiler
- $tsc – TypeScript compiler
- $gulp-tsc – TypeScript compiler implemented as gulp task
Some notes about single command for all tasks and build tools
At first I was thinking as experienced user of usual Visual Studio Enterprise where we have a build and a lot of other “crunches” that allow us to automate tasks – “WTF same command for all tasks???”. But later I noted that usually we have to write another “build-crunches” to execute all this “crunches” on build machine. In VS Code you are configuring build stages(targets) as tasks and should perform them thought your build tool. That is a kind of DRY principle applied to build scripts. Write any task and you will be able to use it build machine.
VS Code tasks are powerful tool that allows us to use any build system and integrate it with code editor.
For more information about tasks see following links.
lunch.json describes how to execute end debug application when you press F5 key. Here is an example from one of my projects:
Currently VS Code supports only two lunch configurations: “Launch” and “Attach” to start debugging and attach to already started process. You can specify type of application, currently only “mono” or “node” are supported under Linux and specify program to start or host/port to attach debugger to.
Unfortunately there is no way to debug .Net Core in VS Code under Linux now. Hope to see it in the nearest future. The most significant problem here is .pdb/.mdb files problem. VS Code for Linux supports mono code mapping files and .Net Core supports usual pdb files. Hope it is just a question of time as far as under Windows VS Code can debug .Net applications.
Ensure that project description is parsed correctly
When you open folder with just project.json file, VS Code automatically parses this file and enables functionality like suggestions and code navigation. In this case you will see “Running” status bar indicating that VS Code is parsing project file.
When project is parsed successfully you will see status like following.
By clicking on project name in status bar you can select project file manually.
In some cases VS Code will not be able to select project file. In such case it will show “Select project” green text in status bar and you will have to select project file manually.
When project file is parsed by VS you will be able to use functionality like code navigation, suggestions, etc.
Built-in GIT support
VS Code has built-in git client. That allows you to perform simple git tasks like push/pull, rebase, commit, select files for commit, revert specific files and so on. More complex tasks like view history and merge conflicts look not very nice in current version of VS Code and are more likely you will use some external tools for these tasks.
Other languages and technology support
Visual studio code supports a lot of languages except C# and support of some languages is even better that in VS Enterprise
|Syntax coloring, bracket matching||Batch, C++, Clojure, Coffee Script, Dockerfile, F#, Go, Jade, Java, HandleBars, Ini, Lua, Makefile, Objective-C, Perl, PowerShell, Python, R, Razor, Ruby, Rust, SQL, Visual Basic, XML|
|Snippets||Groovy, Markdown, PHP, Swift|
|Refactoring, find all references||TypeScript, C#|
- You can use Visual Studio Code write, refactor and debug .Net/Mono (C#) code under any OS
- Support of other languages makes VS Code highly efficient tool for mixed projects with TypeScript, Less and C# code for example.
- Support of custom build tools adds more value to VS Code as tool for complex mixed projects
- All project configurations are human readable JSON that can be easy maintained
- VS Code has built in git support that solves 90% of tasks
- Usage of VS Code requires another point of view on development – usage of easy to understand config files instead of wizards
See my next post for sample project.