Facing Issue while importing manage solution using new PCF CLI

(0) Share

Report

Posted on by Sheldon Copper

200

Hi,

I have followed the steps which were given to import PCF Control using new CLI "pac pcf push --publisher-prefix " , but getting the following error

Error: Import Solution Failed: CustomControl with name Rooh.RecordPreview failed to import with error: CustomControls with Name Rooh.RecordPreview Import Solution Failed with following error: Custom Control with name Rooh.RecordPreview already created by another publisher. Please change your control's name and try importing again

The organization had solution which was build using by earlier CLI version - 0.2.71, we deleted the older CLI solution but still got the same error

When I checked in custom controls metadata the manifest file was still there in custom control metadata, I tried to delete the metadata using POSTMAN Request,but was unable to delete

{

"error": {

"code": "0x8004f032",

"message": "The 'Delete' operation on the current component(name='WebResource', id='6afa6373-156b-4f9c-865d-dbf6f484fab4') failed during managed property evaluation of condition: 'Managed Property Name: iscomponentdeletionenabled; Component Name: WebResource; '",

"innererror": {

"type": "System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=9.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]",

"stacktrace": " at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.Delete(EntityReference entityReference, InvocationContext invocationContext, CallerOriginToken callerOriginToken, WebServiceType serviceType, Boolean checkAdminMode, Boolean checkOptimisticConcurrency, Dictionary`2 optionalParameters)\r\n at Microsoft.Crm.Extensibility.OData.CrmODataExecutionContext.Delete(EntityReference entityReference, Boolean checkForOptimisticConcurrency)\r\n at Microsoft.Crm.Extensibility.OData.EntityController.DeleteEntityImplementation(String& entityName, String key)\r\n at Microsoft.PowerApps.CoreFramework.ActivityLoggerExtensions.Execute[TResult](ILogger logger, EventId eventId, ActivityType activityType, Func`1 func, IEnumerable`1 additionalCustomProperties)\r\n at Microsoft.Xrm.Telemetry.XrmTelemetryExtensions.Execute[TResult](ILogger logger, XrmTelemetryActivityType activityType, Func`1 func)\r\n at lambda_method(Closure , Object , Object[] )\r\n at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass10.<GetExecutor>b__9(Object instance, Object[] methodParameters)\r\n at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__0.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__2.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__1.MoveNext()"

}

Since it was managed solution should this component not have been deleted when I deleted managed solution?

Categories:

Power Apps Pro Dev & ISV

I have the same question (0)

All responses (6)

Answers (0)

namohant Microsoft Employee on at

Like (0)

Report
Copy link

Link copied!

We are looking into the issue. Will share an update as soon as possible.

-Nando

Was this reply helpful? Yes No
liun 48 on at

Like (0)

Report
Copy link

Link copied!

@namohant
This seems related to the issue reported in the "new tooling" thread that the new build tool will add the prefix as part of the control name, while the old control has a different name but same guid.
I feel the addition of prefix during build is unecessary because the namespace should already tookcare that, and it cause huge pain if the PCF is already used on many forms. Now we have to remove them, delete old one, and re-add back to all forms.

Was this reply helpful? Yes No
Hemant Gaur Microsoft Employee on at

Like (1)

Report
Copy link

Link copied!

Fair point Lium. I apologize for this suboptimal experience and we are activity looking into how this can be handled better.

One thing which I would like to call out is that lot of design and engineering effort had gone into making PCF much more robust and scaleable as we release it as GA. This change is also part of those internal feature investments and we will share more details soon.

One core reason for PCF to be still in preview is to have that flexibility of making breaking changes now as opposed to production. We try hard not to do it but that's the price we pay for making bits available early as preview.

Again feedback and any inputs are highly appreciated and we will continue to learn and improve.

Regards,
Hemant

Was this reply helpful? Yes No
liun 48 on at

Like (1)

Report
Copy link

Link copied!
@HemantG Thanks for the explaination. Understood.

With the addition of publisher prefix to the begining of root namespace, it seems introduced some inconsistency in the metadata:

The solution.zip\customization.xml will display the custom control name with prefix, and folder name will have prefix:
<CustomControl> <Name>myprefix_MyRootNameSpace.SecondLevelNS.MyControl</Name> <FileName>/Controls/myprefix_MyRootNameSpace.SecondLevelNS.MyControl/ControlManifest.xml</FileName> </CustomControl>
but the actual manifest still declare the namespace without prefix:
<manifest> <control constructor="MyControl" namespace="MyRootNameSpace.SecondLevelNS">
It could create some confusion because in general, the string before the first dot is the root namespace, and the publisher prefix maybe just same as the root namespace (using organization name). In our case. it became meck_meck.pcf.ImageControl.

My feedbak is letting namespace handle the differences between same control name from different publisher, without adding prefix in build process.

Thanks

Was this reply helpful? Yes No
hansgfixed 37 on at

Like (0)

Report
Copy link

Link copied!

Any workaround? Considering that pa component framework is still in preview no one can assure me there won't be any breaking changes again when I now update all pcfs, remove them from the orgs, re-import and set them up.

Was this reply helpful? Yes No
Hemant Gaur Microsoft Employee on at

Like (1)

Report
Copy link

Link copied!

Framework was declared GA last week, check out https://aka.ms/PCFBlog

Hemant

Was this reply helpful? Yes No