text:
[soci] Fix dependencies in, intern, out

Fixes #34168.
Major revision of dependency control.
The "empty" backend is now optional.
i.e. neither core nor default features include any backend. (sqlite3 might be useful. empty isn't.)
The odbc backend now has a unixodbc dependency when not on windows.
Adds a test-port that actually links to some backends.
Tested in x64-linux with (preview of) vcpkg test-features soci.
CC @baziorek @JonLiu1993

@dg0yt I've checked with provided commands (https://stackoverflow.com/questions/77140854/how-to-install-soci-db-library-with-vcpkg-on-linux) inside docker container and it is working. APPROVE:)

@dg0yt, Thanks for your PR, when I tested the usage I get this error:
1> CMake generation started for configuration: 'x64-Debug'.
1> Command line: "C:\WINDOWS\system32\cmd.exe" /c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Visual Studio 17 2022" -A x64  -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="C:\Users\v-zhli17\source\repos\usageTest\out\install\x64-Debug" -DCMAKE_TOOLCHAIN_FILE=F:/Feature-test/soci/vcpkg/scripts/buildsystems/vcpkg.cmake "C:\Users\v-zhli17\source\repos\usageTest" 2>&1"
1> Working directory: C:\Users\v-zhli17\source\repos\usageTest\out\build\x64-Debug
1> [CMake] -- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.19045.
1> [CMake] -- The C compiler identification is MSVC 19.36.32538.0
1> [CMake] -- The CXX compiler identification is MSVC 19.36.32538.0
1> [CMake] -- Detecting C compiler ABI info
1> [CMake] -- Detecting C compiler ABI info - done
1> [CMake] -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.36.32532/bin/Hostx64/x64/cl.exe - skipped
1> [CMake] -- Detecting C compile features
1> [CMake] -- Detecting C compile features - done
1> [CMake] -- Detecting CXX compiler ABI info
1> [CMake] -- Detecting CXX compiler ABI info - done
1> [CMake] -- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.36.32532/bin/Hostx64/x64/cl.exe - skipped
1> [CMake] -- Detecting CXX compile features
1> [CMake] -- Detecting CXX compile features - done
1> [CMake] -- Found ZLIB: optimized;F:/Feature-test/soci/vcpkg/installed/x64-windows/lib/zlib.lib;debug;F:/Feature-test/soci/vcpkg/installed/x64-windows/debug/lib/zlibd.lib (found version "1.3.0")
1> [CMake] -- Found OpenSSL: optimized;F:/Feature-test/soci/vcpkg/installed/x64-windows/lib/libcrypto.lib;debug;F:/Feature-test/soci/vcpkg/installed/x64-windows/debug/lib/libcrypto.lib (found version "3.1.3")
1> [CMake] -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
1> [CMake] -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
1> [CMake] -- Looking for pthread_create in pthreads
1> [CMake] -- Looking for pthread_create in pthreads - not found
1> [CMake] -- Looking for pthread_create in pthread
1> [CMake] -- Looking for pthread_create in pthread - not found
1> [CMake] -- Found Threads: TRUE
1> [CMake] -- Configuring done (10.3s)
1> [CMake] CMake Error at usageTest/CMakeLists.txt:9 (target_link_libraries):
1> [CMake]   Target "test" links to:
1> [CMake]
1> [CMake]     SOCI::soci_core_static
1> [CMake]
1> [CMake]   but the target was not found.  Possible reasons include:
1> [CMake]
1> [CMake]     * There is a typo in the target name.
1> [CMake]     * A find_package call is missing for an IMPORTED target.
1> [CMake]     * An ALIAS target is missing.
1> [CMake]
1> [CMake]
1> [CMake]
1> [CMake] -- Generating done (0.1s)
1> [CMake] CMake Generate step failed.  Build files cannot be regenerated correctly.
1> 'C:\WINDOWS\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Visual Studio 17 2022" -A x64  -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="C:\Users\v-zhli17\source\repos\usageTest\out\install\x64-Debug" -DCMAKE_TOOLCHAIN_FILE=F:/Feature-test/soci/vcpkg/scripts/buildsystems/vcpkg.cmake "C:\Users\v-zhli17\source\repos\usageTest" 2>&1"' execution failed with error: ''C:\WINDOWS\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Visual Studio 17 2022" -A x64  -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="C:\Users\v-zhli17\source\repos\usageTest\out\install\x64-Debug" -DCMAKE_TOOLCHAIN_FILE=F:/Feature-test/soci/vcpkg/scripts/buildsystems/vcpkg.cmake "C:\Users\v-zhli17\source\repos\usageTest" 2>&1"' returned with exit code: 1'.

Please take a look.

All features are tested successfully in the following triplet:

x86-windows
x64-windows
x64-windows-static

Tested usage successfully by soci[*]:x64-windows-static:
soci provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(SOCI CONFIG REQUIRED)
  # note: 2 additional targets are not displayed.
  target_link_libraries(main PRIVATE SOCI::soci_core_static SOCI::soci_odbc_static SOCI::soci_empty_static SOCI::soci_mysql_static)

PR tested by user @baziorek https://github.com/microsoft/vcpkg/issues/34168#issuecomment-1752147650

It is tested by a test port...

Amazing work as usual, thanks @dg0yt!

Thanks for fixing its!
Author of corrections has priority (if he wants) to answer the question and earn some reputation:
https://stackoverflow.com/questions/77140854/how-to-install-soci-db-library-with-vcpkg-on-linux
if @dg0yt does not want - I'll answer the question:).

@baziorek I'm not active on SO.

@baziorek I'm not active on SO.

OK, I'll reply on SO.

@dg0yt Something got wrong after my approve, because when I checked that time - everything was working, but when I check after merging into master (current top commit: 51475feaccb720ab40e5a0e3f8da70a4510defc0):  There are strange suggestions made by vcpkg in newest version. When I use commands (inside docker container Ubuntu22:04):
./vcpkg/vcpkg install 'soci[sqlite3]'

the output is:
soci provides CMake targets:

    find_package(soci CONFIG REQUIRED)
    target_link_libraries(main PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_core>,SOCI::soci_core,SOCI::soci_core_static>)

    # Linking specific backends (enabled: sqlite3)
    target_link_libraries(main PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_<BACKEND>,SOCI::soci_<BACKEND>,SOCI::soci_<BACKEND>_static>)

when I use those commands in CMake:
./vcpkg/vcpkg integrate install
cmake . -DCMAKE_TOOLCHAIN_FILE=/home/vcpkg/scripts/buildsystems/vcpkg.cmake && make

I see:
Soci found:  and
-- Configuring done
-- Generating done
-- Build files have been written to: /home
[ 50%] Building CXX object CMakeFiles/Learning_VCPKG.dir/main.cpp.o
[100%] Linking CXX executable Learning_VCPKG
/usr/bin/ld: CMakeFiles/Learning_VCPKG.dir/main.cpp.o: warning: relocation against `_ZN4soci7sqlite3E' in read-only section `.text'
/usr/bin/ld: CMakeFiles/Learning_VCPKG.dir/main.cpp.o: in function `main':
main.cpp:(.text+0x61): undefined reference to `soci::sqlite3'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/Learning_VCPKG.dir/build.make:99: Learning_VCPKG] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/Learning_VCPKG.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

CMakeLists.txt (with suggestion used):
cmake_minimum_required(VERSION 3.16)
project(Learning_VCPKG LANGUAGES CXX)

find_package(SOCI CONFIG REQUIRED)

if (SOCI_FOUND)
    message("Soci found: ${SOCI_INCLUDE_DIRS} and ${SOCI_LIBRARY_DIRS}")
endif ()

add_executable(${PROJECT_NAME} main.cpp)

# find_package(soci CONFIG REQUIRED)
target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_core>,SOCI::soci_core,SOCI::soci_core_static>)

