search

Azure / azure-functions-dotnet-worker

Azure Functions out-of-process .NET language worker
MIT License
425 stars 182 forks source link

Engineering: Folder restructuring #1733

Open jviau opened 1 year ago

jviau commented 1 year ago

Part of #1655

In preparation for further engineering improvements, we will restructure this repository to follow the format demonstrated in https://github.com/jviau/dotnet-worker-layout

|- doc                  // doc: contains all doc files
|- eng                  // eng: contains all our engineering related items: common targets, ci templates, signing key
   |- ci                // eng/ci: CI build files and templates.
   |- targets           // eng/targets: common msbuild .props and .targets and their supporting files.
|- misc                 // misc: this is a special csproj which collects files, leveraging globbing, to show in Visual Studio, without needing to add one by one to sln.
|- out                  // out: all project output goes here
   |- bin               // out/bin: final output
   |- obj               // out/obj: intermediate output
   |- pkg               // out/pkg: all packages (nuget or otherwise) go here
|- protos               // protos: proto subdirectory *NOTE*: we should consider consuming these as nuget packages.
|- samples              // samples: all sample projects.
|- src                  // src: all source files go here
   |- Extensions        // src/Extensions: All worker extensions (including ApplicationInsights)
   |- Host              // src/Host: Functions custom dotnet host projects
   |- Shared            // src/Shared: "SharedReference" projects, giving us a way to directly share code without using InternalsVisibleTo
   |- Worker            // src/Worker: All the projects that make up our 'framework'
      |- Sdk            // src/Worker/Sdk: All the SDK projects
      |  |- Sdk         // src/Worker/Sdk/Sdk: Microsoft.Azure.Functions.Worker.Sdk
      |  |- Analyzers   // src/Worker/Sdk/Analyzers: Microsoft.Azure.Functions.Worker.Sdk.Analyzers
      |  |- Generators  // src/Worker/Sdk/Generators: Microsoft.Azure.Functions.Worker.Sdk.Generators
      |- Worker         // src/Worker/Worker: Microsoft.Azure.Functions.Worker
      |- Core           // src/Worker/Core: Microsoft.Azure.Functions.Worker.Core
      |- Grpc           // src/Worker/Grpc: Microsoft.Azure.Functions.Worker.Grpc
|- test                 // test: all test code here. Mirrors src structure.

To simplify the rest of the engineering work, we will perform this in two phases:

  1. Restructure everything as above, except the SDK projects will be in src/Sdk.
  2. Move SDK projects to src/Worker/Sdk after we are ready to combine them into a single release unit.
fabiocav commented 1 year ago

For the output, we should consider what @brettsam pointed out is coming with .NET 8: https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-8#simplified-output-paths

For docs and samples, we would need to make sure we update all doc snippet and analyzer doc references.

fabiocav commented 1 year ago

Should also consider merging the SDK project functionality into Worker.Core

jviau commented 1 year ago

Should also consider merging the SDK project functionality into Worker.Core

Yes, I will have another issue for that. Depending how our restore customization pans out, we may even need to switch to a proper SDK (and referenced via Sdk="" in the csproj). The major difference is SDK packages are restored as part of evaluation, so they have an opportunity to influence restore target