Import Error with PCF Control

[eauerbach]

I created a PCF control, imported and configured in our sandbox, and am trying to move it to production. Exporting is fine, but on import, I get the following error:

Microsoft.Crm.CrmException: CustomControls with Name ValTech.PCFControls.CheckBoxWTime Import Solution Failed with following error: Publisher prefix vtd for this control ValTech.PCFControls.CheckBoxWTime does not match the prefix e8s for the solution with Id 8dd9ac01-31db-e911-a96b-000d3a124c2c.

I've tried importing the PCF on its own and leaving it to the solution import, but both ways throw this error. How can I get the control imported for production use?

[namohant]

Hi @eauerbach ,

Can you please provide us the sandbox org and prod org details so that we can check the issue here? Also it would be helpful if you can provide the solution exported if that is feasible I can provide a share location in such case. 

Regards

Nando

[eauerbach]

Hello @namohant ,

Production org id is org5a335708 (a328a87b-31f4-49c6-90bd-db5a1ee39d15)

Sandbox org id is org28957410 (a5b3fd3b-7f72-4667-a626-bc357770de05)

The PCF control solution is "PCPSelectorControl" and the full solution is called "Phase 2". I can provide the zip file if the information provided isn't enough.

[ben-thompson]

I've been caught out by this multiple times now.

The publisher prefix (in my case usually hdn) you use to publish / push your component needs to be the same as the publisher prefix of the (managed or unmanaged) "transfer" solution that contains your published custom control.

In your case you need to either

1) change the publisher of the "phase 2"

8dd9ac01-31db-e911-a96b-000d3a124c2c

solution to be a publisher with a vtd prefix or if the e8s prefix is essential

2) remove the custom control from the "phase 2" solution (you can keep the references on the forms, it's just the control you need to move) create another managed solution which has a publisher using the vtd prefix and import that custom control solution first before importing the "phase 2" solution that needs the control.

By the way I'm currently keeping custom controls in their own solution at the moment - it avoids the 3 annoying solution checker errors every control still generates. 

[eauerbach]

@ben-thompson Does your comment apply when both solutions are unmanaged? I'm not opposed to renaming the objects, but I'm curious about why the prefix check is in place.

[ben-thompson]

Yes - I've just tested it with an unmanaged solution and the same error message occurs if the components have a different publisher prefix to the prefix in the solution.

I will edit my original response so that the answer is all in one place.

[eauerbach]

Hi @ben-thompson ,

Going with your second suggestion, to confirm the steps:

1. In Sandbox solution for Phase 2, remove the Custom Controls reference to the PCF control
2. Export Phase 2
3. In production, import the PCF control solution
4. In production, import Phase 2
5. Re-associate the control reference in Custom Controls

Is that correct? I would note that I get an error if I try to delete the reference I get an error due to the form dependencies where it's being used.

[ben-thompson]

Not quite.

1) remove the just the reference to custom control from the phase 2  solution 

2) export the phase 2 solution

3) import the PCF solution to the production environment 

4) import the phase 2 solution to production

if step 4 works you won’t need to re-associate the control on the form as that link will just work

[MikeHuguet]

@ben-thompson can you provide more details on this? What are the issues and can you provide me with samples so it can be addressed, if it is feasible?

"By the way I'm currently keeping custom controls in their own solution at the moment - it avoids the 3 annoying solution checker errors every control still generates. "

[ben-thompson]

@MikeHuguet For none published controls I see the following error messages (see attached solution checker that has 3 controls all with the same 3 errors).

web-avoid-eval
High
Security
Web Resources
Usage of the JavaScript eval function should be limited where possible. The eval function can be a dangerous function as it allows strings to be executed as scripts within the context of the caller. This can be exploited to run malicious code. Eval is also usually slower than other options due to the lack of optimizations of the script text passed to eval.
web-use-strict-equality-operators
Medium
Usage
Web Resources
For most comparisons the strict equality comparison algorithm is the appropriate choice as it will return the expected results. The strict operators handle null and undefined values as expected.
web-use-strict-mode
Medium
Usage
Web Resources
Strict mode is a way to introduce better error-checking into your code. Code should run in strict mode wherever possible.

Now I know we don't get those errors if I build the controls in release mode as all 3 errors relate to the wrapper code around the component when it's in debug mode but that means you need to manage the transfer of additional managed solutions around as a managed component comes in a managed solution so you can't just add the component to the final solution. 

Which remind me I must write up notes on how to compile a component for release as the standard documentation approach of create a solution called Solution doesn't work when you may have different combinations of solutions you wish to offer people.