Multi-level App Dependencies

So….I’m working through a new build process for our ISV solution. Why? Because we’re finally breaking it down into many extensions!! More on that another day…..

We’ve created a ‘library’ app which will house all of our common functionality. Each of our functional apps will have a dependency on the library app. Further to this, each of our functional apps will have its own test app. The test app of course has a dependency on the app that it is testing.

Like this:

So……you create your test app, add a dependency to the app you are testing and compile…..NOPE…..failure. 😦

In the above example, what needs to be done is the dependency to Library also needs to be added to Test App 1.

Like this:

Does this make sense? Maybe. This forces an assumption that because App 1 has direct access to the functions and entities within Library that Test App 1 also needs that access. In my example above, this direct access to Library was not something that we needed.

From the symbol perspective it perhaps makes a bit more sense. Adding the dependency forces the system to download the symbols for the dependent apps. If you just add the dependency for App 1‘ above, those symbols could be considered “incomplete” without also having the symbols for its dependencies, in this case Library.

I really (!!!) wish that we didn’t have to specify the extra dependencies. It would be nice if the compiler was able to figure out all of the downstream dependencies. An indirect dependency so to speak!?

The above scenario is fairly simple, but imagine this one:

  • ISV ‘AA’ creates a ‘app b’ that has a dependency on ‘app a’.
  • ISV ‘BB’ creates ‘app c’ that extends ‘app b’. 2 dependencies needed here (a, b).
  • ISV ‘BB’ sells ‘app c’ to a customer who then extends it even more with ‘app d’. This new app requires 3 dependencies (a, b, c).

…..look at all the apps now that have to be updated when ISV ‘AA’ releases a new version of ‘app b’? In an agile saas world, rapid small incremental releases are a reality. Is this also going to be magnified once Microsoft breaks down the main application into smaller (and perhaps dependent) apps?

Oh…in case you don’t know or don’t remember how to add dependencies to your app? It’s done in the app.json file in each app. See below for an example of what the app.json would look like in the ‘test app 1’ from the above example….

So how did I find this? As I mentioned, I’m working on a new build pipeline for our apps. My goal is that the pipeline will dynamically handle the dependencies so that it will update all of the versions in the app.json without the developer having to worry about that. After all, the build numbers are being generated from Azure DevOps so the developer is not going to know what the build numbers of the dependent apps will be. This little dependency hiccup caused a little bit of a wrench in my original plans.

More to come on the build pipeline later……..but spoiler alert…..it is working!!

Until next time…happy coding!

One thought on “Multi-level App Dependencies

  1. Hi Mike,
    A surprise to me that that’s the case, but as you say it makes some sense.
    Take a look at our fellow MVP Kamil’s VSCode/PowerShell extension does. It handles dependent apps as git submodules, they are in the VSCode workspace, but in their own repository. This way you can compile (and reversion if that’s what you want – that’s not require) both your main and test app, but also dependent apps. You find it in the VSCode Extensions, and he showed a small part of it at NavTechDays 2018.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.