Adding ability to select the .NET language on create #2667
Conversation
This will allow the creation of F# projects from the func init command
|
I've done some local testing of this, using the new templates, from the above mentioned pack, and it was able to create both C# and F# across dotnet and isolated. |
| @@ -41,7 +41,7 @@ public static class WorkerRuntimeLanguageHelper | |||
| private static readonly IDictionary<WorkerRuntime, string> workerToDefaultLanguageMap = new Dictionary<WorkerRuntime, string> | |||
| { | |||
| { WorkerRuntime.dotnet, Constants.Languages.CSharp }, | |||
| { WorkerRuntime.dotnetIsolated, Constants.Languages.CSharp }, | |||
| { WorkerRuntime.dotnetIsolated, Constants.Languages.CSharpIsolated }, | |||
There was a problem hiding this comment.
Yeah, figured that the default of C# makes the most sense
|
@fabiocav Adding it to the next sprint to see if we can have someone review this. It's only going into v4. I think @aaronpowell can help create a PR to back port it to v3 as well if this is approved. |
|
Apologies for the delay here. Reassigning this for review. @aaronpowell would it be possible to update this PR against the latest code? Thanks! |
|
@fabiocav done |
| @@ -25,7 +25,7 @@ public static class WorkerRuntimeLanguageHelper | |||
| private static readonly IDictionary<WorkerRuntime, IEnumerable<string>> availableWorkersRuntime = new Dictionary<WorkerRuntime, IEnumerable<string>> | |||
| { | |||
| { WorkerRuntime.dotnet, new [] { "c#", "csharp", "f#", "fsharp" } }, | |||
| { WorkerRuntime.dotnetIsolated, new [] { "dotnet-isolated" } }, | |||
| { WorkerRuntime.dotnetIsolated, new [] { "dotnet-isolated", "c#-isolated", "csharp-isolated", "f#-isolated", "fsharp-isolated" } }, | |||
There was a problem hiding this comment.
Do we still need dotnet-isolated in the array containing c#-isolated and csharp-isolated here?
There was a problem hiding this comment.
I'll have to have a second look at it, but I think the reason I kept dotnet-isolated in there was for backwards compatibility, as prior to this change that's how things were identified.
There was a problem hiding this comment.
I've had a bit of a poke around and I don't think it can be removed with a lot of other cascading changes.
Removing dotnet-isolated will cause existing projects to fail to launch using func start as it's unable to detect the worker type. I also tested changing the worker type in local.settings.json to c#-isolated but that then errors within the WebJobs dependency as it couldn't find the functions language c#-isolated, so there'd be a downstream impact.
Additionally, all templates would need to be updated to either say c#-isolated or f#-isolated in them before the change would usable.
Ultimately, the additional worker types are probably not doing anything of value at present, they are more future proofing 😅
| @@ -55,7 +55,7 @@ public static class WorkerRuntimeLanguageHelper | |||
| { Constants.Languages.TypeScript, new [] { "ts" } }, | |||
| { Constants.Languages.Python, new [] { "py" } }, | |||
| { Constants.Languages.Powershell, new [] { "pwsh" } }, | |||
| { Constants.Languages.CSharp, new [] { "csharp", "dotnet", "dotnet-isolated", "dotnetIsolated" } }, | |||
| { Constants.Languages.CSharpIsolated, new [] { "csharp", "dotnet", "dotnet-isolated", "dotnetIsolated" } }, | |||
There was a problem hiding this comment.
I believe there should be separate entries here: one with { Constants.Languages.CSharp, new [] { "csharp", "dotnet" } } and another with { Constants.Languages.CSharpIsolated, new [] { "dotnet-isolated", "dotnetIsolated" } }
There was a problem hiding this comment.
Yes that's probably true, otherwise it won't detect in-proc properly
There was a problem hiding this comment.
Done but I've had to move csharp out of the CSharpIsolated constant, otherwise it'll explode later on in WorkerRuntimeStringToLanguage, but I'm not quite sure how they all hang together to know if that's a problem (hasn't seem to be in my testing)
There was a problem hiding this comment.
@aaronpowell this PR seems mostly correct, but there are a few minor issues that need to be addressed, which I have added in the comments.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Yay!!!! |
When adding the F# templates for dotnet-isolated (see: Azure/azure-functions-templates#1074) I dug around to figure out just how the tools worked to create new projects.
This led me to figure out how the dotnet setup was done and that adding a language selector into the
func initpipeline wouldn't be that hard. So now we have the ability to select which .NET language we want to use for both in-proc and isolated models.As a result, F# projects can be managed using the
funcCLI rather than having to go via thedotnetcli.