and main.cpp one more time:
#include <exception>
#include <iostream>
#include <soci/soci.h>
#include <soci/sqlite3/soci-sqlite3.h>
#include <string>

using namespace soci;
using namespace std;

int main()
{
    try {
        soci::session sql(sqlite3, "test.db");

        sql << "CREATE TABLE IF NOT EXISTS Employees("
               "ID     INT PRIMARY KEY NOT NULL,"
               "name   TEXT            NOT NULL,"
               "Age   INT             NOT NULL,"
               "Address  TEXT,"
               "Salary REAL);";
        sql << "INSERT INTO Employees (ID, name, Age, Address, Salary) VALUES (1, 'Tadeusz', 24, 'Krakow', 2000.01 ); ";
        sql << "INSERT INTO Employees (ID, name, Age, Address, Salary) VALUES (2, 'Symeon', 25, 'Texas', 15000.00 ); ";
        sql << "INSERT INTO Employees (ID, name, Age, Address, Salary) VALUES (3, 'Rodion', 23, 'Norway', 20000.00 );";

        int count;
        sql << "select count(*) from Employees", into(count);

        cout << "We have " << count << " entries in the Employees table.\n";
    } catch (exception const& e) {
        cerr << "Error: " << e.what() << '\n';
    }
}

target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_core>,SOCI::soci_core,SOCI::soci_core_static>)

You are linking core only. In a static build, you have to link the backend you want.

target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_core>,SOCI::soci_core,SOCI::soci_core_static>)

You are linking core only. ~In a static build~ When directly accessing a particular backend, you have to link that backend.

When I change the CMakeLists.txt:
cmake_minimum_required(VERSION 3.16)
project(Learning_VCPKG LANGUAGES CXX)

find_package(SOCI CONFIG REQUIRED)

if (SOCI_FOUND)
    message("Soci found: ${SOCI_INCLUDE_DIRS} and ${SOCI_LIBRARY_DIRS}")
endif ()

add_executable(${PROJECT_NAME} main.cpp)

target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_core>,SOCI::soci_core,SOCI::soci_core_static>)
target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_<BACKEND>,SOCI::soci_<BACKEND>,SOCI::soci_<BACKEND>_static>)

I see compilation problem:
cmake . -DCMAKE_TOOLCHAIN_FILE=/home/vcpkg/scripts/buildsystems/vcpkg.cmake && make
Soci found:  and
-- Configuring done
CMake Error at CMakeLists.txt:14 (target_link_libraries):
  Error evaluating generator expression:

    $<TARGET_EXISTS:SOCI::soci_<BACKEND>

  $<TARGET_EXISTS:tgt> expression requires a non-empty valid target name.

CMake Error at CMakeLists.txt:14 (target_link_libraries):
  Error evaluating generator expression:

    $<TARGET_EXISTS:SOCI::soci_<BACKEND>

  $<TARGET_EXISTS:tgt> expression requires a non-empty valid target name.

CMake Error at CMakeLists.txt:14 (target_link_libraries):
  Error evaluating generator expression:

    $<TARGET_EXISTS:SOCI::soci_<BACKEND>

  $<TARGET_EXISTS:tgt> expression requires a non-empty valid target name.

-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

So I tried to replace <BACKEND> with sqlite3, so CMake is now:
cmake_minimum_required(VERSION 3.16)
project(Learning_VCPKG LANGUAGES CXX)

find_package(SOCI CONFIG REQUIRED)

if (SOCI_FOUND)
    message("Soci found: ${SOCI_INCLUDE_DIRS} and ${SOCI_LIBRARY_DIRS}")
endif ()

add_executable(${PROJECT_NAME} main.cpp)

