cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Dlabar
Most Valuable Professional
Most Valuable Professional

Plugin Class/Assembly Management/Organization for ALM

In most projected with Dataverse Plugins, there will be a need for more than one plugin.  This brings up challenges for how to organize the classes/assemblies, and normally will result in having to strike a balance between maximizing plugin deployment segregation, (A single plugin class per plugin assembly) and ease of deployment/visual studio project management (All plugins in a single assembly).   The former allows for easily managing what plugins are being updated, and the later simplifies ALM process, since only one plugin registration is required.

 

When dealing with automating ALM plugin updates/registrations, I'm assuming that it makes most since to have a single plugin assembly.  Is this assumption correct?  Why or why not?  Are there other conventions that are used?

1 ACCEPTED SOLUTION

Accepted Solutions
KimB
Advocate II
Advocate II

We are using the same approach: one plugin project per solution.

 

We use namespaces to further structure the plugin classes. One plugin class has one defined functionality, making it easier to unit test, disable or remove steps or the class later.

 

For ALM, we use solution packager and the mapping functionality to extract DLL from the unpacked solution and inject the build result after packing.

 

Consider this article as well: https://docs.microsoft.com/en-us/powerapps/developer/data-platform/best-practices/business-logic/opt...

 

View solution in original post

9 REPLIES 9
ScottDurow
Memorable Member
Memorable Member

Having multiple plugin assemblies only makes it more complex because you have to build them all and copy to the package folder in your build pipeline. I generally have a single plugin assembly per solution - if I am segmenting the solutions then I will have a plugin assembly per solution (if needed) and build/version/release them separately.

KimB
Advocate II
Advocate II

We are using the same approach: one plugin project per solution.

 

We use namespaces to further structure the plugin classes. One plugin class has one defined functionality, making it easier to unit test, disable or remove steps or the class later.

 

For ALM, we use solution packager and the mapping functionality to extract DLL from the unpacked solution and inject the build result after packing.

 

Consider this article as well: https://docs.microsoft.com/en-us/powerapps/developer/data-platform/best-practices/business-logic/opt...

 

DianaBirkelbach
Most Valuable Professional
Most Valuable Professional

Hi @ScottDurow , @KimB ,

We actually have one pluginproject  pro entity/process., because usually they are developed by different developers. We have unit tests, but that's not a replacement for real tests. Do you have dedicated environments pro developer? Otherwise could be hard to test in the same time, given a single assembly,
I know it's recommended to have dedicated environments pro developer, but it's quite an overhead, and would be interesting to hear abour your experience.

Kind regards,

Diana 

Kind regards,
Diana
----------
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."
ScottDurow
Memorable Member
Memorable Member

@DianaBirkelbach I think you are referring to the challenge that when two or more developers are updating the same plugin assembly and deploying it to the same environment then they can overwrite one another's changes. This of course is not just an issue for Plugins (it happens for Flows, Canvas Apps etc.) but as the size of your Plugin grows, then there is more likely to be a collision. Even if you are using feature flags (which I recommend), this still doesn't solve this issue since it's a deployment collision of different local versions.

It certainly is an important consideration - I find that it's more flexible to decide how my solution/plugins are versioned/deployed separately to how they are being developed. I don't want to end up with multiple Plugin Assemblies simply because two developers were working on a Plugin at the same time. And even if you segment your Plugin Assemblies by Entity - you can end up with the same problem (but perhaps less frequently).

 

The strategies I take to address this challenge are:

 

1. Multiple environments per feature being developed - then leave it up to the feature pod to decide on how they manage concurrent development so that they don't interfere with each other. Since the feature pod usually only consists of a smaller number of developers and they are isolated from other parallel work in their own branch/environment I find this works well. The changes are only then integrated into the build when the branch is merged.

 

2. Test Locally before Deployment and Integration - Create Integration tests to run your plugins against an Environment to test your work locally (using a Mock Pipeline connected with a real OrganizationService) before it is integrated into the development environment. There would be someone (or ideally a nightly build/deploy process) in the pod that is responsible for building and deploying to the development environment. The developers who worked on the Plugins should have a high degree of confidence that their plugin logic works since they've tested it locally against the Dataverse environment.

 

3. Develop in temporary Plugin Assemblies - If you know that you are likely to collide with some other development (and you really should know what's happening in the environment you are developing against at all times - if you don't then there is a whole different problem!) - you can develop and deploy your plugin code separately to the solution Plugin Assembly to test it during development - once you are happy, you delete the development version and integrate the code into the main solution Plugin and commit it so it can be built and deployed when the pod is ready. 

 

I've used all of these techniques (often in combination) and they work well - and mean you don't have to change your ALM solution deployment strategy to accommodate the way that developers are working and the parallel work that is being performed.

 

The most important here is communication between all developers so that everyone who is working on the same Development Environment knows what is being worked on any by who - daily stand-ups make this easy.

 

Hope this helps!

 

DianaBirkelbach
Most Valuable Professional
Most Valuable Professional

Thank you so much @ScottDurow  for taking the time to share your experience and thank you @Dlabar for bringing this up!

