.netcore 3.1 builds broken as of 30/06/2022

[DevDaveC]

Google cloud build no longer working as of 30/06/2022 for .netcore 3.1
I tested an old working build and got the same error so it is not a code change causing this

It now outputs this error
Build failed: Failed to run /bin/build: couldn't find runtime version from runtimeconfig.json: &dotnet.RuntimeConfigJSON{RuntimeOptions:dotnet.runtimeOptions{TFM:"netcoreapp3.1", Framework:dotnet.framework{Name:"Microsoft.NETCore.App", Version:"3.1.0"}, Frameworks:[]dotnet.framework(nil), ConfigProperties:dotnet.configProperties{SystemGCServer:false}}}; Error ID: b1205d15

[jskeet]

Please could you show exactly how you're running the build, so I can try to reproduce it? (I've just tried deploying with "gcloud functions deploy" which does use Cloud Build behind the scenes, and that worked fine.)

[DevDaveC]

using command
gcloud functions deploy {FunctionName} --runtime dotnet3 --trigger-event="providers/cloud.firestore/eventTypes/document.create" --trigger-resource="{triggerPath}" --entry-point {classNamespace} --project #{CloudFirestoreProject} --region europe-west2 --set-build-env-vars=GOOGLE_BUILDABLE={filePath} --timeout 120 --vpc-connector={FirebaseVPCConnector} --egress-settings=all

also referencing libaries that have target framework set to 'net472;netcoreapp3.1'

[jskeet]

Interesting - so still with gcloud functions deploy. Are you able to put together a minimal repro of this? (For example, does it still happen for a single project where you don't need GOOGLE_BUILDABLE?) I would hope that the vpc-connector and egress-settings parts aren't relevant here... basically I want to reduce this to the smallest example that demonstrates the problem. I'll try with the multi-project sample, as I suspect that's the part that's most likely to have issues, but there are lots of potential areas for investigation.

[jskeet]

Hmm... my multi-project build is working fine, including if I change the dependency project to target net472 and netcoreapp3.1. So I'm afraid I won't be able to make any more progress without something that helps me reproduce the issue.

[DevDaveC]

I've recreated the issue, the cause is adding EntityFramework 6.4.4 to the dependancy project. I have attached my example FunctionsTest.zip

[jskeet]

Interesting. I'm travelling for the next couple of days, but I'll have a look on Thursday. Sorry for the delay.

[jskeet]

First update: with a single project solution, just adding EntityFramework (and then "using" it by printing out typeof(DbContext).AssemblyQualifiedName) doesn't cause a problem. I'm going to try your repro now.

[jskeet]

Now reproduced, thanks for the code - I'm trying to slim the problem down further.
I suspect the problem is the file it's trying to use for the runtime config. My log contains:

Using runtimeconfig file "ServiceSight.Dependancy/bin/Release/netcoreapp3.1/ServiceSight.Dependancy.runtimeconfig.json"

... whereas it should really be looking in ServiceSight.FunctionsTest.runtimeconfig.json.

[jskeet]

Current simplified version that still demonstrates the problem:

• Only targets netcoreapp3.1 in the dependency
• Doesn't specify a Platforms element in the dependency
• Doesn't specify an EmbeddedResourceUseDependentUponConvention element in the dependency
• Doesn't depend on Elmah, or Google.Events.Protobuf, or (directly) Google.Cloud.Functions.Framework (just Google.Cloud.Functions.Hosting and the project dependency)
• Implements IHttpFunction (because that's easier to test)

I'll keep looking either later today or tomorrow. (I'm travelling again today I'm afraid.) But this is definitely progress...

[DevDaveC]

gcloud functions deploy FunctionTest --runtime dotnet3 --trigger-http --entry-point ServiceSight.FunctionTest.Function --project arboreal-drake-232413 --region europe-west2 --set-build-env-vars=GOOGLE_BUILDABLE=ServiceSight.FunctionTest

[jskeet]

Okay, I think I've got it. When the EntityFramework dependency is included and you build the function (which obviously builds the dependency) you end up with a ServiceSight.Dependancy/bin/Release/netcoreapp3.1/ServiceSight.Dependancy.runtimeconfig.json file.

It looks like the buildpack uses the first runtimeconfig.json it finds, assuming them all to be identical. This isn't a problem in a single-project scenario, of course - but when there are multiple projects with different runtime configurations, it does become a problem.

This is a bug, and should be fixed - I'll file an issue in the buildpacks repo later.

But for the moment, there's a horribly hacky workaround you can use... if you rename ServiceSight.FunctionTest to ServiceSight.AFunctionTest, then that runtime config becomes the first one found (before the dependency) and it all works fine. Obviously that's far from a great solution, but I hope it works for you as a starting point.

[jskeet]

I've got another workaround, which may or may not be useful to you - if you change the target framework of the dependency to netstandard2.1, that doesn't generate a runtimeconfig.json file, avoiding the ordering issue. (You can target net472 separately and it still works, in fact.)

[jskeet]

I'm going to close this issue now, as the buildpacks repo is the right place to fix this - but please do add any comments (either here or on that issue) if you have additional insights/restrictions.