Arash-Sabet commented 7 months ago

The func start command used to work flawlessly but it started showing the subject error message. Further info:

.NET SDK 8.0.101
func --version reveals version 4.0.5455
There is only one .csproj file in the function app's folder, but the function app is a part of a C# solution
I launched VS Code to create and initialize a new minimal azure function app. The func start works.

xandrw commented 7 months ago

I'm having the exact same issue.

Arash-Sabet commented 7 months ago

Just an update: this issue is happening not only on Windows 11, but also on a macOS with VS Code. I think the priority of this issue must be elevated to address and deploy a solution ASAP.

/cc @khkh-ms

ryanzwe commented 7 months ago

Delete the /bin & obj folder

Arash-Sabet commented 7 months ago

@ryanzwe It worked as a workaround but one has to keep doing it every single time. I think the root cause must be addressed.

ryanzwe commented 7 months ago

Glad it worked, sadly it's pretty annoying. It doesn't bother me too much since I just run azure functions through visual studio instead of CLI, but might be worth just making a quick script that will clear out ur obj & bin folders and then run func start

Arash-Sabet commented 7 months ago

@ryanzwe VS 2022 works smoothly but it becomes more annoying when one has to work by VS Code on macOS.

xandrw commented 7 months ago

Delete /bin and /obj folders, downgrade packages until it works.

Arash-Sabet commented 7 months ago

@xandrw which packages specifically?

Hipster74 commented 7 months ago

UPDATE: Check here for this issue https://github.com/Azure/azure-functions-core-tools/issues/3602

Adding to this issue.

dotnet-isolated V4 durable function
.NET SDK 8.0.201
func --version version 4.0.5530
There is only one .csproj file in the function app's folder, but the function app is a part of a C# solution

Func start gives error 'Can't determine Project to build. Expected 1 .csproj or .fsproj but found 2'

If I delete /bin & /obj folder it builds, but fails to start function with:

Could not load file or assembly 'Microsoft.Azure.WebJobs.Script.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c5b9424214e8f8c'. The system cannot find the file specified.

.csproj

`

net8.0 v4 win-x64 true Exe enable enable `

ryanzwe commented 7 months ago

Adding to this issue.

dotnet-isolated V4 durable function

.NET SDK 8.0.201

func --version version 4.0.5530

There is only one .csproj file in the function app's folder, but the function app is a part of a C# solution

Func start gives error 'Can't determine Project to build. Expected 1 .csproj or .fsproj but found 2'

If I delete /bin & /obj folder it builds, but fails to start function with:

Could not load file or assembly 'Microsoft.Azure.WebJobs.Script.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c5b9424214e8f8c'. The system cannot find the file specified.

.csproj

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <AzureFunctionsVersion>v4</AzureFunctionsVersion> <RuntimeIdentifier>win-x64</RuntimeIdentifier> <PublishReadyToRun>true</PublishReadyToRun> <OutputType>Exe</OutputType> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> </PropertyGroup> <ItemGroup> <PackageReference Include="Azure.Data.Tables" Version="12.8.3" /> <PackageReference Include="Azure.Identity" Version="1.10.4" /> <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.3.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.1.1" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" /> <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" /> <PackageReference Include="Microsoft.Extensions.Azure" Version="1.7.2" /> <PackageReference Include="Microsoft.Extensions.Http.Resilience" Version="8.2.0" /> <PackageReference Include="Result.Net" Version="1.5.0" /> </ItemGroup> <ItemGroup>

Try restore manually, or install that package individually, had this happen before on a dependent package needing newtonsoft, installing newtonsoft directly fixed it.

dawidcieszynski commented 7 months ago

I got this issue when upgraded from Microsoft.Azure.Functions.Worker.Sdk 1.16.4 to 1.17.0 In my case temporary solution was to remove obj\Debug\net8.0\WorkerExtensions\WorkerExtensions.csproj before every function start.

(I upgraded because I had another issue with missing operation_Name in the application insights and now checking whether I need 1.17.0 or not :) )

Hipster74 commented 7 months ago

Adding to this issue.

dotnet-isolated V4 durable function