I'm somewhere in between all this, still looking for the perfect world.🤔

 

1. Multiple dev environments are the perfect world indeed, but this means an overhead in continuous syncing the customizing  and test data from main "dev" environment, where the consultants, solution architects and sometimes the customers are making the customizing.

 

2. So you trust a mocked integration test, without deploying and testing the registration, definition of filtered attributes and images, the interaction with  other plugins (even the plugins on another entity could lead to a ping-pong effect). I wish I could have the confidence. Maybe it's because in the big projects, as a dev,  I don't know everything what's happening (or because I'm too much of a control freak 😁  )

 

3. This idea of temporary assembly is interesting. Do you keep the temporary project for later, in case a change request will come later on? Do you make the plugin based on some kind of shared projects?

 

Definitely a lot of ideas to have a second thought. Thank you again, Scott! 

 

Kind regards,

Diana

 

Kind regards,
Diana
----------
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."

I usually go with the same approach as @DianaBirkelbach does. I create an Assembly per Entity/Table.

 

My reason for that is not mainly that different developers could override their changes.

Which as mentioned could be a problem, but a problem that could be fixed as @ScottDurow explained.

My main reason is to have my solution manageable. If you have a big implementation with hundreds of plugins and all of them are in the same assembly it gets hard to deploy plugins. That's because there are always changes in some plugin that weren't tested by the customer. Of course one could (and maybe should) use feature flags. But even then you changed the code which should be tested by the users. 

Dlabar
Most Valuable Professional
Most Valuable Professional

I thought you had a single plugin assembly per solution?

No, I usually split them by Table.

nicknow
Advocate II
Advocate II

One ideas, to build on @ScottDurow's suggestion of a temporary  assembly is to use Shared Projects in your solution and then have multiple projects referencing the shared project to generate different DLL outputs (for production vs local dev solutions.) This also helps solve @BenediktB's concern about feature flags (something I agree with Scott about using) and untested code.

 

You can divide it up by table or functional area or developer or whatever makes sense for your project.

 

But the result is the same. You have a shared project in VS that contains the plugin code itself. Then you have two shared projects that reference that plugin code. One, call it tester, only references a single shared project (could be more than one depending on the dev strategy, but less than all of them.) The other, call it production, references all the shared projects - resulting in a single DLL output (because shared projects result in the code being incorporated into the build instead of generating individual DLLs.)

 

This is how it looks in VS (there are three different solutions):

 

MyProject.Account [Solution]
-> MyProject.Account [Shared Project]
-> MyProject.Account.Dev [tester] (Reference: MyProject.Account)

 

MyProject.Contact [Solution]
-> MyProject.Contact [Shared Project]
-> MyProject.Contact.Dev [tester] (Reference: MyProject.Contact)

 

MyProject [Solution]
-> MyProject.Plugins [Production] (Reference: MyProject.Account, MyProject.Contact)


When I build MyProject.Account, as a developer, I get just those plugins in a DLL, MyProject.Account.DLL, and can test them all I want locally. And if I have a single environment for dev testing I can test them in that environment without impacting other developers. (same goes for MyProject.Contact).

 

Now, when you get to a production build and test (automated or not) I build MyProject and get just one DLL, MyProject.Plugins.DLL.

 

Shared projects also work great for common functionality across multiple plugin DLLs (whether for the same project or for different projects you have going on.)

 

Plus, because each project is its own Git repository you can have branches, only building from the production branches for the production DLL output, but using a dev branch for tester DLL output.

 

Shared projects are an underutilized capability for plugin development, assuming you don't want to use ILMerge/ILRepack (which are not officially supported by Microsoft for plugin development.)

Helpful resources

Announcements

Community will be READ ONLY July 16th, 5p PDT -July 22nd

Dear Community Members,   We'd like to let you know of an upcoming change to the community platform: starting July 16th, the platform will transition to a READ ONLY mode until July 22nd.   During this period, members will not be able to Kudo, Comment, or Reply to any posts.   On July 22nd, please be on the lookout for a message sent to the email address registered on your community profile. This email is crucial as it will contain your unique code and link to register for the new platform encompassing all of the communities.   What to Expect in the New Community: A more unified experience where all products, including Power Apps, Power Automate, Copilot Studio, and Power Pages, will be accessible from one community.Community Blogs that you can syndicate and link to for automatic updates. We appreciate your understanding and cooperation during this transition. Stay tuned for the exciting new features and a seamless community experience ahead!

Check Out | 2024 Release Wave 2 Plans for Microsoft Dynamics 365 and Microsoft Power Platform

On July 16, 2024, we published the 2024 release wave 2 plans for Microsoft Dynamics 365 and Microsoft Power Platform. These plans are a compilation of the new capabilities planned to be released between October 2024 to March 2025. This release introduces a wealth of new features designed to enhance customer understanding and improve overall user experience, showcasing our dedication to driving digital transformation for our customers and partners.    The upcoming wave is centered around utilizing advanced AI and Microsoft Copilot technologies to enhance user productivity and streamline operations across diverse business applications. These enhancements include intelligent automation, AI-powered insights, and immersive user experiences that are designed to break down barriers between data, insights, and individuals. Watch a summary of the release highlights.    Discover the latest features that empower organizations to operate more efficiently and adaptively. From AI-driven sales insights and customer service enhancements to predictive analytics in supply chain management and autonomous financial processes, the new capabilities enable businesses to proactively address challenges and capitalize on opportunities.    

