Support for dotnet?

[lambci]

Support for dotnet?

[mhart]

Unfortunately this is a lot harder than the other languages, because replacing a single class in a .NET DLL is virtually impossible without having the original source.

I'm waiting on some support from AWS for this – I'll let you know when they get back to me

[mhart]

Oh yeah, forgot we also had an issue open. .NET Core 2.0 is now supported!

I'm going to close this out. If there's really a lot of ppl asking for .NET Core 1.0 support, I could look at adding that, but I feel like it's pretty low priority now that 2.0 is out.

[joaoasrosa]

Hi @mhart,

Any updates on this?
Let me know if I can help.

Cheers

[mhart]

@joaoasrosa sure! How much do you know about disassembling and reassembling .NET DLLs? If you can replicate the same way I do it in Java, that'd be a huge help: https://github.com/lambci/docker-lambda/blob/master/java8/run/lambda-runtime-mock/build.sh#L7-L14

[jason-riddle]

@mhart Is there a dotnet.tgz file we can play around with in order to test dissembling and reassembling?

[jason-riddle]

Actually it looks like #68 is attempting to address this issue.

[joaoasrosa]

@mhart and @jason-riddle if you do not mind I can take a look to #68 and try from there.
Also, from your work in Java, we can try ILMerge. I need to invest some time in research since I do not know if they support it for dotnet core.

[romanlum]

The key diffrence between the .NET and the Java implementation ist that the .NET runtime is bootstraped from a NATIVE binary using native memory and native libraries...
That`s why i replaced the whole bootstrap in #68

[mhart]

@romanlum it's actually still a compiled .NET binary though, and the libraries are .NET DLLs, except for the library that speaks to the AWS Lambda management layer, but that's the same with Java – that also uses a native library for that functionality, which is the only part I mock out.

Ideally the only part that is mocked out is just the part that communicates with the Lambda management layer – so that all of the rest of the code has the same behavior as it does on Lambda itself (eg, changing the way things are logged, or redirecting stdout or whatever).

[romanlum]

I don't think that the file /var/runtime/awslambda (which is the original entrypoint) is a compiled .net application.
It is a native application bootstraping the .net environment (calling /var/lang/bin/dotnet)

[romanlum]

Unfortunately we cannot use the original bootstrap.dll because there is a bug in the entrypoint which prevents us from replacing the lambda runtime as you did in java.

  if (!(str == "--lambda-runtime-override-assembly"))
          {
            if (!(str == "--lambda-runtime-override-type"))
            {
              if (str == "--errorcode")
              {
                errorcode = s;
              }
              else
              {
                BootstrapEntrypoint.Usage(string.Format("Invalid argument '{0}'", (object) str));
                return -1;
              }
            }
            else
              assemblyPath = s;
          }
          else
            assemblyPath = s;
        }

As you can see they are setting assemblyPath twice :(

if (string.IsNullOrWhiteSpace(assemblyPath) ^ string.IsNullOrWhiteSpace(empty))
  {
    InternalLogger.NO_OP_LOGGER.LogDebug("Override parameter missing, both lambda-runtime-override-assembly and lambda-runtime-override-type must be specified.");
    return -1;
  }

so this if can never be true :(

[romanlum]

In my implementation I used the internal classes from the original bootstrap.dll so the loading and parsing of the data is the same as with the original runtime

[mhart]

@romanlum you are right, it does appear to be a binary compiled from C, not .NET – my apologies!

[mhart]

In dotnetcore1.0, the /var/runtime/awslambda binary usage is like this:

awslambda --netcore <coreclr/corefx> --runtime <bootstrap assemblies root> --task <user code root>

I haven't checked if it's the same for 2.0?

[romanlum]

its the same
bash-4.2# ./awslambda
usage:
awslambda
--netcore <coreclr/corefx>
--runtime
--task

[jason-riddle]

Is it possible to patch a dll file? Or would it be “easier” just to decompile the dll, fix the bug, and then recompile? Also, I’m guessing that the dll is signed by Amazon correct?

[romanlum]

The dll is not signed, but the native binary awslambda is calling the bootstrap.dll so you cannot add commandline arguments that easy .

If you look at my code in the pull request you can see that i am using the internal UserCodeLoader, so it is the same as if the bootstrap.dll would have been called.

[joaoasrosa]

@mhart there are further developments on this front? Anything where we can help?

[jason-riddle]

Update: #68 has been merged which adds support for dotnet core 2.0.