Yeah there is something dodgy about Amazon.Lambda.Core. I created a class library in Fire and visual studio. I added Amazon.Lambda.Core v2.1.0 from nuget to both and opened the assemblies in dotnet peek. It shows the version as 1.0.0.0
The file version is 1.0.0.0 but the product version is 2.1.0
Did you manage to finish this ? Im still generating anycpu so I was going to try generating x64, fixing the deps.json and seeing if that made a difference.
What part is missing?
the support for appending the RuntimeIdentifier to the name is in .2803. This will not use the architecture field (because that doesnāt give you the ālinux-ā part), if anything does at all. For your case, set RuntimeIdentifiers to one value, ālinux-x64ā.
.2803 also exposes that project setting in Fire/Water (not in VS yet, need to merge that over).
.2803 also filters the runtimes by (crudely) checking if the runtime matches at least one of the specified RuntimeIndentifiers (if any); in your case, this should leave runtimes empty, for Linux, according to the test case you sent (which had only windows and browser runtimes).
The latest .2804 build on firehose should have the fix for bringing back the assemblyVersion/fileVersion on the reference.
Am I missing any other plot points?
Thanks very much. Iāll give everything a try. The RuntimeIdentifier only seems to appear if you select binary type as exe, could you make it so that it works with library as well ?
Hmm, I guess now that it affects the deps.json too, it makes sense to expose that for libraries too, yeah. will fix.
Thanks. When I run the thing I still get the same error but I found the source code so Im going to see if I can work out what the issue is.
I tested a few things and there is one thing missing
{
"runtimeTarget": {
"name": ".NETCoreApp,Version=v6.0/linux-x64",
"signature": ""
},
"compilationOptions": {
},
"targets": {
".NETCoreApp,Version=v6.0": {},
".NETCoreApp,Version=v6.0/linux-x64": {
"HelloWorld/1.0.0": {
When the runtimeTarget is different there also needs to be an associated target as well. Like in the above.
Ah, ok. will fix first thing tomorrow
In the libraries section, the nugets Ive referenced are also different
This is dotnet
"Amazon.Lambda.Core/2.1.0": {
"type": "package",
"serviceable": true,
"sha512": "sha512-ok06UhfBZw6j6+PhiJR9C0EOMuJvnq8rMCHVkaFmPFrlI/q447ukwGZQKaAKqodV+MNTfpb/iPxjgUPVbSlVVw==",
"path": "amazon.lambda.core/2.1.0",
"hashPath": "amazon.lambda.core.2.1.0.nupkg.sha512"
},
vs Elements
"Amazon.Lambda.Core/2.1.0": {
"type": "package",
"serviceable": false,
"sha512": "",
"path": "amazon.lambda.core/2.1.0",
"hashPath": "amazon.lambda.core.2.1.0.nupkg.sha512"
},
serviceable is false and sha512 is missing
Iāll need to check where those come from. But these should not cause problems.
I was reading this sdk/runtime-configuration-file.md at main Ā· dotnet/sdk Ā· GitHub
serviceable - a boolean indicating if the library can be serviced (only for package-typed libraries)
sha512 - SHA-512 hash of the package file (package-typed libraries).
lol. what does that mean ? There isnt really an explanation of what anything is used for.
To be clear, does it need BOTH, or just the /linux-x64 added to the one thatās there? if both, should the first one be empty?
Imagine a world where this stuff was documentedā¦ 
I get these straight from the package
property Serviceable: Boolean read coalesce(Xml:Root:FirstElementWithName("metadata"):FirstElementWithName("serviceable"):Value:ToLowerInvariant = "true", false);
property Sha512: nullable String read if ShaFile.FileExists then "sha512-"+File.ReadText(ShaFile);
property ShaFile: String read Path.Combine(LocalCacheFolder, Name.ToLowerInvariant+"."+Version.ToLowerInvariant+".nupkg.sha512");
the Amazon package doesnāt have Servicable set, and has no hash file. So this part is āas designedā IMHO.
The dotnet one has both with the first empty.
This is one generated.
HelloWorld.deps.json (3.0 KB)
It has sha512 set, I wonder where it gets the value from
This is one of generated from Elements, so it does set sha512 and serviceable. Iāll create another dotnet one with more references
"Microsoft.Extensions.Configuration.Binder/6.0.0": {
"type": "package",
"serviceable": true,
"sha512": "",
"path": "microsoft.extensions.configuration.binder/6.0.0",
"hashPath": "microsoft.extensions.configuration.binder.6.0.0.nupkg.sha512"
},
"Microsoft.Extensions.DependencyInjection/6.0.0": {
"type": "package",
"serviceable": true,
"sha512": "sha512-wl7voCCnhdhgj4xbwbfUeao/m7MpWqxBoba4FEDujC1obyirX3yb2MdiFSrYlXzHG3q/p9S2yFWSv8J+UVWSig==",
"path": "microsoft.extensions.dependencyinjection/6.0.0",
"hashPath": "microsoft.extensions.dependencyinjection.6.0.0.nupkg.sha512"
},
I created shadotnet using dotnet and shaconsoleapplication using Fire
ShaConsoleApplication3.deps.json (3.2 KB)
shadotnet.deps.json (2.9 KB)
If you look at System.Threading.Tasks.Dataflow and Amazon.Lambda.Core sha512 and serviceable are being set in dotnet
Ok, thatās what Iāve done now, will be in the next build.
Indeed. i suppose to could calculate it fresh, but then why doesnāt
have it too?
As for Serviceable, maybe Iām assuming the wring default, and no value is supposed to lead to true? idkā¦ As I said, I donāt think either of these two should have any effectā¦
Note you do seem to be pulling in different reference versions.: 6.0 vs 7.0, even though both projects say 7.0.
itās also odd (and maybe wrong) that āAmazon.Lambda.Core.dllā is listed under runtime for ours, but no for dotnet. (Echoes.dll is of course an expected difference).
aws lambda is using dotnet 6.4 and as far as I can workout the 7.x microsoft extension nugets are intended for dotnet 7 and 6.x for 6 so thats why the elements one has 6.
My more complex project still isnt loading so I can try removing Amazon.Lambda.Core from runtimes and see if it makes a difference