.NET SDK 8.0.201

func --version version 4.0.5530

There is only one .csproj file in the function app's folder, but the function app is a part of a C# solution

Func start gives error 'Can't determine Project to build. Expected 1 .csproj or .fsproj but found 2' If I delete /bin & /obj folder it builds, but fails to start function with: Could not load file or assembly 'Microsoft.Azure.WebJobs.Script.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c5b9424214e8f8c'. The system cannot find the file specified. .csproj <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <AzureFunctionsVersion>v4</AzureFunctionsVersion> <RuntimeIdentifier>win-x64</RuntimeIdentifier> <PublishReadyToRun>true</PublishReadyToRun> <OutputType>Exe</OutputType> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> </PropertyGroup> <ItemGroup> <PackageReference Include="Azure.Data.Tables" Version="12.8.3" /> <PackageReference Include="Azure.Identity" Version="1.10.4" /> <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.3.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.1.1" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" /> <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" /> <PackageReference Include="Microsoft.Extensions.Azure" Version="1.7.2" /> <PackageReference Include="Microsoft.Extensions.Http.Resilience" Version="8.2.0" /> <PackageReference Include="Result.Net" Version="1.5.0" /> </ItemGroup> <ItemGroup>

Try restore manually, or install that package individually, had this happen before on a dependent package needing newtonsoft, installing newtonsoft directly fixed it.

Thanks @ryanzwe , this issue is already handled here : https://github.com/Azure/azure-functions-core-tools/issues/3602

ryanzwe commented 7 months ago

Adding to this issue.

dotnet-isolated V4 durable function

.NET SDK 8.0.201

func --version version 4.0.5530

There is only one .csproj file in the function app's folder, but the function app is a part of a C# solution

Func start gives error 'Can't determine Project to build. Expected 1 .csproj or .fsproj but found 2' If I delete /bin & /obj folder it builds, but fails to start function with: Could not load file or assembly 'Microsoft.Azure.WebJobs.Script.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c5b9424214e8f8c'. The system cannot find the file specified. .csproj <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <AzureFunctionsVersion>v4</AzureFunctionsVersion> <RuntimeIdentifier>win-x64</RuntimeIdentifier> <PublishReadyToRun>true</PublishReadyToRun> <OutputType>Exe</OutputType> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> </PropertyGroup> <ItemGroup> <PackageReference Include="Azure.Data.Tables" Version="12.8.3" /> <PackageReference Include="Azure.Identity" Version="1.10.4" /> <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.3.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.1.1" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" /> <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" /> <PackageReference Include="Microsoft.Extensions.Azure" Version="1.7.2" /> <PackageReference Include="Microsoft.Extensions.Http.Resilience" Version="8.2.0" /> <PackageReference Include="Result.Net" Version="1.5.0" /> </ItemGroup> <ItemGroup>

Try restore manually, or install that package individually, had this happen before on a dependent package needing newtonsoft, installing newtonsoft directly fixed it.

Thanks @ryanzwe , this issue is already handled here : https://github.com/Azure/azure-functions-core-tools/issues/3602

Yikes.. New day, something new broken.. Seems we're all having fun working on newer azure functions :P

cr3wdayt5p commented 7 months ago

I can confirm this happens when upgrading Microsoft.Azure.Functions.Worker.Sdk from 1.16.4 to 1.17.0.

Details:

.NET SDK 8.0.200
func --version version 4.0.5530

dustinrbb commented 7 months ago

Had this issue as well due to the same cause with Microsoft.Azure.Functions.Worker.Sdk version 1.17.0. Looks like the latest version of the package resolves this issue though. Deleting the current bin/obj directories and then updating Microsoft.Azure.Functions.Worker.Sdk to 1.17.2 resolves this issue.

per-samuelsson commented 6 months ago

I have Microsoft.Azure.Functions.Worker.Sdk 1.17.2 and the latest tooling, 4.0.5611. This issue persist.

Deleting bin and obj works as a workaround still.

tiwilson7 commented 6 months ago

We just upgraded to latest isolated functions with .net 8 and 4.0.5611 azure function core tools and are receiving the same issue.

