Export solution containing components from another managed solution

[prathyoo]

Hi,

We built a canvas ap using custom controls (code components) from the creator kit (Creator Kit - overview (preview) - Power Platform | Microsoft Learn). The Creator Kit was installed as a managed component in our Dev Environment. We added the Canvas App to an unmanaged environment and we wanted to migrate this to our UAT environment. So, instead of having to also import the Creator Kit solution to the UAT, we added the custom controls that we used from the creator kit to our unmanaged solution.

But, when we exported this solution as a managed solution and imported the same to our UAT, we noticed that the custom controls were not included in the solution. Interestingly the app still worked. Is this how it works? When we imported the solution to UAT, it did not contain the components from the creator kit - 

We checked the zip and that too did not list the custom controls

[cchannon]

This sounded totally wrong to me, so I did a check in one of my own environments and the results were fun! Check my test below to see if I missed anything:

I have some custom controls I made myself and brought into a separate Dev env through a managed solution. I then created a new Unmanaged solution in that target Dev env and added one of those custom controls from the managed import. I then exported (as managed) that new solution containing nothing but the custom control. Then, I imported that (new) managed solution into a third environ which did not contain any of the managed or unmanaged customizations from the previous two environs.

What I found was that it (surprisingly) did let me export that solution and (also surprisingly) let me import it again. But... the solution didn't actually contain anything at all because there were no unmanaged customizations to the custom control itself, so there was nothing to put into the customizations xml. This is fascinating because custom controls are just a code bundle and can't have unmanaged customizations, so it seems that once they get bundled as managed, these may indeed be the only solution component that can be rendered non-recoverable (neat!)

...but wait, we added that thing to a solution, isn't it supposed to come across in the solution? Actually, no. We added a reference to a component that is from a managed solution. If this were more than just an atomic test (for example, if we'd added the control to an unmanaged form in our solution) then we would get a missing component ref in Solution.xml that listed the managed solution that control was supposed to come from. That missing component ref is what is supposed to tell the target env to reject the import because it doesn't have the right managed solution.

...but wait, wasn't the original problem that this dependency was from an unmanaged customization? Yeah, that is weird--and a bug--for sure, but it is not the only solution component dependency tracking problem I have seen with custom controls. For example, as recently as a couple months ago I was still able to delete custom controls from an environ even when a form still had dependencies on it (haven't tested recently) which is a HUGE problem for the form XML.💥

...But wait... @prathyoo said "Interestingly the app still worked" so what gives? This still seems totally wrong to me and in my testing I have to insist it is wrong. When you bundle up the unmanaged solution in this way it DOES NOT carry the solution customizations that define a custom control, so there is no way it could possibly migrate a custom control from one env to another. Check out this screenshot from my test when inspecting the solution zip - note there is no Controls folder in this zip at all. 

Now look at this zip from the original managed solution - note the Controls folder where all the PCF definitions are stored:

Now... I guess it is possible that the creator kit (as a first party solution) is somehow unique here and it doesn't need to move that way but I HIGHLY doubt that... so much so that I don't think it's worth the time to even test it. Far, far, far more likely is that someone just imported that solution without telling you, @prathyoo ...did you check your solution histories in the target env?

[prathyoo]

Hi,

Thank you so much for testing this out. I own both the environments and checked the second environment again and it does not contain the custom controls. I checked the "Default Solution". In the dev environment, when I try to edit the app, it lets me know that the app uses the following code components - 

In the UAT environment, I am able to click edit on the canvas app (from outside the solution) and it gives the following error -

But, when I play the app, I can see the code components in action. Example, the progress bar indicator -

Thanks

[prathyoo]

@cchannon  - Interestingly, my canvas app had both code components and library components. the library components where from a library "Power CAT Component Library". Now, when I checked the required objects for the app it showed this component library but none of the code components. Now, again with the issue above, when I tried to add this component library into my unmanaged solution, it wouldn't export out this managed component library. And when trying to import into UAT, the import failed with the dependency. At least, for this the solution was to convert the library components to local app level components and hence remove any dependency on this library.

As an aside - Even though this component library was part of a managed solution, I could still edit the component library if I accessed the library from the "Default Solutions". 

[cchannon]

I think this is a really cool gap you've found here. Obviously the correct answer for you is to make sure going forward that you actually install the Creator Kit before you bring in your own solution, but this gap should also get filled.

@HemantG - Seems like a really interesting issue with PCF dependency tracking here. I figure your team would probably want to know.