Creating a C# Module Reference throws an error SOLVED

I’m following the Cloud Code tutorial.
“Create > Services > Cloud Code C# Module Reference” throws an error:

InvalidOperationException: Failed to add object of type `CloudCodeModuleReference`. Check that the definition is in a file of the same name and that it compiles properly.
Unity.Services.CloudCode.Authoring.Editor.Modules.CloudCodeModuleReferenceImporter.OnImportAsset (UnityEditor.AssetImporters.AssetImportContext ctx) (at ./Library/PackageCache/com.unity.services.cloudcode@2.8.1/Editor/Authoring/Modules/CloudCodeModuleReferenceImporter.cs:22)
UnityEditor.AssetImporters.ScriptedImporter.GenerateAssetData (UnityEditor.AssetImporters.AssetImportContext ctx) (at <5e53ad466ce74a6082606d7fa046fc9b>:0)

The created ccmr file looks like this:

{
  "modulePath": "..\\..\\HelloWorld\\HelloWorld.sln"
}

I’m using 2022.3.50f1 with all the latest CC/Deployment etc packages imported
Windows 11
I’ve followed the tutorial to the letter. Any help would be appreciated!

EDIT: Removed and reinstalled all the UGS plugins, and then it worked. Feels a bit shaky…

Hey,
Sorry for the issue. I will ask the importer team as this doesnt seem to be on our side. It basically says it was unable to find the .cs file.

Cheers!

Thanks for getting back to me!
Looking back, I think what might have happened was an environment mismatch. Which leads me to another question… I set the environment at runtime, but this doesn’t seem to affect Cloud Code calls. Is there any way to force CC to use an environment? I’m doing this with Remote Settings, but I haven’t found a way to do this for CC.
Thanks!

Hi!

A lot to unpack :slight_smile:

I think what might have happened was an environment mismatch.

What versions of the packages are you using? Specially Services.Core, Services.CloudCode, Services.Deployment?

I set the environment at runtime, but this doesn’t seem to affect Cloud Code calls

How are you setting the environment specifically?

I’m doing this with Remote Settings

Im guessing you mean remote config?

To clarify, you should be setting up the environment with either the dropdown or through code for all services

var options = new InitializationOptions();
options.SetEnvironmentName("dev");
await UnityServices.InitializeAsync(options);

If Im reading between the lines, you are probably using a legacy remote-config environment set-up, that indeed will not work for Cloud-Code

Let me know if that helps,

cheers!

Thanks for replying despite my sloppy communication…
Let me take half a step back.
My dream scenario would be to set the environment individually for each user at runtime during the development phase (clients, devs, creatives, etc).

My solution:

  1. Initialize UGS services
  2. Sign in user
  3. Check a Cloud Save key for the user’s preferred environment
  4. Re-initialize UGS services with the specified environment

It doesn’t seem that the environment changes after the second initialization, even though I’m doing this:

    var options = new InitializationOptions();
    options.SetEnvironmentName(environmentName);
    await UnityServices.InitializeAsync(options);

When pulling in Remote Config settings, I can get around it by specifying the environment like the so (no indication this would be deprecated in 4.0.2):

   RemoteConfigService remoteCfg = RemoteConfigService.Instance;
   remoteCfg.SetEnvironmentID(environmentId);

   // Fetch config
   RuntimeConfig runtimeConfig = await remoteCfg.FetchConfigsAsync(new userAttributes(), new appAttributes());

   // Check result to validate environment 
   Debug.Log(runtimeConfig.environmentId.ToString());

Now I’m trying to achieve the same thing with Cloud Code, but I haven’t found a way to “force” an environment when calling a CC method.

I’m using 2022.3.50f1 and the most current versions of all UGS plugins:

  • Core: 1.14.0
  • Cloud Code: 2.9.0
  • Deployment: 1.4.1
  • Authentication: 3.4.0
  • Remote Config: 4.1.1
  • Remote Config Runtime: 4.0.2

Hey!
I’ll have to check with my colleagues to see if we can “uninit” and re-init the core package.
The simple fix is to use the APIs directly: Redirecting to latest version of com.unity.services.apis

This package allows you to talk to the services directly, bypassing all tooling, so you can set the environment whenever you’d like. You could even just use that to only use cloud-save, and then set up the environment according to that and proceed as usual.

However, the solution I would most likely recommend is to ship either a local configuration file you check out, or different binaries for dev/stg/prod (the latter is the most common in the industry). Each user getting an environment dynamically is definitely odd, specially if you want to share state (like leaderboards, cloud-save, etc) across multiple environments. It could make some debugging nightmarish too.

I hope this solves your issue. Let me know. Sorry for delay, start of the year was busy and all.

Cheers!

cc: @erickb_unity

1 Like