The workarounds mentioned above work, but they are really annoying.

I will add that you can use the command line to clean and start at the same time, which makes it slightly less annoying.

dotnet clean & func start -p 1234

alij commented 4 months ago

The dotnet clean work around didn't work for me as it doesn't remove the WorkerExtensions.csproj. I need to delete it manually for it to work:

rm {Path_To_Project}\obj\Debug\net8.0\WorkerExtensions\WorkerExtensions.csproj func start --verbose

akashkolaTap commented 4 months ago

Hi, I'm facing the same issue still. Is there any update on it? Steps to reproduce:

Second time function start

codebrane commented 4 months ago

This started with VSCode on Mac v1.90.0. There is no way to run anything from VSCode now, without first deleting the obj and bin folders to get rid of:

Can't determine Project to build. Expected 1 .csproj or .fsproj but found 2

obj/Debug/net8.0/WorkerExtensions/WorkerExtensions.csproj ./TheProject.csproj

v1.90.0 also seemed to break SLN files as the project started using .vscode/launch.json in the root directory so it couldn't run from that either. Had to remove all SLN files to get it to the point where it fails with the above error.

The problem seems to happen when I open the folder, save as workspace, close, then open the workspace and it adds a .sln file. On every dotnet build it then crashes with:

/usr/local/share/dotnet/sdk/8.0.100/NuGet.targets(399,5): error MSB3202: The project file ... obj/Debug/net8.0/WorkerExtensions/WorkerExtensions.csproj was not found

The project itself builds fine until I open the folder with VSCode. VSCode then crashes with the above errors when launching Attach to .NET Functions.

Deleting the .sln file lets dotnet build work again but VSCode then crashes with:

Language Worker Process exited. Pid=70633. dotnet exited with code 134 (0x86). Unhandled exception. System.ArgumentException: Don't know which KeyVault to read from. Exceeded language worker restart retry count for runtime:dotnet-isolated. Shutting down and proactively recycling the Functions Host to recover

Removing all traces of VSCode from the project and dotnet build works every time. Opening the folder in VSCode destroys it. VSCode deletes the file it's looking for:

obj/Debug/net8.0/WorkerExtensions/WorkerExtensions.csproj

and dotnet build no longer works.

The only way to get dotnet build to work again is to delete the .sln file created by VSCode. VSCode is also incapable of debugging as it can no longer build as it deletes the file it needs from its .sln file.

codebrane commented 4 months ago

To reproduce the issue:

create new Azure Function App project using VSCode with HttpTrigger
new project works fine and function app runs locally
save project as workspace. SLN file appears in project directory.
at this point dotnet build is still working
run function app locally. VSCode fails to run the function app if the sln file is present.
project is now unusable. Cannot run function app locally, cannot run dotnet build. The sln file is around twice as big as existing sln files from previous versions of vscode. Its presence stop vscode working.

/usr/local/share/dotnet/sdk/8.0.100/NuGet.targets(399,5): error MSB3202: The project file "/Users/alistair/dev/test/TestFunction/obj/Debug/net8.0/WorkerExtensions/WorkerExtensions.csproj" was not found. [/Users/alistair/dev/test/TestFunction/TestFunction.sln]

Existing projects and workspaces are fine. It's just workspaces created with this version of VSCode:

Version: 1.90.0 Commit: 89de5a8d4d6205e5b11647eb6a74844ca23d2573 Date: 2024-06-04T19:34:44.157Z Electron: 29.4.0 ElectronBuildId: 9593362 Chromium: 122.0.6261.156 Node.js: 20.9.0 V8: 12.2.281.27-electron.0 OS: Darwin x64 22.6.0

Deleting the sln file resolves the issue but VSCode recreates it when opening the workspace and destroys the project.

FinOCE commented 4 months ago

Currently facing this issue as well. .net 8.0.301, func tools 4.0.5148, worker sdk 1.17.2, F# project. Deleting obj and bin workaround works but not dotnet clean. Any updates on a proper fix being made?

HugoKNL commented 3 months ago

