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
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#
1. Moved deploy to the explorer menu bar instead of right click menu on function app
1. Removed 'zip' wording
1. Only added 'Create Function App' to subscription and command palette for now
1. Prompt with existing App Settings before listing resources
1. Add support for storage resource type
1. Validate AzureWebJobsStorage app setting before creating non-HTTP triggers
Also:
1. Use secure random string
1. Slightly modify newline rules that are being annoying
1. Remove '--type-check' from lint command since it's deprecated and no longer necessary
Some of the templates don't work on the latest func cli when debugging locally. Adding a 'Verified' setting for just the ones that work and an 'All' setting for those adventurous users
The main benefits:
1. We get the full list of templates supported in the portal
1. We can prompt the user for input parameters
1. We reduce reliance on the func cli
I also refactored uiUtil into an interface so that I could more easily create unit tests
1. Add 'right click on folder' entry point
1. Add context-specific wording for each entry point
1. Make folder selection consistent across all commands
1. Update gifs and feature list to include zip deploy
1. Rename 'Create Function App' to 'Create New Project' to differentiate it from creating the Azure Resource
1. Update telemetry note in README to include privacy notice and be more generic
- Move repeated code (like getIconPath) into NodeBase
- Implement showNodePicker so that commands work from the command pallete
- Move start/stop/restart logic into command files and show function app state in explorer instead of output window
Eric Jizba
REDMOND\jiewan
Sheng Chen
Chris Dias
Chris Dias