For the 64 bit warning, it now opens the link directly with a 'See more info' instead of having to copy the link. There's also a 'Don't warn again' option
Our project settings were being completely ignored in multi-root workspaces. Here's what I did to fix that:
1. Declare our project-based settings as 'resource' scope (If you use the default scope of 'window', then settings only apply at the user/workspace level - not the workspaceFolder level)
1. Pass the projectPath in when getting settings so that the specific folder takes precedent
1. Modify the workspace folder picker so that it dynamically gets the subpath for each folder
1. Fix 'update' for mutli-root settings: If you don't pass the ConfiguratonTarget, it uses the appropriate scope from the configuration (Workspace vs WorkspaceFolder)
This is what currently happens if you try to create a function without a language/runtime set:
1. Language is an empty string, but user isn't prompted to set it
1. Runtime is an empty string, and user _is_ prompted
1. We try to find the templates matching the user's settings, but we can't find any so we prompt them for all three values again (language, runtime, and filter)
Instead, we should prompt them in step 1 & 2 and then we don't have to prompt for step 3. (Step 3 is only meant to happen if the user changes their settings to something like 'Python', 'beta', and 'Verified' - which has no templates)
1. The type for the launch.json should be 'clr' instead of 'coreclr'
1. We have to show a warning about attaching to 64 bit processes
1. Allow for func.exe possibly being renamed to func64.exe
1. The regex for the process was wrong. Specifically, we want to match these two strings (v1 and v2 of the runtime)
```
emjdev3,C:\Users\erijiz\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin/func.exe host start,func.exe,10608
emjdev3,dotnet C:\Users\erijiz\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin/Azure.Functions.Cli.dll host start,dotnet.exe,10528
```
But we don't want to match these (other languages than C#):
```
emjdev3,C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -Command func host start,powershell.exe,10020
emjdev3,C:\WINDOWS\system32\cmd.exe /c ""C:\Users\erijiz\AppData\Roaming\npm\func.cmd" host start",cmd.exe,3664
emjdev3,node "C:\Users\erijiz\AppData\Roaming\npm\\node_modules\azure-functions-core-tools\lib\main.js" host start,node.exe,8700
```
* Include more detail about v1.0 vs v2.0
* Explain how to uninstall/reinstall C# templates
* Move language specific sections down the page
* dotnet cli -> .NET CLI
1. Switch away from ps-node on windows because it is very slow
1. Stop and restart the functions host if it is running when the user starts debugging
1. Only build once when the user F5's instead of twice
1. Allow windows users to install either the .NET Core _or_ .NET Framework templates
1. Provide commands to install/uninstall the templates
1. Limit function templates to just the main 4
1. Detect if the project created was .NET Core or .NET Framework and set runtime accordingly
Since a project is basically a new 'workspace', it doesn't make sense to use settings from the 'previous' workspace. Instead, only respect global settings.
This supports project/function creation and local debugging. It does not include deploy logic.
A brief summary:
1. We default C# projects to beta runtime and class library (instead of C# script)
1. We use dotnet templates for project/function creation. We will automatically install the templates for the user if they are not on their machine (I don't prompt at all - let me know if you think we should prompt).
1. We use the parameter information from the functions portal (Aka C# Script templates) since it's easier to parse than the dotnet cli and it gives us more information (like validation). This requires us to assume that parameters for C# Scripts are the same as the parameters for the C# Class libraries. Since that might not always be the case, I mitigated this with unit tests and hard-coding the version of the dotnet templates.
1. Unlike JavaScript debugging, we have to attach to a specific process instead of attaching with a port. I implemented a 'pickProcess' command to search for the functions host process.
1. This only works on Windows. There's a few issues on a Mac I still need to iron out.
Turns out we want to add support for class libraries (.cs), but this code added support for C# script files (.csx). I want to leave this code in the git history in case we add support for .csx _in addition_ to .cs
* Add CSharp to the list of options when creating a new project
* Add setting for projectLanguage
* The user has many options for language, but only C#/Java/JavaScript can be debugged in VS Code today. The rest only support create & deploy
* If it's not set (for example in old projects before this release), the user will be prompted one time and their workspace setting will be updated
* Add setting for projectRuntime
* We want to use ~1 for JavaScript and beta as the default for Java/C#
Matt Hernandez
Eric Jizba
Sheng Chen
Jay Wang
chrisdias