Happens for me in wsl with .net SDK 8.0.301, runtime 8.0.6 and func version 4.0.5801

paulyuk commented 3 months ago

ACK I just filed this bug too and realize my bug is a dupe of this. I am escalating directly to team.

albx commented 2 months ago

Same issue. In my case deleting the bin and obj folder solves the issue.

binoypatel commented 2 months ago

same issue with func: 4.0.5907, it's not only annoying but waste of time since deleting obj will do the restore and compilation all over again, this has to be addressed sooner than later.

MarksPoint commented 2 months ago

Same issue here! Of course, deleting bin and obj works (in my case, deleting obj is enough, since the second .csproj file is located in ./obj/Debug/net8.0/WorkerExtensions/WorkerExtensions.csproj), but this is no real solution as stated by others.

Please fix, MS!

dirkesquire commented 2 months ago

I don't wish to be mean, but I wonder who decided it would be a good idea to create \obj\Debug\net8.0\WorkerExtensions\WorkerExtensions.csproj on each build. I hope Azure Functions team seriously re-evaluates if this is indeed the route they want to be going in. I appreciate the hard work in separating out various workers, but there must be a better solution, surely. Perhaps this can be fixed in V5 on Azure Function Tools.

Error messages like: obj/Debug/net8.0/WorkerExtensions/WorkerExtensions.csproj" was not found if .sln file is present (which gets automatically created) and running 'dotnet build'. Error messages like: Can't determine Project to build. Expected 1 .csproj or .fsproj but found 2. if deleting the .sln file and running 'func start' twice in a row.

It just seems such an anti-pattern (one .csproj project creating another .csproj project), and completely confuses everything. Solution (.sln) files being automatically created, needing to delete /bin and /obj folders on each run. VS Code now can't debug anymore. Azure pipeline broke since there are two projects detected. Azure functions just seems a complete mess now. I must admit we are trying to upgrade from Azure Functions V1 which worked perfectly.

.net 8.0.301, func tools 4.0.1, worker sdk 1.17.4, C# project.

P.S. I've noticed that downgrading to the Worker.SDK 1.16.4 resolves this issue: <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />

davidgeary commented 2 months ago

