Skip to main content
M
MA873117416-Pearl
16-Pearl
February 18, 2026
Solved

Calling service via Things["ThingName"] works, but direct dependency reference causes error

  • February 18, 2026
  • 3 replies
  • 92 views

Hi everyone,

I have two ThingWorx projects that depend on each other. Both i want to  import as packages into our server.

I noticed the following behavior:

When I reference the Thing dynamically like this, it works without any issue means package is created:

 

const Controller = "thingName;

Things[Controller ].serviceOne({
 id: 234,
 state: "complete",
});

 

However, when I try to use the dependency more directly (e.g., referencing it statically without the intermediate variable), I get an error while packaging for dependency.

 

Things[thingName].serviceOne({
 id: 234,
 state: "complete",
});

 

My questions:

  • Is there a recommended way to handle cross-project Thing references?

Any insights or best practices would be appreciated.

Thanks in advance!

Best answer by Constantine
Hello,

A proper way to do it would be by decoupling your cross-project dependencies by making thing names configurable via Configuration. So you’d be calling something like Things[me.GetXxxUtility()].Yyy(), with GetXxxUtility() reading a dependency name from Configuration. Not only it would help with packaging, but also make it easier to unit-test.

Regards,
Constantine

3 replies

N
nmutter16-Pearl
16-Pearl
February 20, 2026

It's quite hard to understand what you are asking. What I take:

  • You have a circular dependency. E.g. Project A depends on Project B, and Project B depends on Project A.

Your unspecified error mentioned might be something like "Project [ProjectA] cannot depend on itself in a circular dependency from [ProjectB]. These project cannot be published until this is resolved manually"

 

This is not good 🙂🙂

Solution is to redesign so you do not have this circular dependency anymore. This is a common issue in software development with different strategies to resolve. Just some (AI generated):

  • Extract a Shared Abstraction
  • Use Dependency Inversion

So find out what your dependency is for both projects and think about how to turn one around - or move the shared one into Project C. Best strategy is based on the actual use cases you have.

 

So not sure if this helps you. But you may share some more context maybe on both dependencies otherwise to find a good solution to your issue

 

    C
    Constantine18-OpalAnswer
    18-Opal
    February 20, 2026
    Hello,

    A proper way to do it would be by decoupling your cross-project dependencies by making thing names configurable via Configuration. So you’d be calling something like Things[me.GetXxxUtility()].Yyy(), with GetXxxUtility() reading a dependency name from Configuration. Not only it would help with packaging, but also make it easier to unit-test.

    Regards,
    Constantine
      A
      abandal12-Amethyst
      12-Amethyst
      February 27, 2026

      Hi @MA8731174,

       
      I wanted to follow up with you on your post to see if your question has been answered.
      If so, please mark the appropriate reply as the Accepted Solution for the benefit of other members who may have the same question.
      Of course, if you have more to share on your issue, please let the Community know so that we can continue to support.


      Thanks,
      Abhi

       

      Terms & ConditionsCookie settingsAccessibility statement