target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_core>,SOCI::soci_core,SOCI::soci_core_static>)
target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_sqlite3,SOCI::soci_sqlite3,SOCI::soci_sqlite3_static>)

And compilation also failures:
cmake . -DCMAKE_TOOLCHAIN_FILE=/home/vcpkg/scripts/buildsystems/vcpkg.cmake && make
Soci found:  and
-- Configuring done
CMake Error at CMakeLists.txt:13 (target_link_libraries):
  Error evaluating generator expression:

    $<TARGET_EXISTS:SOCI::soci_sqlite3,SOCI::soci_sqlite3,SOCI::soci_sqlite3_static>

  $<TARGET_EXISTS> expression requires exactly one parameter.

CMake Error at CMakeLists.txt:13 (target_link_libraries):
  Error evaluating generator expression:

    $<TARGET_EXISTS:SOCI::soci_sqlite3,SOCI::soci_sqlite3,SOCI::soci_sqlite3_static>

  $<TARGET_EXISTS> expression requires exactly one parameter.

CMake Error at CMakeLists.txt:13 (target_link_libraries):
  Error evaluating generator expression:

    $<TARGET_EXISTS:SOCI::soci_sqlite3,SOCI::soci_sqlite3,SOCI::soci_sqlite3_static>

  $<TARGET_EXISTS> expression requires exactly one parameter.

-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

-target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_sqlite3,SOCI::soci_sqlite3,SOCI::soci_sqlite3_static>)
+target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_sqlite3>,SOCI::soci_sqlite3,SOCI::soci_sqlite3_static>)

-target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_sqlite3,SOCI::soci_sqlite3,SOCI::soci_sqlite3_static>)
+target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_sqlite3>,SOCI::soci_sqlite3,SOCI::soci_sqlite3_static>)

Thanks, when I correct as You suggested CMakeLists.txt:
cmake_minimum_required(VERSION 3.16)
project(Learning_VCPKG LANGUAGES CXX)

find_package(SOCI CONFIG REQUIRED)

if (SOCI_FOUND)
    message("Soci found: ${SOCI_INCLUDE_DIRS} and ${SOCI_LIBRARY_DIRS}")
endif ()

add_executable(${PROJECT_NAME} main.cpp)

target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_core>,SOCI::soci_core,SOCI::soci_core_static>)
target_link_libraries(${PROJECT_NAME} PRIVATE $<IF:$<TARGET_EXISTS:SOCI::soci_sqlite3>,SOCI::soci_sqlite3,SOCI::soci_sqlite3_static>)

everything works:
cmake . -DCMAKE_TOOLCHAIN_FILE=/home/vcpkg/scripts/buildsystems/vcpkg.cmake && make
Soci found:  and
-- Configuring done
-- Generating done
-- Build files have been written to: /home
Consolidate compiler generated dependencies of target Learning_VCPKG
[ 50%] Linking CXX executable Learning_VCPKG
[100%] Built target Learning_VCPKG
root@agh-legion:/home# cmake . -DCMAKE_TOOLCHAIN_FILE=/home/vcpkg/scripts/buildsystems/vcpkg.cmake && make && ./Learning_VCPKG
Soci found:  and
-- Configuring done
-- Generating done
-- Build files have been written to: /home
Consolidate compiler generated dependencies of target Learning_VCPKG
[100%] Built target Learning_VCPKG
We have 3 entries in the Employees table.

But IMO suggestion from VCPKG needs modification, when I compare diff between suggestion and working version:

First occurrence of text <BACKEND should be replaced with sqlite3, but another two occurrences to replace are: <BACKEND> (extra >). IMO it should be the same text to replace in all three places.
Of course it would be much easier if suggestion will be just copy&paste without replacing <BACKEND>  keyword, but maybe it is impossible:)

I see, we lost a >. I want to avoid <...> for BACKEND, but I couldn't come up with an alternative fast enough. I avoided adding usage in the beginning because it wouldn't be trivial, but the uninformed heuristics is helpful either.


text:
[Azure Storage] Update to November Release

Update vcpkg ports for Azure SDK release. This release may contain multiple ports.

Adding azure-storage-common to release
cc: @microzchang

Adding azure-storage-blobs to release
cc: @microzchang

Adding azure-storage-files-datalake to release
cc: @microzchang

Adding azure-storage-files-shares to release
cc: @microzchang

Adding azure-storage-queues to release
cc: @microzchang

source: gharchive/pull-request

repo: microsoft/vcpkg

license: MIT

license_type: permissive

license_source: github-api


text:
[libdatachannel] Update, cleanup

Complements https://github.com/microsoft/vcpkg/pull/40335

All features are tested successfully in the following triplet:

x86-windows
x64-windows
x64-windows-static

Tested usage successfully by libdatachannel[*]:x64-windows:
libdatachannel provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(LibDataChannel CONFIG REQUIRED)
  target_link_libraries(main PRIVATE LibDataChannel::LibDataChannelStatic)


text:
[Suggestion] Add visual indicator that properties are required

Gathered from internal feedback.
On intenseness of property names, there should be some visual indication of required vs. optional.

https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1069204

Example from TypeScript:

source: gharchive/issue

authors: StephenWeatherford neilpeterson

repo: microsoft/vscode-azurearmtools


text:
Error while deploying the azure function

Repro steps:

Action: azureFunctions.deploy
Error type: Error
Error Message: Entry not found in cache.
Version: 0.17.0
OS: darwin
Product: Visual Studio Code
Product Version: 1.33.1
Language: en

Call Stack
a.module.exports.a.createError extension.js:1:49013
b.<anonymous> extension.js:229:176642
extension.js:229:171257
extension.js:229:43312
extension.js:229:41305
extension.js:229:40927
i.module.exports.i.find extension.js:229:75420
module.exports.find.init.then extension.js:229:22917