Summer of Solutions | Week 3 Results | Win free tickets to the Power Platform Conference

We are excited to announce the Summer of Solutions Challenge!   This challenge is kicking off on Monday, June 17th and will run for (4) weeks.  The challenge is open to all Power Platform (Power Apps, Power Automate, Copilot Studio & Power Pages) community members. We invite you to participate in a quest to provide solutions in the Forums to as many questions as you can. Answers can be provided in all the communities.    Entry Period: This Challenge will consist of four weekly Entry Periods as follows (each an “Entry Period”)   - 12:00 a.m. PT on June 17, 2024 – 11:59 p.m. PT on June 23, 2024 - 12:00 a.m. PT on June 24, 2024 – 11:59 p.m. PT on June 30, 2024 - 12:00 a.m. PT on July 1, 2024 – 11:59 p.m. PT on July 7, 2024 - 12:00 a.m. PT on July 8, 2024 – 11:59 p.m. PT on July 14, 2024   Entries will be eligible for the Entry Period in which they are received and will not carryover to subsequent weekly entry periods.  You must enter into each weekly Entry Period separately.   How to Enter: We invite you to participate in a quest to provide "Accepted Solutions" to as many questions as you can. Answers can be provided in all the communities. Users must provide a solution which can be an “Accepted Solution” in the Forums in all of the communities and there are no limits to the number of “Accepted Solutions” that a member can provide for entries in this challenge, but each entry must be substantially unique and different.    Winner Selection and Prizes: At the end of each week, we will list the top ten (10) Community users which will consist of: 5 Community Members & 5 Super Users and they will advance to the final drawing. We will post each week in the News & Announcements the top 10 Solution providers.  At the end of the challenge, we will add all of the top 10 weekly names and enter them into a random drawing.  Then we will randomly select ten (10) winners (5 Community Members & 5 Super Users) from among all eligible entrants received across all weekly Entry Periods to receive the prize listed below. If a winner declines, we will draw again at random for the next winner.  A user will only be able to win once overall. If they are drawn multiple times, another user will be drawn at random.  Individuals will be contacted before the announcement with the opportunity to claim or deny the prize.  Once all of the winners have been notified, we will post in the News & Announcements of each community with the list of winners.   Each winner will receive one (1) Pass to the Power Platform Conference in Las Vegas, Sep. 18-20, 2024 ($1800 value). NOTE: Prize is for conference attendance only and any other costs such as airfare, lodging, transportation, and food are the sole responsibility of the winner. Tickets are not transferable to any other party or to next year’s event.   ** PLEASE SEE THE ATTACHED RULES for this CHALLENGE**   Week 1 Results: Congratulations to the Week 1 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Community MembersNumber of SolutionsSuper UsersNumber of Solutions @anandm08  23 @WarrenBelz  31 @DBO_DV  10 @Amik  19 AmínAA 6 @mmbr1606  12 @rzuber  4 @happyume  7 @Giraldoj  3@ANB 6 (tie)   @SpongYe  6 (tie)     Week 2 Results: Congratulations to the Week 2 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Community MembersSolutionsSuper UsersSolutions @anandm08  10@WarrenBelz 25 @DBO_DV  6@mmbr1606 14 @AmínAA 4 @Amik  12 @royg  3 @ANB  10 @AllanDeCastro  2 @SunilPashikanti  5 @Michaelfp  2 @FLMike  5 @eduardo_izzo  2   Meekou 2   @rzuber  2   @Velegandla  2     @PowerPlatform-P  2   @Micaiah  2     Week 3 Results: Congratulations to the Week 3 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge.   Week 3:Community MembersSolutionsSuper UsersSolutionsPower Apps anandm0861WarrenBelz86DBO_DV25Amik66Michaelfp13mmbr160647Giraldoj13FLMike31AmínAA13SpongYe27  

Updates to Transitions in the Power Platform Communities

We're embarking on a journey to enhance your experience by transitioning to a new community platform. Our team has been diligently working to create a fresh community site, leveraging the very Dynamics 365 and Power Platform tools our community advocates for.  We started this journey with transitioning Copilot Studio forums and blogs in June. The move marks the beginning of a new chapter, and we're eager for you to be a part of it. The rest of the Power Platform product sites will be moving over this summer.   Stay tuned for more updates as we get closer to the launch. We can't wait to welcome you to our new community space, designed with you in mind. Let's connect, learn, and grow together.   Here's to new beginnings and endless possibilities!   If you have any questions, observations or concerns throughout this process please go to https://aka.ms/PPCommSupport.   To stay up to date on the latest details of this migration and other important Community updates subscribe to our News and Announcements forums: Copilot Studio, Power Apps, Power Automate, Power Pages

Top Solution Authors
Users online (4,333)