I find myself using a lot of redundant code on different customizations. Is it far fetched to consider writing a DLL to house all this code that I can import and call at will? Are there any roadblocks?
For example, I use many dynamic forms for confirmation and warnings and call lot’s of the same BAQs to feed to grids.
Only downside is that DLLs are version dependent. So when you upgrade from version to version you’ll have to recompile the DLLs and redeploy them.
Bah… cut n paste it is
The DLLs will still run if you force the BPM to be Compatible… But everytime you do a DB Copy, it will be outdated again. Jose is right, once you upgrade 500 to 600 you will need to recompile against Epicor’s latest DLLs. This also goes for Service Connect if you import .NET Libraries you will need to re-import or your SC will keep blowing up with errors of version mismatch etc…
Overall… DLLs are great at this time if your making a Helper Library, but for re-usability Epicor still has to do some work so we don’t copy/paste code, violating the DRY rule, right @Bart_Elia =)
What I tend to do is create a class outside of class Script { } and make use of that for the time being; for code that is duplicated alot.
I also pass through references to objects that I am going to use very likely.
Nice @hkeric.wci
Perhaps some silly questions, but how do you get you get your code outside of the script? Are you able to reference this from any customization?
It looks like you literally just moved your code outside of the script brackets. If you can’t access this from other customizations, what benefits do you gain from doing so? #ThirstyForKnowledge
You cant call it from another Customization; but the benefit for me is that I do not clutter my repetitive code within that Customizations Code; Since it is very likely that Customization B will utilize the same code that Customization A uses; on top of that it will have Unique Code related to only itself… So just decluttering it. Then when I copy/paste it and if I make a change to the class I can easily do a find/replace without messing with the code inside Class Script { } which again might be unique for Customization B or C or D.
My developer likes to use dll’s but I have banned them because of the added complexity’s of the upgrade process.
I would rather have more code and have it easily testable by the epicor upgrade tests than code that is written once and compiled into a dll and then incompatible after a class name change or something similar.
Ideology say write once use many times - but in practice it is sometimes important to fit the situation at hand.
I know this is counter to most of the posts so far but we’ve been using a client side common functions DLL for years with minimal issues.
Not going to discount the claims of issues when upgrading because they are completely valid. What we’ve found is that it’s yet to be a significant hurdle. Recompile, run through tests, and push out to the client. The amount of time that’s consumed during each upgrade has been outweighed by the development savings.
It is worth noting that we keep the DLL as specialized as possible, there are very few Epicor DLLs that it’s dependent on and it’s primarily working with the UI.
The only exception is our standardization of the BAQ retrieval to simplify running them through customizations. In theory we could spin that off into a REST client DLL and could remove the need to recompiled/redeploy that every time we upgrade.
The scenario is well understood internally. Working on something we may be able to greenlight for vNext…