FWIW (and as you'd probably expect), this is also a problem when running under Visual Studio 2022. Similar to that described above, the easiest workaround appears to be to add dotnet clean to the project's Post-build event.

TomJarFab commented 2 months ago

Still the same issue on version Microsoft.Azure.Functions.Worker.Sdk 1.17.4

ryanski44 commented 2 months ago

I've submitted a pull request with a fix to this issue. The fix limits the search for .csproj files to the function directory. It was recursively searching before. I think the fix is appropriate because the code in question is a validation check that is trying to make sure that a subsequent call to dotnet build is going to work, and dotnet build (when called without specifying a project file) also only looks in the working directory non-recursively. So, in my opinion the validation check should follow the same rules.

That being said, I'm not associated with this project in any way. I'm not a contributor to this project, nor do I work at Microsoft. I'm just someone who wanted this fixed. So, if you have one of the following questions, not only do I not know the answer, but I would also love to have an answer from a maintainer of this project.

When will this pull request be reviewed?
What release would this fix get included in?

I was able to build the project locally with my fix and then replace func.exe, func.dll in C:\Program Files\Microsoft\Azure Functions Core Tools with the ones I built and now the problem is fixed for me. You are welcome to attempt the same, but you would be on your own in terms of support, and there could be unexpected consequences of running a locally built version.

kshyju commented 2 months ago

Thanks for your patience. We are working on a fix for this issue.

Just to confirm, this issue is happening only for dotnet-isolated model function apps. Correct? If anyone else is seeing this issue in non-dotnet isolated apps, please share a minimal repro.

FinOCE commented 2 months ago

Thanks for your patience. We are working on a fix for this issue.

Just to confirm, this issue is happening only for dotnet-isolated model function apps. Correct? If anyone else is seeing this issue in non-dotnet isolated apps, please share a minimal repro.

I have a .net8 iso app that has this issue and a .net6 in-proc app that doesn't have it. Can't say for certain it doesnt happen on in-proc but at least on mine it doesn't.

dirkesquire commented 2 months ago

I'm using .net 8 dotnet-isolated. For me it is the Worker.SDK that is borked. Microsoft.Azure.Functions.Worker.Sdk - 1.16 - works Microsoft.Azure.Functions.Worker.Sdk - 1.17.0, 1.17.1, 1.17.2, 1..17.3, 1.17.4 - borked

Personally I'd like to see the changes made in Worker.SDK 1.17.* rolled back

reminvestor commented 2 months ago

I'm using .net 8 dotnet-isolated. For me it is the Worker.SDK that is borked. Microsoft.Azure.Functions.Worker.Sdk - 1.16 - works Microsoft.Azure.Functions.Worker.Sdk - 1.17.0, 1.17.1, 1.17.2, 1..17.3, 1.17.4 - borked

Personally I'd like to see the changes made in Worker.SDK 1.17.* rolled back

I have the same issue with isolated .net 8 function I created from vs code on Mac. I set the project to use 1.16 and did a dotnet restore then ran the function again but I get this error.

Determining projects to restore... Restored /Users/ryan/Documents/Functions/Functions.csproj (in 282 ms). Functions -> /Users/ryan/Documents/Functions/bin/output/Functions.dll Determining projects to restore... Restored /var/folders/qv/9vgr49v90rn6739y_m8zjc6w0000gn/T/n5kakvcq.fvp/WorkerExtensions.csproj (in 897 ms). WorkerExtensions -> /var/folders/qv/9vgr49v90rn6739y_m8zjc6w0000gn/T/n5kakvcq.fvp/buildout/Microsoft.Azure.Functions.Worker.Extensions.dll

Build succeeded. 0 Warning(s) 0 Error(s)

Time Elapsed 00:00:05.08

Azure Functions Core Tools Core Tools Version: 4.0.5907 Commit hash: N/A +807e89766a92b14fd07b9f0bc2bea1d8777ab209 (64-bit) Function Runtime Version: 4.834.3.22875

[2024-07-24T15:27:56.297Z] Found /Users/ryan/Documents/Functions/Functions.csproj. Using for user secrets file configuration. [2024-07-24T15:27:57.587Z] Worker process started and initialized.

Functions:

    QueueTrigger: QueueTrigger

For detailed output, run func with --verbose flag. [2024-07-24T15:27:59.730Z] Worker process started and initialized. [2024-07-24T15:27:59.736Z] Worker failed to load function: 'QueueTrigger' with functionId: '964268076'. [2024-07-24T15:27:59.737Z] Result: Failure [2024-07-24T15:27:59.737Z] Exception: System.InvalidOperationException: Unable to load Function 'QueueTrigger'. A function with the id '964268076' name already exists. [2024-07-24T15:27:59.737Z] at Microsoft.Azure.Functions.Worker.FunctionsApplication.LoadFunction(FunctionDefinition definition) in D:\a_work\1\s\src\DotNetWorker.Core\FunctionsApplication.cs:line 62 [2024-07-24T15:27:59.737Z] at Microsoft.Azure.Functions.Worker.GrpcWorker.FunctionLoadRequestHandler(FunctionLoadRequest request, IFunctionsApplication application, IMethodInfoLocator methodInfoLocator) in D:\a_work\1\s\src\DotNetWorker.Grpc\GrpcWorker.cs:line 269 [2024-07-24T15:27:59.737Z] Stack: at Microsoft.Azure.Functions.Worker.FunctionsApplication.LoadFunction(FunctionDefinition definition) in D:\a_work\1\s\src\DotNetWorker.Core\FunctionsApplication.cs:line 62 [2024-07-24T15:27:59.737Z] at Microsoft.Azure.Functions.Worker.GrpcWorker.FunctionLoadRequestHandler(FunctionLoadRequest request, IFunctionsApplication application, IMethodInfoLocator methodInfoLocator) in D:\a_work\1\s\src\DotNetWorker.Grpc\GrpcWorker.cs:line 269.

reminvestor commented 2 months ago

For a test I created the same queue trigger function from scratch on a windows machine with vs code and it just works for .net 8 isolated with no changes. The function starts right up. It seems to be something with Mac version of VS Code when running a function.

dzsquared commented 2 months ago

I think it may have something to do with the C# dev kit extension creating a sln automatically, not necessarily OS

dirkesquire commented 2 months ago

@eminvestor are you sure you ran 'dotnet clean' and deleted your bin and obj folders before doing your test. I am running <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" /> and .net 8 isolated and do NOT get the problem. And yes I am also using VS Code for Mac, so that is not a problem.

I can verify that running 'find . -name "*.csproj"' returns only one .csproj file generated with Worker.Sdk.

The fact that you have 'WorkerExtensions.csproj' and errors like 'A function with the id '964268076' name already exists.', would indicate that you have old files hanging about from the 1.17 version of the Worker.SDK.

jviau commented 2 months ago

3773 aims to address this issue. The root problem is the cli is trying to recursively search for csproj's as a pre-validation for calling `dotnet build`. Instead, this validation can be removed entirely as `dotnet build` will perform its own validation.

dirkesquire commented 2 months ago

Filtering out the second .csproj is actually not fixing the root problem, but more fixing a symptom of the problem.

The root cause is that versions 1.17 of the Worker.SDK are now producing WorkerExtensions.csproj, which it didn't before. This seems like an anti-pattern. One project generating another project on each and every build? It's a nightmare to debug, test and maintain. Sure you can 'filter' out the second .csproj but one still ends up with a bit of a code smell.

Running with Worker.SDK 1.16.4:

dotnet build
find . -name "*.csproj"

Result: ./my-fn-project.csproj (only the 1 .csproj of the project you are working on is found.)

Using Worker.SDK 1.17.0, 1.17.1, 1.17.2, 1.17.4:

dotnet build
find . -name "*.csproj"

Returns ./obj/Debug/net8.0/WorkerExtensions/WorkerExtensions.csproj ./my-fn-project.csproj

Suddenly you can see a new WorkerExtensions.csproj created on EACH build from version 1.17.0 onwards. That seems a bit weird and is going to make it so much harder to maintain the Azure Function code. It would be better code if it didn't create a project to create a dll, but just created the dll directly (like it did before).

What is the reason for WorkerExtensions.csproj? On my machine at least, WorkerExtensions.csproj seems to be targeting .net6.0: <TargetFramework>net6.0</TargetFramework> Which means another hidden subproject to maintain and which could go out of date.

Going back to Worker.SDK 1.16.4 and everything just works, it has been a nice feeling.

jviau commented 2 months ago

@dirkesquire the WorkerExtension.csproj is by design and will not be changing. The SDK has always been producing that project, just before it was placed in a new temp directory each build. We moved it to intermediate output directory so that the project's location is consistent between builds, allowing us to support incremental build.

This project is responsible for resolving the host extension payload to be included with the function app. We have discussed this design with the dotnet, msbuild, and nuget team. We all came to a conclusion there is no alternative to the generated project outside of re-implementing the entire assembly resolution system from the dotnet SDK - which is not a feasible approach.

kshyju commented 2 months ago

Thanks to @ryanski44 for contributing the fix for this issue. We will provide an update in this thread when a new version of the core tools, including this change, becomes available.

Note: The issue is automatically closed by the GitHub workflow when the associated pull request is completed. This means the change has been merged into the correct branch, and the next step is to release a new version of the core tools that includes this change.

asolimaan commented 2 months ago

till you fix it i create this workaround -- in powershell

function runAzurFunc {
    # clean
    dotnet clean

    # build and run
    func start
}
Set-Alias -Name zfunc  -Value runAzurFunc

-- in mac

runAzurFunc() {
    # clean
    dotnet clean
    # build
    func start
}
alias zfunc=runAzurFunc

mxa0079 commented 2 months ago

Thanks to @ryanski44 for contributing the fix for this issue. We will provide an update in this thread when a new version of the core tools, including this change, becomes available.

Is there an ETA?

I appreciate the effort, and in the spirit of providing good heart feedback I must say the the developer experience with Azure Functions in .NET has impacted my team's productivity -- to the point that we will not consider it as a viable architecture in the future and we will look for alternatives to migrate our code.

claus18 commented 2 months ago

For me this works fine with SDK 1.17.2 but fails when I upgrade Microsoft.Azure.Functions.Worker.Sdk to 1.17.4 (or 1.17.3) We're on dotnet 8.0.303
func version 4.0.5611 and using isolated mode with multiple functions in same solution file.

When starting from a the project directory

func start
Can't determine Project to build. Expected 1 .csproj or .fsproj but found 2

Shouldn't the SDK 1.17.3 and 1.17.4 be removed from nuget, since they are causing so much trouble? Even if you fix the tools version, it is not good to have breaking change in the SDK that forces you to upgrade the Tools at the same time. Also I find it strange that this issue is "Closed"

kshyju commented 2 months ago

@claus18 The issue is automatically closed by the GitHub workflow when the associated pull request is completed. This means the change has been merged into the correct branch, and the next step is to release a new version of the core tools that includes this change.

We will provide an update in this thread when a new version of the core tools, including this change, becomes available.

kpeek commented 1 month ago

Here's my workaround for VS Code on macOS - add a task to delete the bin and obj folders that runs before func host start

in tasks.json (important bit is task named clean-bin-obj):

    {
      "label": "run-data-processing",
      "type": "func",
      "command": "host start --port 7071",
      "options": {
        "cwd": "${workspaceFolder}/data-processing"
      },
      "isBackground": true,
      "presentation": {
        "reveal": "always",
        "clear": true,
        "group": "data-processing",
        "revealProblems": "onProblem"
      },
      "problemMatcher": "$func-dotnet-watch",
      "dependsOn": ["clean-bin-obj"]
    },
    {
      // Cleans the bin and obj folders (hack to get around https://github.com/Azure/azure-functions-core-tools/issues/3594)
      "label": "clean-bin-obj",
      "type": "shell",
      "command": "find . -type d \\( -name \"bin\" -o -name \"obj\" \\) -exec rm -rf {} +",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      },
      "options": {
        "cwd": "${workspaceFolder}"
      }
    }

