Azure-functions-vs-build-sdk: Microsoft.NET.Sdk.Functions v3.0.4 does not call IWebJobsStartup class

[briandunnington]

Updated to 3.0.4 today and started getting errors about DI types not being able to be resolved. Ran the debugger and noticed that the Startup class that implements IWebJobsStartup was not being called. Rolled back to 3.0.3 and confirmed that it works as expected there.

[AtOMiCNebula]

Seeing same behavior. bin\extensions.json is clearly not referencing any assemblies when using v3.0.4, but has my Startup-containing assembly (and other assemblies, in my case DurableTaskStartup) when using v3.0.3.

Curiously, I only see this when running dotnet build; dotnet publish produces okay content for publish\bin\extensions.json.

When enabling detailed build logging, _GenerateFunctionsExtensionsMetadataPostBuild build target clearly generates a failure, while _GenerateFunctionsExtensionsMetadataPostPublish is fine. I'm not debugging further though, and will leave it to sdk owners. :smile:

[Rocinante89]

I'm experiencing the same issue also

[WillEastbury]

Same here with CosmosDB Binding in v3.0.4

[WillEastbury]

3.0.4 Doesn't seem to be generating the correct content in the Extensions.json file.

3.0.3 generates
{
"extensions":[
{ "name": "CosmosDB", "typeName":"Microsoft.Azure.WebJobs.Extensions.CosmosDB.CosmosDBWebJobsStartup, Microsoft.Azure.WebJobs.Extensions.CosmosDB, Version=3.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"}
]
}

3.0.4 generates
{
"extensions":[
]
}

[vitalybibikov]

The same is valid for me as well.

[mmajcica]

Same here, with Microsoft.NET.Sdk.Functions 3.0.4. the code doesn't get into the FunctionsStartup class and the composition is not happening.

[rasmuschristensen]

Me too :(

[briandunnington]

Looks like this issue (as well as #390 and #391) might all be caused by this: https://github.com/Azure/azure-functions-host/issues/5747 - sounds like a fix is on the way, but I think that 3.0.4 should probably be removed from NuGet.

[brettsam]

Closing as dupe of https://github.com/Azure/azure-functions-host/issues/5747 (to make sure all updates happen in one place).

[daerhiel]

I've found that startup attribute stops working if project has reference to user secrets id, try removing it.
<UserSecretsId>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</UserSecretsId>

[rari2012]

Thanks for this hint @daerhiel - worked for me immediatly!
But, now it seems to be insecure - so - this is just a workaround - but have to be fixed i guess.
So i wil investigate further. Found this article and will try to follow that one: https://damienbod.com/2020/07/12/azure-functions-configuration-and-secrets-management/
Mybe this is also helpful for others.

[daerhiel]

But, now it seems to be insecure - so - this is just a workaround - but have to be fixed i guess.

Well, I'm not sure how about azure functions, but the UserSecretsId setting exists just for _local instance_ development to create the emulation of secure key repository. I don't think that this key is used wherever else, as it only exists in the project file, and never goes to the binary. For the cloud development you should use KetVault, and this id shoudln't play role there.

..but yeah, that's a nasty bug. I almost broke my head yesterday.

[rari2012]

Got it. @daerhiel .
Thanks.

[NaanKaran]

I've found that startup attribute stops working if project has reference to user secrets id, try removing it.
<UserSecretsId>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</UserSecretsId>

This one worked for me