Thanks for filing - as a workaround you could try signing out and signing back in to your Azure Account using the command palette.
Unfortunately there's not much we can do in this extension, but this is being tracked upstream here: https://github.com/microsoft/vscode-azure-account/issues/53

repo: microsoft/vscode-azurefunctions


text:
True support for multiple function apps in a monorepo

I have a "real" monorepo with multiple workspaces under a single root repository (not a multi-root workspace). This extension doesn't support multiple function apps in a true, single-root monorepo. I think it should.
Current impact is that my team can't really develop and deploy multiple function apps in parallel in a single development container. Now I need to set up CI for our function apps, which is fine, but it's also work I was hoping I wouldn't have to do right now. Deploying from VS Code using this extension is a nice fit with rapid prototyping, and it was a surprise to discover you don't support multiple workspaces in a repository.

What is your desired behavior in this situation? Just prompt to select the function app each time?

Maybe another level of the tree? Honestly I'm not sure. I suppose my expectation as I added a couple more function apps was that I'd be able to, say, right-click deploy to each one in the tree.
FYI my use case was webhooks and queue workers; it makes sense for these to be separate function apps in a shared repository, since they share most dependencies (e.g. TypeScript configs and types) but have different runtime requirements (e.g. webhooks need to stay warm whereas queue workers are fine to start cold).
Now that I've set up GitHub Actions to deploy each of my Azure function apps, I'm no longer in need of this extension; it was a great stopgap solution, I just wanted to provide the feedback on what would have kept it useful for us. Thanks!

:slightly_frowning_face: In the last 60 days, this issue has received less than 5 community upvotes and we closed it. Still a big Thank You to you for taking the time to create it! To learn more about how we handle issues, please see our documentation.
Happy Coding!

That's alright, we're switching to Google Cloud Run which offers far better means for running function apps. Still a big Thank You for taking the time to consider making Azure Functions worth using, better luck next time 👋

@AzCode-Bot the issue has 5 upvotes now, please reopen; thanks

I came across same problem. I have been trying several hacks to keep mono git repo for multiple Azure function project. It would be good if it supports out of box.

:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

Love that this got to the backlog! I am wanting a monorepo as well with durable functions.

Hey, just want to politely bump this thread. I too have recently moved our team's codebase under a mono-repo, while it has its obvious simplifications and joys, it comes with its speedbumps and learning experiences.
The first obvious problem is the deployment of an azure function via the vs code extension relies on a traditional folder structure, therefore, has no greater awareness of any broader local packages outside of the scope of the function app folder. Given most mono-repo environments utilize workspaces, which is a feature in most if not all modern package managers, I do imagine a solution could exist for this that is abstract enough to not require a really niche solution.
I could be missing something here so please let me know if I'm off the ball, but just some controls for multiple function apps, and the ability to define install & build commands would go a long way in helping this broader problem. 😄

Hey Guys is there a way to make a function app actually work in a monorepo? if so i could use some hints. We have turbo-repo with PNPM to run our monorepo.

I am not sure if the desired behavior is still clear. No matter what monorepo tools you are using the basis for all of them nowadays seems to be npm workspaces and then there are some features added to cache, bump versions etc. But all based on npm workspaces.
So lets get the requirements straight. I can start explaining the setup that I am for, you guys con chip in yours and we see where we can align.
My primary issue is that I want to have a set of function apps that together make my software. In that I want to have shared code and shared libraries.
My proposals:

in npm workspaces I can actually install dependencies on the root level of my repo and npm knows that the packages in the root node_modules can be used in the workspaces. If I want to deploy that I would expect that the azure function will not deploy those dependencies. Because each function app has its own node_modules. I guess thats one thing that should be working. Solution: the functions app knows that its within a monorepo (property in local-settings.json or such) and what the repo root is. It will copy the node_modules from there for deployment. Downside: maybe too many modules will be uploaded that the function does not actually need.
also I want to habe some self written shared code like project specific libraries, domain models, etc. So there should be a way to have workspaces that are not an azure function app. but it should be possible to use them inside the function app. That would work in npm workspaces. Again here the issue so far ist only the deployment of the function app.

Note: I usually deploy using the azure cli.
Workarounds (I will try this now and let you know if it works out):

put your shared code in a packages folder, keep the apps separate.
publish your shared code to a tar (uning npm pack) instead of to npm
install that tar to your functions dependencies
use lerna or turborepo or similar to create a dependeny on build that rebuilds the tar files first

As promised a WORKAROUND to fulfill shared code and multiple azure function apps within one repo, for javascript and typescript:
I am on a Mac, maybe someone could help with a Windows solution of the build script. I can also create one with node. But I think on Windows it should work with Git-Bash where you can run bash-scripts as well.
following folder structure:
my-project/
  apps/
    function-app-a/
      function-a-1/
      function-a-2/
      ...
      package.json
      ...
    function-app-b/
      function-b-1/
      function-b-2/
      ...
      package.json
      ...
  lib/
    out/
    core/
    domain-model/
    whatever-you-need/
    package.json
  build.sh

Please put you eye on:

the lib/out
the package.json files in each function app
the build.sh

The build.sh gets following content:
#!/usr/bin/env bash
# the output of the tgz file
OUT_DIR=out
# the name of your lib (package,json > name)
LIB_NAME=my-project-lib
# the path of your shared code (relative to the root path)
LIB_DIR=lib
# the directory of this file
BASE_DIR=$(dirname "$0")
# the origin path of the script execution (your function app)
ORIGIN_DIR=$(realpath "$PWD")
# the root directory of your project
ROOT_DIR=$(realpath "$PWD/$BASE_DIR")

# go to root and build dependencies as tgz
cd "$ROOT_DIR" || exit
cd "$LIB_DIR" || exit

if [ -d "$OUT_DIR" ]; then rm -Rf $OUT_DIR/*.tgz; fi

mkdir $OUT_DIR;

npm run build || exit
npm pack --pack-destination $OUT_DIR "$@" || exit

cd "$ORIGIN_DIR" || exit
npm i "$LIB_NAME"

Now configure:

LIB_NAME = whatever you put in the name property of lib/package.json
optional:
OUT_DIR = lib/out in this example. you can change the folder name if you want to and the set the same dir-name here
LIB_DIR = lib or whatever you want to call that folder

make sure build.sh is executable. on unix this would be:
chmod +x build.sh

run the build file. on unix:
./build.sh

check that it created a tgz-file in lib/out
go to each of your function apps and install the tgz like so:
npm i ../../lib/my-project-lib.tgz

why tgz? because you can install npm packages in your lib and they will also be within you function app nodemodules whenever you build.
Last step:
in your function apps (each one) modify your build script in the package.json.
for typescript:
"scripts": {
    "build": "../../build.sh && tsc",

for jsvascript:
"scripts": {
    "build": "../../build.sh",
    "prestart": "npm run build",

I believe the approach to create a local library as a dependency in each function app could also be adjusted to other languages like Java and C# but it will be a while until I would get around to that. Maybe we can create a repo to store templates for this workaround.

After browsing the web for quite a while in hopes to get a good solution for that, I've ended up creating my own NX workspace plugin for that. You're welcome to use it. :)
https://www.npmjs.com/package/@nxazure/func

Hey Guys is there a way to make a function app actually work in a monorepo? if so I could use some hints. We have turbo-repo with PNPM to run our monorepo.

Idk about PNPM specifically, but for yarn, I had success getting deployments to work via nohoist in the package.json of the function app:
"workspaces": {
    "nohoist": [
        "**"
    ]
}

While nohoist is useful, it does come with drawbacks. The most obvious one is modules will now be duplicated in multiple locations, denying the benefit of hoisting. This solution becomes more problematic when you want to have multiple function apps, so that double up of packages could quickly cascade out, if you only have the one, this might work for your needs, its not optimal, but it is functional (with yarn atleast).
This thread might help around hoisting behavior and pnpm

I have found a workaround to use as a temporary solution (Note the below is quite bespoke to my environment so a pure copy and paste may not work)
path: scipts/azure-deploy.js
// eslint-disable-next-line @typescript-eslint/no-var-requires
const fs = require('fs');

// eslint-disable-next-line @typescript-eslint/no-var-requires
const path = require('path');

const packageName = process.argv[2];  // Get the package name from command-line arguments

// Define the paths to the JSON files
const settingsPath = path.join(__dirname, '..', '.vscode', 'settings.json');
const launchPath = path.join(__dirname, '..', '.vscode', 'launch.json');
const tasksPath = path.join(__dirname, '..', '.vscode', 'tasks.json');

// Read the JSON files
const settings = JSON.parse(fs.readFileSync(settingsPath, 'utf8'));
const launch = JSON.parse(fs.readFileSync(launchPath, 'utf8'));
const tasks = JSON.parse(fs.readFileSync(tasksPath, 'utf8'));

// Modify the JSON data
settings["azureFunctions.projectSubpath"] = path.join('functions', packageName);
settings["azureFunctions.deploySubpath"] = path.join('functions', packageName);

// Modify the tasks.json to reflect the correct package
tasks.tasks.forEach((task) => {
    if (task.options && task.options.cwd) {
        task.options.cwd = "${workspaceFolder}/functions/" + packageName;
    }
});

// Save the JSON data back to the files
fs.writeFileSync(settingsPath, JSON.stringify(settings, null, 4), 'utf8');
fs.writeFileSync(launchPath, JSON.stringify(launch, null, 4), 'utf8');
fs.writeFileSync(tasksPath, JSON.stringify(tasks, null, 4), 'utf8');

// Ready to deploy with the updated paths

Basically just rewriting the paths do where its being deployed from, and making sure I call it properly prior to deploying. Its not ideal, but it allows multiple apps to be deployable from vscode for now.
example in package.json
{
    "scripts": {
        "predeploy": "node ./scripts/function-deploy.js",
    }
}

yarn predeploy subscriptions updates all the hardcoded paths to be /functions/subscriptions
yarn predeploy api updates all the hardcoded paths to be /functions/api

Can any one help me on How do we build and deploy multiple go-lang azure functions under single repo code base?

Can we have an update or a timeline for when this plan to be available, at least as a preview maybe?

I am also looking to setup a monorepo with a react ui and azure functions. @ejizba would you recommend any one of these workarounds in while this issue is open? thank you

Any updates?

4 years later still waiting, do we really have to abandon azure functions just because we use a mono repo?

4 years later still waiting, do we really have to abandon azure functions just because we use a mono repo?

Pretty much i guess. I migrated all our functions to a new nestjs app. Can run that one anywhere i want. Cheaper too

Ok after some research we have learned this isnt just multiple azure functions, even if you have 1 azure function in a monorepo (turborepo in our case) it will just break deployment. The files are uploaded but none of the endpoints show/ are registered)
We can probably work around this with a deployment pipeline but it is more work for us and this was supposed to be a quick and easy implementation!

@DrPye if you're open to using NX for managing your monorepo, I've created a plugin that allows you to add azure function apps to your monorepo.
It supports using libs, it supports running functions in parallel and it supports publishing each function independently.
Have a look, maybe it will suit your needs.
https://www.npmjs.com/package/@nxazure/func

@AlexPshul I would love to but we've just finished migrating to turbo and I think id lose my job if I do another refactor ha!

hello, after much suffering, wanted to post something because my team, and I got a workaround working today and maybe it might help others if you're looking for a hacky fix.
CONTEXT
We recently shifted to a monorepo using npm workspaces and a Azure Functions (typescript) implementation. Our "monorepo" had our backend directory nested with our azure function implementation. At the top level, we have github workflows with deploy .yml files that followed this microsoft tutorial: https://learn.microsoft.com/en-us/azure/azure-functions/functions-how-to-github-actions?tabs=windows%2Cdotnet&pivots=method-template
We realised that az functions only cared about having the dist build package being at the top level and doesn't like the directory with the az funcs in a nested directory... lol.
OUR NESTED AZ FUNC DIRECTORY
PoC-Template
├── apps
│   ├── frontend
│   ├── backend
│   │   ├── dist (from npm run build)
│   │   ├── src
│   │   ├── package.json
│   │   ├── tsconfig.json (moved this later to root level)
│   │   └── src
│   │       └── functions
│   │   ├── package.json (updated this file)
├── tsconfig.json  (moved from backend to root level here)
└── ...

OUR FIX
We pretty much copied our /dist out build package directory that contained our javascript azure functions to the root level. This meant we had to move the tsconfig.json to the top level as well (and added an "exclude" for any directories that you don't want built during the "npm run build") and add to the package.json the ""main": "dist/functions/*.js" assuming your root is in a "../src".
Some mocked code snippets:
tsconfig.json
{   "compilerOptions": {     "module": "NodeNext",     "moduleResolution": "NodeNext",     "target": "ES2022",     "outDir": "dist",     "rootDir": "apps/backend/src",     "sourceMap": true,     "strict": true,     "skipLibCheck": true   },   "exclude": [     "apps/frontend",     ...   ] }
package.json
`{
"name": "",
"version": "1.0.0",
"description": "",
"scripts": {
...
},
...
"main": "dist/functions/*.js"
}
`
.github/deploy-backend.yml
# Step to build the package in /apps/backend
- name: Build and publish package (Backend)
  shell: bash
  run: |
    echo "Building the package in /apps/backend"
    pushd 'apps/backend'
    npm install --no-audit --no-fund # Install backend-specific packages only
    npm run build # This creates the /dist folder
    popd

# Step to copy /apps/backend/dist to the root directory
- name: Copy dist folder to root
  run: |
    echo "Copying dist folder from /apps/backend to root"
    cp -R apps/backend/dist . # Copy the /dist folder from /apps/backend to the root
    ls -l dist # Verify that dist is now in the root directory

# Step to deploy Azure Functions pointing to the root-level dist folder
- name: "Deploy Azure Functions"
  uses: Azure/functions-action@v1
  id: fa
  with:
    app-name: ${{ env.FUNCTIONS_APP_NAME }}
    package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
    publish-profile: ${{ secrets.AZURE_FUNCTIONAPP_PUBLISH_PROFILE }}

hope this helps someone (or maybe myself in the future) xx

Hi all, if your using turbo repo (possibly pnpm deploy will do the same trick) I wrote a blog post for sorting this out, no extra tsconfig needed, no moving of files, just a bit of a build script for deployments. Please let me know if you feel steps are missing or need clarification!
https://pyedpiper.pyenet.co.uk/blog/serverless-function-deploy-mono

Hi all, if your using turbo repo (possibly pnpm deploy will do the same trick) I wrote a blog post for sorting this out, no extra tsconfig needed, no moving of files, just a bit of a build script for deployments. Please let me know if you feel steps are missing or need clarification!
https://pyedpiper.pyenet.co.uk/blog/serverless-function-deploy-mono

This is incredibly helpful @DrPye - would you mind sharing your tsup.config.ts? Right now I am bundling internal packages like so:
const tsupConfig = defineConfig((options) => {
    return {
        // ...
        noExternal: [/^@my-monorepo\/*/], // Bundle internal packages - results in dynamic require is not supported error
    }
})

