Merge master into release

.vscode/launch.json

@@ -11,7 +11,9 @@
             ],
             "stopOnEntry": false,
             "sourceMaps": true,
-            "outDir": "${workspaceRoot}/out/src"
+            "outFiles": [
+                "${workspaceRoot}/out/src/**/*.js"
+            ]
         },
         {
             "name": "Launch Tests",
@@ -21,7 +23,9 @@
             "args": ["--extensionDevelopmentPath=${workspaceRoot}", "--extensionTestsPath=${workspaceRoot}/out/test" ],
             "stopOnEntry": false,
             "sourceMaps": true,
-            "outDir": "${workspaceRoot}/out/test"
+            "outFiles": [
+                "${workspaceRoot}/out/test/**/*.js"
+            ]
         }
     ]
 }

CHANGELOG.md

@@ -1,9 +1,49 @@
-## Known Issues
+## Known Issues in 1.8.1
 
 * Running and debugging of tests are not supported in .csproj-based .NET Core projects. However, there will still be clickable "run test" and "debug test" indicators above test methods. ([#1100](https://github.com/OmniSharp/omnisharp-vscode/issues/1100))
 * When opening a .csproj-based .NET Core project in VS Code, the C# extension will not activate until a C# file is opened in the editor. ([#1150](https://github.com/OmniSharp/omnisharp-vscode/issues/1150))
 * There currently is no completion support for package references in csproj files. ([#1156](https://github.com/OmniSharp/omnisharp-vscode/issues/1156))
 
+## 1.9.0 _(Not Yet Released)_
+
+#### Unit Testing
+
+* Support added for running and debugging unit tests in .csproj-based .NET Core projects. ([#1100](https://github.com/OmniSharp/omnisharp-vscode/issues/1100))
+
+#### Debugger
+
+* **Arch Linux change**: Before, the debugger would automatically use the Ubuntu 16 debugger on Arch. Now we require the debugger to be explicitly set. See https://aka.ms/vscode-csext-arch for more information.
+* Several bug fixes that addressed problems with launch ([#1335](https://github.com/OmniSharp/omnisharp-vscode/issues/1335), [#1336](https://github.com/OmniSharp/omnisharp-vscode/issues/1336))
+* Fixed several pipeTransport issues including introducing a new `quoteArgs` option ([#1318](https://github.com/OmniSharp/omnisharp-vscode/issues/1318)), and fixing attach with Docker ([#1369](https://github.com/OmniSharp/omnisharp-vscode/issues/1369))
+* Fix issue where VS Code would incorrectly display threads as paused ([#1317](https://github.com/OmniSharp/omnisharp-vscode/issues/1317))
+* Added new 'csharp.fallbackDebuggerLinuxRuntimeId' configuration setting to control the version of the debugger used on Linux ([#1361](https://github.com/OmniSharp/omnisharp-vscode/issues/1361)).
+* Added a new `clr` debugging `type` in launch.json to enable debugging for Azure scenarios. That type is limited to Windows Desktop CLR, 64-bit processes, and only supports the [Portable PDB debug format](https://github.com/OmniSharp/omnisharp-vscode/wiki/Portable-PDBs).
+* Added support for the launch.json editor's 'Add Configuration' button ([#1024](https://github.com/OmniSharp/omnisharp-vscode/issues/1024]))
+
+#### Project System
+
+* Properly handle package references with version ranges in .csproj (PR: [omnisharp-roslyn#814](https://github.com/OmniSharp/omnisharp-roslyn/pull/814))
+* Fix regression with MSBuild project system where a project reference and a binary reference could be added for the same assembly, causing ambiguity errors ([omnisharp-roslyn#795](https://github.com/OmniSharp/omnisharp-roslyn/issues/795), PR: [omnisharp-roslyn#815](https://github.com/OmniSharp/omnisharp-roslyn/pull/815))
+* If VS 2017 is on the current machine, use the MSBuild included with VS 2017 for processing projects. ([#1368](https://github.com/OmniSharp/omnisharp-vscode/issues/1368), PR: [omnisharp-roslyn#818]()https://github.com/OmniSharp/omnisharp-roslyn/issues/818)
+* Fixed null reference exception in DotNetProjectSystem when project reference is invalid (PR: [omnisharp-roslyn#797](https://github.com/OmniSharp/omnisharp-roslyn/pull/797))
+
+#### Improved OmniSharp Settings
+* Added support for global omnisharp.json file ([omnisharp-roslyn#717](https://github.com/OmniSharp/omnisharp-roslyn/issues/7170), PR: [omnisharp-roslyn#809](https://github.com/OmniSharp/omnisharp-roslyn/pull/809)) _(Contributed by [@filipw](https://github.com/filipw))_
+
+  This file can appear in one of the following locations:
+  * Windows: `%APPDATA%\OmniSharp\omnisharp.json`
+  * macOS/Linus: `~/.omnisharp/omnisharp.json`
+* Watch local and global omnisharp.json files for changes while OmniSharp is running. Currently, this only works for formatting options. (PR: [omnisharp-roslyn#804](https://github.com/OmniSharp/omnisharp-roslyn/pull/804))_(Contributed by [@filipw](https://github.com/filipw))_
+* New 'omnisharp.waitForDebugger' setting to make it easier to debug the OmniSharp server itself. (PR: [#1370](https://github.com/OmniSharp/omnisharp-roslyn/pull/1370))
+
+#### Other Updates and Fixes
+
+* Improvements made to project.json package completion experience. ([#1338](https://github.com/OmniSharp/omnisharp-vscode/pull/1338))
+* Diagnostics are no longer created for hidden diagnostics, addressing the problem of "Remove Unnecessary Usings" spam in the Problems pane. ([#1231](https://github.com/OmniSharp/omnisharp-vscode/issues/1231))
+* Improved the extension's runtime dependency download logic to skip re-downloading packages that were already successfully downloaded and installed.
+* Assets for building and debugging are now always generated with POSIX style paths. ([#1354](https://github.com/OmniSharp/omnisharp-vscode/pull/1354))
+* Don't offer to generate tasks.json if build task already exists. (PR #1363) _(Contributed by [@eamodio](https://github.com/eamodio))_
+
 ## 1.8.1 (March 31, 2017)
 
 Fixes debugging on macOS Sierra 10.12.4.

README.md

@@ -34,7 +34,7 @@ See our [change log](https://github.com/OmniSharp/omnisharp-vscode/blob/v1.8.0/C
 
 ### Supported Operating Systems for Debugging
 
-* Currently, the C# debugger supports the following operatings systems:
+* Currently, the C# debugger supports the following operating systems:
 
   * Windows (64-bit only)
   * macOS
@@ -64,7 +64,7 @@ To **run and develop** do the following:
 * Run `npm i`
 * Run `npm run compile`
 * Open in Visual Studio Code (`code .`)
-* *Optional:* run `tsc -w`, make code changes (on Windows, try `start node ".\node_modules\typescript\bin\tsc -w"`)
+* *Optional:* run `npm run watch`, make code changes
 * Press <kbd>F5</kbd> to debug
 
 To **test** do the following: `npm run test` or <kbd>F5</kbd> in VS Code with the "Launch Tests" debug configuration.

debugger-launchjson.md

@@ -0,0 +1,112 @@
+# Configurating launch.json for C# debugging
+The launch.json file is used to configure the debugger in Visual Studio Code.
+
+Visual Studio Code generates a launch.json with almost all of the required information. 
+If your workspace has only one launchable project, the C# extension will offer to automatically generate this file. 
+If you missed this prompt, you can force the generation by executing the command `.NET: Generate Assets for Build and Debug` from the VS Code command palette.
+The generated file contains two sections. One that configures debugging for launch and a second that configures debugging for attach.
+
+If you have more than one launchable project, then you will need to modify your launch.json file by hand. 
+Visual Studio Code will still generate a basic template, but you will need to fill in the 'program' field to point at the executable dll that you would like to debug.
+
+
+# Configurating VS Code's debugging behavior
+
+## PreLaunchTask
+The `preLaunchTask` field runs the associated taskName in tasks.json before debugging your program. You can get the default build prelaunch task by executing the command `Tasks: Configure Tasks Runner` from the VS Code command palette.
+
+This will create a task that runs `dotnet build`. You can read more about tasks at [https://code.visualstudio.com/docs/editor/tasks](https://code.visualstudio.com/docs/editor/tasks).
+
+## Program
+The program field is set to the path to the application dll or .NET Core host executable to launch. 
+
+Example: "${workspaceRoot}/bin/Debug/\<target-framework\>/\<project-name.dll\>" where:
+
+* \<target-framework\>: (example: 'netstandard1.5') This is the framework that the app is being built for. It is set in the project.json file.
+* \<project-name\>: (example: 'MyApp') The name of the project being debugged.",
+
+## Cwd
+The working directory of the target process.
+
+## Args
+These are the arguments that will be passed to your program.
+
+## Stop at Entry
+If you need to stop at the entry point of the target, you can optionally set `stopAtEntry` to be "true".
+
+## Launch Browser
+The launch browser field can be optionally added if you need to launch with a web browser.
+If there are web server dependencies in your project.json, the auto generated launch file will add launch 
+browser for you. It will open with the default program to handle URLs.
+
+## Environment variables
+Environment variables may be passed to your program using this schema:
+
+    "env": {
+        "myVariableName":"theValueGoesHere"
+    }
+
+## Console (terminal) window
+By default, processes are launched with their console output (stdout/stderr) going to the VS Code Debugger Console. This is useful for executables that take their input from the network, files, etc. But this does NOT work for applications that want to read from the console (ex: `Console.ReadLine`). For these applications, use a setting such as the following:
+
+    "console": "integratedTerminal"
+
+When this is set to `integratedTerminal` the target process will run inside [VS Code's integrated terminal](https://code.visualstudio.com/docs/editor/integrated-terminal). Click the 'Terminal' tab in the tab group beneath the editor to interact with your application.
+
+When this is set to `externalTerminal` the target process will run in a separate terminal.
+
+## Source File Map
+You can optionally configure a file by file mapping by providing map following this schema:
+
+    "sourceFileMap": {
+        "C:\foo":"/home/me/foo"
+    }
+
+## Symbol Path
+You can optionally provide paths to symbols following this schema:
+
+    "symbolPath": [ "/Volumes/symbols" ]
+
+## Just My Code
+You can optionally disable `justMyCode` by setting it to "false". You should disable Just My Code when you are trying to debug into a library that you pulled down which doesn't have symbols or is optimized.
+
+    "justMyCode":false*
+
+Just My Code is a set of features that makes it easier to focus on debugging your code by hiding some of the details of optimized libraries that you might be using, like the .NET Framework itself. The most important sub parts of this feature are --
+
+* User-unhandled exceptions: automatically stop the debugger just before exceptions are about to be caught by the framework
+* Just My Code stepping: when stepping, if framework code calls back to user code, automatically stop.
+
+## Require Exact Source
+The debugger requires the pdb and source code to be exactly the same. To change this and disable the sources to be the same add:
+
+    "requireExactSource": false
+
+## Stepping into properties and operators
+The debugger steps over properties and operators in managed code by default. In most cases, this provides a better debugging experience. To change this and enable stepping into properties or operators add:
+
+    "enableStepFiltering": false
+
+## Logging
+You can optionally enable or disable messages that should be logged to the output window. The flags in the logging field are: 'exceptions', 'moduleLoad', 'programOutput', 'engineLogging', and 'browserStdOut'.
+
+## PipeTransport
+If you need to have the debugger to connect to a remote computer using another executable to relay standard input and output bewteen VS Code and the .NET Core debugger backend (vsdbg), 
+then add the pipeTransport field folloing this schema:
+
+    "pipeTransport": {
+        "pipeProgram": "ssh",
+        "pipeArgs": [ "-T", "ExampleAccount@ExampleTargetComputer" ],
+        "debuggerPath": "~/vsdbg/vsdbg",
+        "pipeCwd": "${workspaceRoot}",
+        "quoteArgs": true
+    }
+
+More information about pipe transport can be found [here](https://github.com/OmniSharp/omnisharp-vscode/wiki/Attaching-to-remote-processes).
+
+You can find information on configuring pipe transport for [Windows Subsystem for Linux](https://msdn.microsoft.com/en-us/commandline/wsl/about) (WSL) [here](https://github.com/OmniSharp/omnisharp-vscode/wiki/Windows-Subsystem-for-Linux).
+
+## Operating System Specific Configurations
+If there specific commands that need to be changed per operating system, you can use the fields: 'windows', 'osx', or 'linux'. 
+You can replace any of the fields mentioned above for the specific operating system.
+

debugger.md

@@ -1,18 +1,18 @@
-#Instructions for setting up the .NET Core debugger
+# Instructions for setting up the .NET Core debugger
 This page gives you detailed instructions on how to debug code running under .NET Core in VS Code. 
 
-####Your Feedback​
+#### Your Feedback​
 File bugs and feature requests [here](https://github.com/OmniSharp/omnisharp-vscode/issues) and [join our insiders group](http://landinghub.visualstudio.com/dotnetcoreinsiders) to help us build great tooling for .NET Core.
 
-####Requirements
+#### Requirements
 * Requires .NET Core 1.0 (rc2 are earlier releases are not supported)
 * X64 only
 * Supported operating systems: 
     * macOS: 10.11+ (El Capitan+)
     * Linux: Red Hat Enterprise Linux 7.2+, Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, Debian 8.2+, Linux Mint 17+, CentOS 7.1+, Oracle Linux 7.1+, Fedora 23, openSUSE 13.2
     * Windows: 7+
 
-###First Time setup
+### First Time setup
 ##### 1: Get Visual Studio Code
 Install Visual Studio Code (VSC). Pick the latest VSC version from here: https://code.visualstudio.com Make sure it is at least 1.5. 
 
@@ -35,9 +35,8 @@ If you have previously installed the C# extension, make sure that you have a rec
 The first time that C# code is opened in VS Code, the extension will download the platform-specific files needed for debugging and editing. Debugging and editor features will not work until these steps finish.
 
 
-###Once for each project
+### Once for each project
 The following steps have to executed for every project. 
-
 ##### 1: Get a project
 You can start from scratch by creating an empty project with `dotnet new`. Begin by opening the terminal in Visual Studio Code (`View->Integrated Terminal`) and type these commands:
 
@@ -80,56 +79,14 @@ If your code has multiple projects or you would rather generate these files by h
 ##### 4: Start debugging
 Your project is now all set. Set a breakpoint or two where you want to stop, click the debugger play button (or press <kbd>F5</kbd>) and you are off.
 
-###Debugging Code compiled on another computer
+### Debugging Code compiled on another computer
 If your code was built on a different computer from where you would like to run in there are a few things to keep in mind --
 
-* **Source Maps**: Unless your local source code is at exactly the same path as where the code was originally built you will need to add a [sourceFileMap](#source-file-map) to launch.json.
+* **Source Maps**: Unless your local source code is at exactly the same path as where the code was originally built you will need to add a [sourceFileMap](https://github.com/OmniSharp/omnisharp-vscode/blob/master/debugger-launchjson.md#source-file-map) to launch.json.
 * **Portable PDBs**: If the code was built on Windows, it might have been built using Windows PDBs instead of portable PDBs, but the C# extension only supports portable PDBs. See the [portable PDB documentation](https://github.com/OmniSharp/omnisharp-vscode/wiki/Portable-PDBs#how-to-generate-portable-pdbs) for more information.
-* **Debug vs. Release**: It is much easier to debug code which has been compiled in the `Debug` configuration. So unless the issue you are looking at only reproduces with optimizations, it is much better to use Debug bits. If you do need to debug optimized code, you will need to disable [justMyCode](#just-my-code) in launch.json.
-
-####More things to configure In launch.json
-#####Just My Code
-You can optionally disable justMyCode by setting it to "false". You should disable Just My Code when you are trying to debug into a library that you pulled down which doesn't have symbols or is optimized.
-
-    "justMyCode":false*
-
-Just My Code is a set of features that makes it easier to focus on debugging your code by hiding some of the details of optimized libraries that you might be using, like the .NET Framework itself. The most important sub parts of this feature are --
-
-* User-unhandled exceptions: automatically stop the debugger just before exceptions are about to be caught by the framework
-* Just My Code stepping: when stepping, if framework code calls back to user code, automatically stop.
-
-#####Source File Map
-You can optionally configure a file by file mapping by providing map following this schema:
-
-    "sourceFileMap": {
-        "C:\foo":"/home/me/foo"
-    }
-
-#####Symbol Path
-You can optionally provide paths to symbols following this schema:
-
-    "symbolPath": [ "/Volumes/symbols" ]
-
-#####Environment variables
-Environment variables may be passed to your program using this schema:
-
-    "env": {
-        "myVariableName":"theValueGoesHere"
-    }
-
-#####Console (terminal) window
-By default, processes are launched with their console output (stdout/stderr) going to the VS Code Debugger Console. This is useful for executables that take their input from the network, files, etc. But this does NOT work for applications that want to read from the console (ex: `Console.ReadLine`). For these applications, use a setting such as the following:
-
-    "console": "integratedTerminal"
-
-When this is set to `integratedTerminal` the target process will run inside [VS Code's integrated terminal](https://code.visualstudio.com/docs/editor/integrated-terminal). Click the 'Terminal' tab in the tab group beneath the editor to interact with your application.
-
-When this is set to `externalTerminal` the target process will run in a separate terminal.
-
-##### Stepping into properties and operators
-The debugger steps over properties and operators in managed code by default. In most cases, this provides a better debugging experience. To change this and enable stepping into properties or operators add:
+* **Debug vs. Release**: It is much easier to debug code which has been compiled in the `Debug` configuration. So unless the issue you are looking at only reproduces with optimizations, it is much better to use Debug bits. If you do need to debug optimized code, you will need to disable [justMyCode](https://github.com/OmniSharp/omnisharp-vscode/blob/master/debugger-launchjson.md#just-my-code) in launch.json.
 
-    "enableStepFiltering": false
+#### [Configurating launch.json for C# Debugging](debugger-launchjson.md)
 
 #### Attach Support
 The C# debugger supports attaching to processes. To do this, switch to the Debug tab, and open the configuration drop down.