Monthly Archives: April 2022

How to: debug plugins in the shared environments

When debugging a plugin, I often use PluginExecutionExceptions to display debugging messages. But, of course, it all works great when my development environment (or the plugin) is relatively isolated. And it all falls apart when there are other people working in the same environment, and they suddenly start seeing those error messages.

image

There is a simple workaround, though. Basically, I want to see those error messages, but I don’t want anyone else to be affected by them, so I just need to make sure they will be displayed for my user id. Which is easy to do with the help of the function below:

public static void ThrowDebuggingError(IPluginExecutionContext context, string msg, string userId)
{
   if (context.InitiatingUserId == new Guid(userId))
   {
      throw new InvalidPluginExecutionException(msg);
   }
}

With this in place, I can now call ThrowDebuggingError, pass plugin context, message, and my userId, and that error will only be displayed when the plugin has been initiated by me.

It’s worth noting that “context.InitiatingUserId” might work better than “context.UserId” in the code above, since InitiatingUserId woud correspond to my user account id even if the plugin is configured to run in the context of the “System” (or other) user account.

Power Platform /Dataverse development vs Classic Development – what’s the problem?

The question of setting up a branching strategy when doing development in Dataverse comes up almost inevitably. It’s a discussion that happens at a certain point, and it can be happening on the same project a number of times as people are joining the project.

Would probably make sense to explain why we are having this issue (and, as to “whether we have a good solution”, I think it depends on the project requirements).

The first diagram below shows your classic project where every developer would have their own “workstation” to do development, and they would have their local execution environment on those workstations.

Once the changes are ready, they would be pushed into git, and, from there, they would go to the QA/UAT/Prod environments.

This also allows for branching, for instance, since every developer can work on their own branch in git. After all, there is separate execution environment per developer in this scenario, and that’s important since every developer can maintain their own execution environment.

image

However, once we have switched to Dataverse / Power Platform, it all becomes different. Every developer would still have a workstation, but they might now be sharing the execution environment:

image

Which makes branching in git nearly impossible. So, of course, you might try changing it a little more. Why don’t we have a power platform/dataverse environment per developer?

image

This may work better, but you’ll have to figure out the source control, since you won’t be making “code” changes in those individual development environments – you’ll be making configuration and customization changes, and this is all supposed to be transported through the dataverse solutions.

Which are still far from perfect when it comes to branching and merging support in git, and, more often than not, that last mile between local development environments and git will have to be covered by manually re-implementing changes in some kind of “integration environment”:

image

That’s when you may finally have a somewhat similar setup (similar to the classic development), but this involves a few more power platform environments now, and this also involves that manual/semi-manual step of pushing ready-to-deploy changes to the “integration”.