With v9 a lot of changed. One of the major changes is client
web API, some of calls were made deprecated and some were added. For example,
The new ‘Xrm.WebApi.retrieveRecord(entityLogicalName, id,
options).then(successCallback, errorCallback)’ can’t be made synchronous. But
imagine situation, in which you need to go through multiple entities (lookups).
In this scenario, you need the result of retrieved record to access the next
record. So how can this be done?
There’s no breakthrough in this blogpost… It’s just to show you how does the new .csproj look like, what basic things can be done in msbuild and how-to setup ILRepack for common data service painlessly.
System.Runtime.Serialization.SerializationException: Type is not resolved for member ‘Newtonsoft.Json.JsonSerializationException’
If you ever run into this exception without any trace available it is most likely not like it seems. Microsoft’s internal wrapper for launching CodeActivity catches it and ignores your trace log entries. So if your code throws this exception the platform treats it like internal exception. It is probably because it serializes parameters for CodeActivity into JSON and this process can produce the same exception (in Microsoft’s internal code).
Hello there, fellow power platform customizers/developers! Have you tried to override the default open behavior in subgrid and failed?
What I’ve found in my research:
Documentation by Microsoft says: “You can now create a command definition for an entity with Mscrm.OpenRecordItem as the value of the Id attribute (<CommandDefinition> (RibbonDiffXml)), and define custom action for the command <Actions> (RibbonDiffXml). Customer Engagement will look for this command Id for an entity when you try to open a record from the entity-bound grid, and if present, will execute the custom action instead of opening the entity record (default behavior).”
IMPORTANT NOTE: This feature is supported only for Unified Interface.
Finally, it’s the weekend and I have some time to focus on an issue which bothered our team for a few months. As always we wanted to do it the right way so it will be fast, reusable, continuous integration compatible and without spawning unnecessary workflows and plugin instances.
UPDATE 19/9/18: It has been fixed in 188.8.131.52 version of Plugin Registration Tool https://www.nuget.org/packages/Microsoft.CrmSdk.XrmTooling.PluginRegistrationTool/184.108.40.206
If you use 9.0 version of Plugin Registration Tool to update your assemblies in Dynamics 365 you may encounter the following exception:
ERROR: Occurred while checking whether the assembly exists
The PluginType(00000000-0000-0000-0000-000000000000) component cannot be deleted because it is referenced by 1 other components. For a list of referenced components, use the RetrieveDependenciesForDeleteRequest.
The import of the solution XYZ failed. The following components are missing in your system and are not included in the solution. Import the managed solutions that contain these components (Active) and then try importing this solution again.
If you ever run into this exception and there are all the components already present in the environment you just need to get rid of few lines in a solution definition in the ZIP file you are trying to import.
Do this only if you are absolutely sure that you know what you are doing.
In previous article, we have looked at the possibility to connect Dynamics 365 on-premise directly with Azure AD, which is on one hand really cool, on the other, it doesn’t provide all the features like mobile apps integration. In this article, we are going to explore a production ready solution by leveraging Active Directory Federation Service and Azure AD as a Claims Provider Trust.