We've encountered quite a significant issue with 2013 SP1 UR1 with solutions containing custom actions.
Prior to SP1 UR1, when custom actions were exported as part of a solution, the SDKMessageId for the custom action wasn't included in the solution export, which resulted in a new SDKMessageId being created during solution installation. This caused a cascade issue if there were plugin steps attached to the custom action as the step only contains the sdkmessageid it needs to be attached to.
In SP1 UR1, the export for the custom action now contains the SdkMessageId which would allow the above situation to work on a new SP1 UR1 org, however if the custom action already exists, but the SdkMessageId's differ, the solution import will fail.
The repro steps for this are quite easy:-
- Create 2 orgs on a SP1 environment (Dev and Test). It can be any version of CRM prior to SP1 UR1.
- On the Dev org, Create a Solution and add a custom action to the solution, it doesn't matter what the custom action is attached to, or what the custom action does.
- Export the solution from dev managed and import onto the test org. This will import successfully.
- Update the 2 orgs to SP1 UR1.
- Re-export the solution from dev managed and import to the test org.
The import will fail with an error like "Expected to find one SdkMessageFilter for SdkMessageId ac3b08d3-88e1-e311-93ff-00155d003014, PrimaryEntity 2 and SecondaryEntity 0. Found 0 records"
This is a very contrived example, but very easy to come up with real world examples on how this would occur.
For anybody in Microsoft, I went through a support ticket for the original issue on plugin steps on plugins (REG:114060411497815) which support are telling me to raise another support case for this new issue (in my opinion it's one and the same issue, we cannot import solutions containing custom actions and steps, but now import of custom actions is completely broken) not seeing the criticality of this issue with SP1 UR1.