Question: How is this intended to be used by software vendors?

[cjbadger]

Hi there,

Firstly, the kit is a great idea, so thank you for putting it together and making it available for makers.

I'm not entirely clear on whether, or how, the kit is intended to be used by software vendors. I note that the Use the Creator Kit guide states:

When deploying an app that includes the components, make sure the Creator Kit (managed solution) is already installed in the target environment, or explicitly include the components used in the app in the solution.

Having to install the Creator Kit (in its entirety) in a customer's environment doesn't seem ideal for a software vendor, not least of all because this will result in the installation of several unwanted/unnecessary Apps in the customer's environment (Fluent Theme Designer, etc).

I'm not entirely sure what "explicitly include the components used in the app in the solution" means here. This is presented as an alternative to installing the Kit in the target environment. My understanding is that — as the Component Library and Code Components have the "cat" publisher prefix, these cannot be included in a solution without:

• In the case of the Component Library, creating a copy of the Library in an unmanaged solution created from the release assets, publishing it with the vendor's own solution publisher and including that new Library in the solution
• In the case of the Code Components, building the components from their pcf projects, using the pac cli to pac pcf push them to the development environment with the vendor's own solution publisher prefixas set out in the Power CAT code components repository, and then including each code component in the solution.

This results in the connection between the components and their source being broken, meaning we need to watch for changes to the kit and manually update the various components ourselves from time-to-time. This seems fine for the Code Components, but a bit unwieldy for the Component Library.

Thanks for your help.

[denise-msft]

When you say software vendor, are you talking about publishing ISV solutions, or re-branding the components in your solution you are building for a customer project as a vendor? Is re-publishing the components as your vendor's publisher blocking you from developing a solution for the customer, or is it just a branding issue?

[cjbadger]

Hi Denise,

Thanks for the reply. I'm talking about publishing ISV solutions. It's not a branding issue, so much as a workflow issue, or a deployment and maintenance issue, depending on what approach we take to including the components in our solutions.

If we adopt the first approach mentioned in the Use the creator kit guide (referenced above), and "make sure the Creator Kit is already installed in the target environment" when "deploying an app that includes the components", then when a customer installs our solutions via AppSource, for example, they need to first install the Creator Kit in their environments (since I don't believe there's any way to manage first-party dependencies in the AppSource package itself). As noted in my original post, this also obviously results in the user getting a number of Apps being installed in their environment which they didn't ask for (Fluent Theme Designer, etc).

I'm not entirely sure what the alternative approach mentioned in the guide entails (" explicitly include the components used in the app in the solution"), but the only thing I can think of is set out in the last two bullet points in my original post. In that case, our components are completely orphaned from the Creator Kit, and benefiting from updates to the Creator Kit (updates to existing components/library, new components, etc) becomes a manual process.

Does that make sense?

Thanks

[scottdurow]

Hi @badger-barhead - thanks so much for your feedback and thoughts on this topic. As you say, the story for code components is quite different to the canvas components in terms of packaging in an ISV scenario, and certainly it's much easier for code components.

• For code components, if you include them in your ISV solution, to avoid namespace/publisher prefix collisions with the Creator Kit solution that your clients may want to install separately, one solution would be to fork the code component repo and then merge in updates as they are released. You can then build and deploy these do your development environment using a different publisher prefix and namespace - releasing as part of your App Source package as and when you have tested them.

• For the canvas components, you could perhaps fork this repo and merge in updates to the component library . But again you would need to ensure that the component library was re-packed (using the pac cli) inside a different solution so that you could give it a different publisher prefix. I can imagine this might be harder to main than the code component fork.

So in summary, I agree that the code components would be fairly straightforward to include in your ISV solution by forking the repo and re-namespacing, but the canvas components might be better to simply use as a template. Currently, the Spinner and Progress canvas components are candidates to be moved over to code components - and this might happen for other canvas components in the future too.

Thanks for your help again and I would love to hear any further thoughts you have on this.

[cjbadger]

Hi @scottdurow ,

Thanks very much for your reply, and for your suggestions! We've basically taken the approach you've outlined; I just wanted to make sure the kit wasn't designed with some other approach in mind which I'd missed or not considered.

My only thought would be that — while I understand that ISVs are not the primary intended users of this kit — it would be great if the ISV solution use case we've discussed (and maintaining the currency of the kit in that scenario) could be considered in future iterations of the kit.

Thanks for your help! Chris.