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."
BenediktB
Advocate II
Advocate II

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

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

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 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**

Celebrating the June Super User of the Month: Markus Franz

Markus Franz is a phenomenal contributor to the Power Apps Community. Super Users like Markus inspire others through their example, encouragement, and active participation.    The Why: "I do this to help others achieve what they are trying to do. As a total beginner back then without IT background I know how overwhelming things can be, so I decided to jump in and help others. I also do this to keep progressing and learning myself." Thank you, Markus Franz, for your outstanding work! Keep inspiring others and making a difference in the community! 🎉  Keep up the fantastic work! 👏👏   Markus Franz | LinkedIn  Power Apps: mmbr1606  

Copilot Cookbook Challenge | Week 1 Results | Win Tickets to the Power Platform Conference

We are excited to announce the "The Copilot Cookbook Community Challenge is a great way to showcase your creativity and connect with others. Plus, you could win tickets to the Power Platform Community Conference in Las Vegas in September 2024 as an amazing bonus.   Two ways to enter: 1. Copilot Studio Cookbook Gallery: https://aka.ms/CS_Copilot_Cookbook_Challenge 2. Power Apps Copilot Cookbook Gallery: https://aka.ms/PA_Copilot_Cookbook_Challenge   There will be 5 chances to qualify for the final drawing: Early Bird Entries: March 1 - June 2Week 1: June 3 - June 9Week 2: June 10 - June 16Week 3: June 17 - June 23Week 4: June 24 - June 30     At the end of each week, we will draw 5 random names from every user who has posted a qualifying Copilot Studio template, sample or demo in the Copilot Studio Cookbook or a qualifying Power Apps Copilot sample or demo in the Power Apps Copilot Cookbook. Users who are not drawn in a given week will be added to the pool for the next week. Users can qualify more than once, but no more than once per week. Four winners will be drawn at random from the total qualifying entrants. If a winner declines, we will draw again at random for the next winner.  A user will only be able to win once. If they are drawn multiple times, another user will be drawn at random. Prizes:  One Pass to the Power Platform Conference in Las Vegas, Sep. 18-20, 2024 ($1800 value, does not include travel, lodging, or any other expenses) Winners are also eligible to do a 10-minute presentation of their demo or solution in a community solutions showcase at the event. To qualify for the drawing, templates, samples or demos must be related to Copilot Studio or a Copilot feature of Power Apps, Power Automate, or Power Pages, and must demonstrate or solve a complete unique and useful business or technical problem. Power Automate and Power Pagers posts should be added to the Power Apps Cookbook. Final determination of qualifying entries is at the sole discretion of Microsoft. Weekly updates and the Final random winners will be posted in the News & Announcements section in the communities on July 29th, 2024. Did you submit entries early?  Early Bird Entries March 1 - June 2:  If you posted something in the "early bird" time frame complete this form: https://aka.ms/Copilot_Challenge_EarlyBirds if you would like to be entered in the 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. Copilot Cookbook Gallery:Power Apps Cookbook Gallery:1.  @Mathieu_Paris 1.   @SpongYe 2.  @Dhanush 2.   @Deenuji 3.  n/a3.   @Nived_Nambiar  4.  n/a4.   @ManishSolanki 5.  n/a5.    n/a

Your Moment to Shine: 2024 PPCC’s Got Power Awards Show

For the third year, we invite you, our talented community members, to participate in the grand 2024 Power Platform Community Conference's Got Power Awards. This event is your opportunity to showcase solutions that make a significant business impact, highlight extensive use of Power Platform products, demonstrate good governance, or tell an inspirational story. Share your success stories, inspire your peers, and show off some hidden talents.  This is your time to shine and bring your creations into the spotlight!  Make your mark, inspire others and leave a lasting impression. Sign up today for a chance to showcase your solution and win the coveted 2024 PPCC’s Got Power Award. This year we have three categories for you to participate in: Technical Solution Demo, Storytelling, and Hidden Talent.      The Technical solution demo category showcases your applications, automated workflows, copilot agentic experiences, web pages, AI capabilities, dashboards, and/or more. We want to see your most impactful Power Platform solutions!  The Storytelling category is where you can share your inspiring story, and the Hidden Talent category is where your talents (such as singing, dancing, jump roping, etc.) can shine! Submission Details:  Fill out the submission form https://aka.ms/PPCCGotPowerSignup by July 12th with details and a 2–5-minute video showcasing your Solution impact. (Please let us know you're coming to PPCC, too!)After review by a panel of Microsoft judges, the top storytellers will be invited to present a virtual demo presentation to the judges during early August. You’ll be notified soon after if you have been selected as a finalist to share your story live at PPCC’s Got Power!  The live show will feature the solution demos and storytelling talents of the top contestants, winner announcements, and the opportunity to network with your community.  It's not just a showcase for technical talent and storytelling showmanship, show it's a golden opportunity to make connections and celebrate our Community together! Let's make this a memorable event! See you there!   Mark your calendars! Date and Time: Thursday, Sept 19th Location: PPCC24 at the MGM Grand, Las Vegas, NV 

Tuesday Tip | Accepting Solutions

It's time for another TUESDAY TIPS, your weekly connection with the most insightful tips and tricks that empower both newcomers and veterans in the Power Platform Community! Every Tuesday, we bring you a curated selection of the finest advice, distilled from the resources and tools in the Community. Whether you’re a seasoned member or just getting started, Tuesday Tips are the perfect compass guiding you across the dynamic landscape of the Power Platform Community.   To enhance our collaborative environment, it's important to acknowledge when your question has been answered satisfactorily. Here's a quick guide on how to accept a solution to your questions: Find the Helpful Reply: Navigate to the reply that has effectively answered your question.Accept as Solution: Look for the "Accept as Solution" button or link, usually located at the bottom of the reply.Confirm Your Selection: Clicking this button may prompt you for confirmation. Go ahead and confirm that this is indeed the solution.Acknowledgment: Once accepted, the reply will be highlighted, and the original post will be marked as "Solved". This helps other community members find the same solution quickly. By marking a reply as an accepted solution, you not only thank the person who helped you but also make it easier for others with similar questions to find answers. Let's continue to support each other by recognizing helpful contributions. 

Reminder: To register for the Community Ambassador Call on June 13th

Calling all Super Users & User Group Leaders     Reminder: To register for the Community Ambassador Call on June 13th—for an exclusive event for User Group Leaders and Super Users! This month is packed with exciting updates and activities within our community.   What's Happening: Community Updates: We'll share the latest developments and what's new in our vibrant community.Special Guest Speaker: Get ready for an insightful talk and live demo of Microsoft Copilot Studio templates by our special guest.Regular Updates: Stay informed with our routine updates for User Groups and Super Users.Community Insights: We'll provide general information about ongoing and upcoming community initiatives. Don't Miss Out: Register Now: Choose the session that fits your schedule best.Check your private messages or Super User Forum for registration links. We're excited to connect with you and continue building a stronger community together.   See you at the call!  

Top Kudoed Authors
Users online (2,406)