Skip to content
This repository has been archived by the owner on Jan 15, 2023. It is now read-only.

Support for dotnet? #52

Closed
Thaina opened this issue Sep 5, 2017 · 19 comments
Closed

Support for dotnet? #52

Thaina opened this issue Sep 5, 2017 · 19 comments

Comments

@Thaina
Copy link

Thaina commented Sep 5, 2017

I use C# for my lambda and want to test it in local. AWS point to here that we can test lambda locally by this docker. Would you pleased to add C# dotnet in this too?

@mhart
Copy link
Member

mhart commented Sep 5, 2017

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

@joaoasrosa
Copy link

Hi @mhart,

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

Cheers

@mhart
Copy link
Member

mhart commented Jan 26, 2018

@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
Copy link

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

@jason-riddle
Copy link

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

@joaoasrosa
Copy link

joaoasrosa commented Jan 26, 2018

@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
Copy link

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
Copy link
Member

mhart commented Jan 26, 2018

@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
Copy link

romanlum commented Jan 26, 2018

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
Copy link

romanlum commented Jan 26, 2018

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
Copy link

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
Copy link
Member

mhart commented Jan 26, 2018

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

@mhart
Copy link
Member

mhart commented Jan 26, 2018

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
Copy link

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

@jason-riddle
Copy link

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
Copy link

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
Copy link

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

@jason-riddle
Copy link

jason-riddle commented Feb 20, 2018

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

@mhart
Copy link
Member

mhart commented Feb 20, 2018

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.

@mhart mhart closed this as completed Feb 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants