Why .NET-C# developers struggle with Dynamics 365 Development
--
“Practice creates the master.” — Miguel Ruiz
Experience is important for Dynamics 365 developers because with development you learn how it doesn’t work, whilst learning how it works e.g. mistakes. There is no shortcut to mastery, it takes time, hard work, learning and trial and error.
Microsoft Dynamics 365 can be illogical but you get used it, making mistakes and learning is the cost of experience.
Experience is gained by creating customisations and them not working (often in many different flavours of not working) before getting them to work. Understanding how functionality doesn’t work, helps you understand how it works.
Plugins
When a Dynamics 365 developer starts developing a plugin, he will learn the all the steps you need to take and the hoops you need to jump through
I went through some of the common problems in this blog but here is a quick recap
- setup up Dynamics Developer toolkit
- User has to be CRM Admin
- Isolation mode? if none user has to be a deployment administrator
- plugin needs to be signed
These are simple steps to create and register a plugin, that’s without even thinking about the code and if it works, testing, debugging etc.
Tools
There are lots of great tools in the XRM toolbox which everyone uses to make development easier. The XRM toolbox is the ultimate tool.
- Ribbon workbench
- Web Resource Manager
- Fetch XML Builder
- SQL 4 CDS — Dynamics 365 tool you should use — SQL 4 CDS
WHY .NET/C# struggle developing
Companies will use C# resources on Dataverse/Dynamics projects which they think they will use to do some Dynamics 365 customization.
This theory seems sound, the actual C# code in a plugin is small and simple but for a C# Developer with no Dynamics 365 experience it’s confusing with illogical rules.
