Calling an endpoint inside a Cloud Code C# Module from outside of Unity

Unity Services
, ,
1

I was experimenting with the new C# Modules feature in cloud code, and after some trial and error I finally managed to upload a small module!

However, I wasnt able to find any documentation on how to call an exposed function endpoint from inside a C# Module. I only saw the code refence for how to make the call inside a Unity project here. I wanted to test the endpoint directly an external HTTP request like how I could for standalone cloud code scripts.

Any help would be appreciated!

2

Hi there,

Thanks for trying out our latest features! At the moment we don’t yet have any dashboard integration which would allow for easily testing out your endpoints. Instead you can either test them out in a Unity project (as that would handle the authentication for you) or by calling the endpoints directly through something like Postman.

In order to call the endpoint yourself you’ll need to create an anonymous user using this endpoint and grab the idToken from the response. Then you can call the run module endpoint with the idToken as the Bearer key. This would allow you to test your modules outside of the Unity editor whilst we’re still working on improving the dashboard integration. Note that the idToken may expire and thus you’d either have to generate a new one or extend it (haven’t done that manually before but there’s an endpoint for that in the Authentication REST API as the SDK provides that as a feature as well).

Let me know if you need any help

2 Likes
3

Ah, the run module endpoint was exactly what i needed thank you Miley! Now I can reach my endpoint with postman.

However, I noticed I’m getting a status 422 Unprocessable Entity now, code 9009 with the following body

{
    "type": "problems/invocation",
    "title": "Unprocessable Entity",
    "status": 422,
    "detail": "Invocation Error",
    "instance": null,
    "code": 9009,
    "details": [
        {
            "message": "Could not load assemblies for module SayMyName. Ensure that the zip file includes all necessary DLLs and is compiled for linux-x64",
            "name": "ScriptRunner.Exceptions.InvalidModuleException",
            "stackTrace": []
        }
    ]
}

I made sure the module compiled on its own correctly as a class library. I even tried making a standalone app, then converting it to a class library, and that still threw this error. I had enabled trim unused code to ensure the file would be under 10mb so it could fit cloud code’s size requirements. I attached an image of the build settings I used in the image below.

8908062--1219437--Build Settings VS.png

4

I’m also noticing I’m not able to delete Uploaded C# Modules.
Despite the key I’m using having “cloud_code.modules.delete”, in its scopes, it wont read a JWT token made through the token exchange, because it returns a 401.

When using the basic 64 encoded key itself, it gives a 403 forbidden which means it recognizes permissions on the key, but doesnt allow it to delete cloud code modules despite the key service giving it that permission.

5

Did you ensure that the zip file at its root level contains all the .dll and .pdb files? Not a folder with those files?

As for the deletion, I’ll check with folks internally to see what’s up there and will update you once I know more

6

Just tried uploading a zip file and .ccm file with all of its files at root level, but still getting the same 422 error

8908650--1219647--Module File Structure Example.png
8908650--1219647--Module File Structure Example.png918Ă—647 55.4 KB

7

Interesting, I’ve asked the team to have a look as well.

As for the deletion, could you have a look at this page? The auth token might need to be encoded in a different manner as the deletion goes through the Admin API.

Edit:

I’ve also send you a DM, could you please share your C# Module project source code with me there?

8

Could you try and not use the self-contained option? We believe this may be the issue here. Do ensure that if you have the ability to enable Ready2Run that it’s turned on.

1 Like
9

Ah, your steps fixed it!

First I had to enable Ready2Run in visual studio by editing the project file and adding the property described in the MSDN docs.

Then I changed the deployment mode to framework-dependent, which gave a much smaller build size (18kb vs 9mb!) and when patching my module endpoint, I was able to successfully call it with parameters.

I think my point of confusion was this documentation on Module Deployment saying for Visual Studio to set the deployment mode to self contained on step 6, when that should be framework-dependent instead.

I’m also noticing the CLI listing uses the command --no-self-contained which now that I look it up, indicates for you to build as a framework-dependent application.

All of this is on top of ensuring the zip file is compressed so all of the necessary files are at root level as well. But thank you so much for the assistance!

1 Like
10

Great to hear it’s working now, we already fixed the docs yesterday to remove that step (that was a slight confusion internally when writing the docs) and I’ll have a look at how we want to add the PublishReadyToRun step for Visual Studio (myself I use Rider on macOS so I don’t have proper access to Visual Studio on Windows)