But I am running into the esbuild issue outlined here (dynamic require not supported). Are you implementing one of the fixes in that thread or are you bundling internal packages in a different way?

@tyleralbee Im really happy it helped, that was alot of smashing my head into a wall to get it working.
Im glad your sorted your problem but to answer your question, we simply use noExternal we havent come across the issue you had. It is possible we dont have any dynamic imports currently.

authors: AlexPshul AndrewDucDanhDo AzCode-Bot DrPye EricJizbaMSFT GustavoOS aaronadamsCA ashishapy brandon-burciaga ingmaramzan joelybahh lensbart ravitejaavv sanderkooger sittingbool sudosean tyleralbee


text:
V0.9.2 causes error when deploying to function app

Downgrading to v0.9.1 solves the issue, but with version 0.9.2 my colleagues and I get the following error message deploying to a function app:
Operation 'Microsoft.Web/sites/read' failed as server encountered too many requests. Please try after '60' seconds. Tracking Id is ________

This has been fixed in v1.15.3 of Azure Functions.

authors: alexweininger mwdavids

repo: microsoft/vscode-azureresourcegroups


text:
Enable scoping selectSubscriptions command by account

Requested by the @azure team
cc: @MRayermannMSFT

Lol, @alexweininger, I highly recommend putting "@ azure" in  backtics (`), otherwise you are tagging the Azure org on GitHub. XD

Lol, @alexweininger, I highly recommend putting "@ azure" in backtics (`), otherwise you are tagging the Azure org on GitHub. XD

Oh no

authors: MRayermannMSFT alexweininger


text:
Increase timeout value for fixes tests timeout on win32

The following error are copied from  https://github.com/microsoft/vscode-cmake-tools/runs/4933169033?check_suite_focus=true
2022-01-25T07:38:39.8034093Z   1) CMake FileAPI driver tests
2022-01-25T07:38:39.8035702Z        All target for Visual Studio Community 2019 - amd64:
2022-01-25T07:38:39.8038322Z      Error: Timeout of 60000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (d:\a\vscode-cmake-tools\vscode-cmake-tools\out\test\unit-tests\driver\cmfileapi-driver.test.js)
2022-01-25T07:38:39.8040365Z   	at listOnTimeout (internal/timers.js:554:17)
2022-01-25T07:38:39.8041995Z   	at processTimers (internal/timers.js:497:7)
2022-01-25T07:38:39.8043420Z
2022-01-25T07:38:39.8044865Z   2) Kits scan test
2022-01-25T07:38:39.8058046Z        Detect system kits never throws:
2022-01-25T07:38:39.8061281Z      Error: Timeout of 120000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (d:\a\vscode-cmake-tools\vscode-cmake-tools\out\test\unit-tests\kit-scan.test.js)
2022-01-25T07:38:39.8063425Z   	at listOnTimeout (internal/timers.js:554:17)
2022-01-25T07:38:39.8065171Z   	at processTimers (internal/timers.js:497:7)

Signed-off-by: Yonggang Luo luoyonggang@gmail.com

I was hoping to have some time to look at this on my PC, but this should work for now.  Windows CI takes so much longer to complete than Linux/Mac and I think it's mostly because of Kits.

authors: bobbrow lygstate

repo: microsoft/vscode-cmake-tools


text:
add pinned cmake commands view

This change addresses item #3296
This changes adds a new view in sidebar where users can add cmake commands to pin

Nbd, but for UI changes it would be easier to review if you add a screenshot

Also, there seem to be some build failures that may be due to flaky issues with the windows test, but I requeued to try again.


text:
Copilot Bugs Out When Closed Out

VS Code Version: 1.85.1
OS Version: Windows 11
Logs:

Steps to Reproduce:
I meant to add @workspace with ctrl enter so I quickly closed out, but then the chat bugs out.

enter a prompt to GitHub Copilot Chat
While the prompt is loading, press 'X' on the top right of the prompt
The prompt box will not be able to send any messages, and the 'stop' square doesn't work.
In order to fix, open a new chat window or close and reopen vscode.

I can't repro an issue, can you share a screenshot or some more details to be sure I understand? You can check the "GitHub Copilot Chat" or "Window" output channels for errors

authors: orgenom roblourens

repo: microsoft/vscode-copilot-release