PhilippRoessner commented 1 month ago

I have this issue in our .NET Aspire application. The workaround, deleting bin/obj, doesn’t work. I downgraded Microsoft.Azure.Functions.Worker.Sdk to 1.16.4, and I have this behavior with all the versions from 1.16.4 to the latest 1.17.4.

When I run the Azure function without .NET Aspire, it works fine.

Reading through these posts, I see that we are not alone in suffering from the horrible developer experience of Azure Functions. Our team works mostly with VS Code, and a little bit with Visual Studio. Both tools cannot even remotely offer the quality we are used to with other .NET technologies in development. “Blips” like this one will definitely get us to reevaluate our architecture design regarding serverless technologies.

dsschnau commented 1 month ago

I upgraded to version 4.0.5907, and I still have this problem. It's annoying :/

dirkesquire commented 1 month ago

It's clear that when someone decided it was a good idea to role out this switch to the .csproj file locations that they did not do proper testing before releasing. I think Microsoft needs to up their game on cross platform testing with Azure Functions. I would love to work for Microsoft to help with this.

Azure / azure-functions-core-tools

Can't determine Project to build. Expected 1 .csproj or .fsproj but found 3 when running "func start" #3594

3773 aims to address this issue. The root problem is the cli is trying to recursively search for csproj's as a pre-validation for calling `dotnet build`. Instead, this validation can be removed entirely as `dotnet build` will perform its own validation.

Azure / azure-functions-core-tools

Can't determine Project to build. Expected 1 .csproj or .fsproj but found 3 when running "func start" #3594

3773 aims to address this issue. The root problem is the cli is trying to recursively search for csproj's as a pre-validation for calling dotnet build. Instead, this validation can be removed entirely as dotnet build will perform its own validation.

3773 aims to address this issue. The root problem is the cli is trying to recursively search for csproj's as a pre-validation for calling `dotnet build`. Instead, this validation can be removed entirely as `dotnet build` will perform its own validation.