text:
23:00:09: Error: failed to connect to server [127.0.0.1:27017] on first connect [[Error: connect ENOBUFS 127.0.0.1:27017 - Local (undefined:undefined)

   Does this occur consistently?  Repro steps:   1. 2.  Action: stat Error type: MongoNetworkError Error Message: failed to connect to server [127.0.0.1:27017] on first connect [[Error: connect ENOBUFS 127.0.0.1:27017 - Local (undefined:undefined) 	at internalConnect (net.js:835:16) 	at defaultTriggerAsyncIdScope (internal/async_hooks.js:301:12) 	at net.js:926:9 	at processTicksAndRejections (internal/process/task_queues.js:75:11)] {   name: 'MongoNetworkError',   [Symbol(mongoErrorContextSymbol)]: {} }]  Version: 0.14.0 OS: win32 OS Release: 10.0.18362 Product: Visual Studio Code Product Version: 1.47.2 Language: en   Call Stack  ``` internalConnect net.js:835:16 defaultTriggerAsyncIdScope async_hooks.js:301:12 net.js:926:9net.js:926:9 processTicksAndRejections task_queues.js:75:11 Pool. mongodb/server.js:438:11 Pool.emit events.js:203:13 pool.js:561:14mongodb/pool.js:561:14 pool.js:994:11mongodb/pool.js:994:11 connect.js:31:7mongodb/connect.js:31:7 callback mongodb/connect.js:264:5 Socket. mongodb/connect.js:294:7 Object.onceWrapper events.js:291:20 Socket.emit events.js:203:13 emitErrorNT destroy.js:91:8 emitErrorAndCloseNT destroy.js:59:3 processTicksAndRejections task_queues.js:77:11 ```

Thanks for reporting @AviadC31.  Do you have a local mongo server running?

repo: microsoft/vscode-cosmosdb


text:
The wrong web page is opened when executing command "Learn more about authenticating with Azure Active Directory"

OS: Win10
Build Version: 20230927.1
Regression: Not a Regression
Repro Steps:

F1 -> Select "PostgreSQL: Learn more about authenticating with Azure Active Directory".
Check whether the corresponding web page is opened or not.

Expect:
The corresponding web page is opened.
Actual:
The wrong web page is opened.

More Info:
This issue also reproduces when clicking the button "Learn more about authenticating with Azure Active Directory".

This is expected for now. I will activate the forward link before publishing 0.20.0.

The wiki page has been activated.

Verified this bug on the latest build 20231017.2, it has been fixed.

authors: JasonYeMSFT v-ruizh


text:
Connecting to codespace docker from host machine.

Can I use kitematic to connect to docker from codespace?.  Is there a way to do that?. I am looking for this way so I can practice the cool things from docker (like MySQL etc).

I got reply from @Chuxel  on similar post, closing it.

repo: microsoft/vscode-dev-containers


text:
Failed to load the ESLint library for the document... (Windows 10, WSL)

This works fine for me in macOS. I'm having this issue in Windows:
[Info  - 8:46:29 PM] ESLint server stopped.
[Info  - 8:46:30 PM] ESLint server running in node v8.9.3
[Info  - 8:46:30 PM] ESLint server is running.
[Info  - 8:46:30 PM] Failed to load the ESLint library for the document Untitled-1
To use ESLint for single JavaScript file install eslint globally using 'npm install -g eslint'.
If you are using yarn or pnpm instead of npm set the setting `eslint.packageManager` to either `yarn` or `pnpm`
You need to reopen VS Code after installing eslint.

Repro steps:
Setup WSL and environment

Enable WSL
Install an Ubuntu version from the Windows Store
👇 in Ubuntu
Go through setup; Install Node.js and npm LTS
Modify npm prefix to use path owned by me and not root
Install eslint globally (npm -g i eslint)
Add .eslintrc file to ~/
👇 back in Windows
Install VS Code Stable
Open VS Code
👇 in VS Code

Setup VS Code

Install ESLint extension (dbaeumer.vscode-eslint)
View > Command Palette... > Terminal: Select Default Shell > WSL Bash

Final steps

Close VS Code; Open VS Code (via Windows taskbar shortcut / start menu)
File > New File
View > Command Palette... > Change Language Mode > JavaScript
View > Output
Select ESLint in output provider list
Output: See log at beginning of this post
View > Terminal
Execute the following commands:

node -v && npm -v
v10.15.0
6.4.1

npm -g prefix
/home/jesse/.npm-global

npm -g ls --depth 0
/home/jesse/.npm-global/lib
└── eslint@5.13.0

which eslint
/home/jesse/.npm-global/bin/eslint

eslint -v
v5.13.0

Do I need to do something else?

This is currently not working since the ESLint server is started on the Windows side. The issue needs to be addressed by VS Code itself and there is a corresponding item on the VS Code roadmap (see https://github.com/Microsoft/vscode/wiki/Roadmap , WSL support).
As soon as VS Code has support for it I will start adopting in ESLint.

the ESLint server is started on the Windows side

Can you elaborate this? I don't understand what you mean.

So there's nothing wrong, in theory, with the procedure I listed, and it's just an issue with VS Code not really supporting WSL yet?

What are the steps to get it working until WSL is adequately supported?

The ESLint extension runs the eslint npm module on the Windows and not on the WSL side. This is why this is failing.
There is nothing wrong in theory but it needs better support in VS Code itself to make this scenario happening.

ironic, given that Idea works better with WSL than MS product

https://code.visualstudio.com/docs/remote/wsl will fix this. I am closing this issue.

@dbaeumer So I will need to install another extension before being able to use ESLint in Windows? I'm confused.
Will you please elaborate here what steps will be needed (starting from a fresh Windows 10 installataion) to get ESLint working in VS Code through WSL?

@jsejcksn A good documentation on how to use this is here: https://code.visualstudio.com/docs/remote/wsl#_getting-started
The benefit of this approach is that not only the ESLint runs in WSL but also language support and debugging. So it is a more holistic solution then only running ESLint in WSL.
Please note that the general WSL support in VS Code is currently only available in Insider. But it will come to stable.

authors: dbaeumer jsejcksn snooopcatt

repo: microsoft/vscode-eslint


text:
v0.3.13 error darwin x64

:warning:Please attach $TMPDIR/vscode-java-installer/log.txt for more details.
version: 0.3.13
env:
JAVA_HOME: undefined
PATH:
/usr/bin
/bin
/usr/sbin
/sbin
JDKs:
/Library/Java/JavaVirtualMachines/jdk-16.jdk/Contents/Home	DefaultLocation

log:
[09:10:29] arch:x64
[09:10:49] Download Visual Studio Code ... [Completed]
[09:10:49] Install Visual Studio Code
[09:10:54] Install Visual Studio Code ... [Completed]
[09:10:54] Configure Java Settings
[09:10:54] Error occurred
[09:10:54] Error: Can not add index to parent of type string

JDK 16 is auto detected. You can install Java Extension Pack manually, and it's all set.

[09:10:54] Error: Can not add index to parent of type string

It's possible that your user settings file is corrupted. Can you attach content of your settings.json file?

authors: Eskibear mfkoide

repo: microsoft/vscode-java-installer


text:
unable to download required widget in VSCode

Environment data

VS Code version: XXX
Jupyter Extension version (available under the Extensions sidebar): XXX
Python Extension version (available under the Extensions sidebar): XXX
OS (Windows | Mac | Linux distro) and version: XXX
Python and/or Anaconda version: XXX
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): XXX
Jupyter server running: Local | Remote | N/A

Expected behaviour
XXX
Actual behaviour
XXX
Steps to reproduce:
[NOTE: Self-contained, minimal reproducing code samples are extremely helpful and will expedite addressing your issue]

XXX

Logs

Output for Jupyter in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Jupyter)

XXX

Thanks for filling this issue
However without any information it’s not possible to help you
Please could you fill in the required info and include steps to repro the issue

thanks for replying! the problem was eventually fixed - it had to do with
an antivirus software on my computer. it was my first time reporting an
issue and didn't realize that I needed to write more information. will do
next time!
-Gin
On Thu, Aug 24, 2023 at 7:08 PM Don Jayamanne @.***>
wrote:

Thanks for filling this issue
However without any information it’s not possible to help you
Please could you fill in the required info and include steps to repro the
issue
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-jupyter/issues/14176#issuecomment-1691475123,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AU5BJNFBD3CKJN5CT5DGFHLXW4Y2LANCNFSM6AAAAAA34RPARU
.
You are receiving this because you authored the thread.Message ID:
@.***>

authors: DonJayamanne gincru

repo: microsoft/vscode-jupyter


text:
Review changes to Proposed API and Trusted Notebooks

The concept of trusting notebooks has changed in the API

Review the current proposed API (changes)
Review the new proposed API (what's the proposed solution for enabling trust in notebooks?)
Remove redundant code (tests, changing metadata to trusted, runnable, etc) - where applicable

Note: VSC hasn't decided on an API yet, track the progress here https://github.com/microsoft/vscode/issues/118584

Closing for now, as there's nothing to be done. We have reviewed the issue and provided feedback.