Auto-rebuild customizations on load

Epicor ERP 10
, , ,
1

Afternoon all (or morning, whatever part of the world you’re in!)

I’ve come across an interesting issue, and was curious if anybody has any insight on how to go about solving this. We have a customization that references an external assembly (one that we’ve built). We version our assemblies, so when we do any updates, we’ll increment the version - 1.0.0.0 to 1.0.0.1 for example.

Now if a customization is built and references 1.0.0.0, when we update the version on our assembly to 1.0.0.1, Epicor throws an exception that it can’t load 1.0.0.0 - because the compiled DLL from the customization holds reference to that specific assembly.

So I’m curious if anyone has any ideas for a solution to this issue? Ideally, we don’t want to run scripts that kill off the -808 folder and have it recreated, and not particularly keen on forcing the client to do a reset of the cache. Is there something I may be missing that is glaringly obvious to mark the assembly as external, to recompile customizations on load if the signatures are different, or anything else?

Edit: The reason the title is as it is, is because when we open the form with the customization in customization mode, and just recompile it - it works. That’s because it recompiles the assembly for the customization, so pulls in the references based on the reference paths.

Many thanks!

Dave.

2

There has been a lot of discussion about this issue over the years. It is a design issue when we choose to tightly couple our objects. Fortunately, C# supports some strategies to avoid this problem. Designers use interfaces and abstract classes to loosely-couple objects. You will hear of a pattern called inversion of control or dependency injection used to solve this kind of problem. A Google search will show you how you can instantiate your object regardless of version if the signature hasn’t changed.

Mark W.

3

So a couple of things
Why Versioning? I mean versioning the assemblies is nice and all but .NET is particularly fussy about that, so why not keep the assembly version the same? It is just an internal DLL and I’m assuming you use the same DLL everywhere so leaving the version alone would fix this problem for you.
Version your actual code using Git or something like it but leave the assembly version alone, again for small internal DLL’s this is more of a nuisance than an aide.

If that’s not an option you can always try reflection, you can dynamically load your assembly and invoke any of its members and methods using reflection. This would completely bypass any versioning issues and frankly with the dynamic objects now it is a breeze, it isn’t pretty but it does work.

using System.Reflection
Assembly a = Assembly.Load("example.dll");
       // Get the type to use.
       Type myType = a.GetType("Example");
       // Get the method to call.
       MethodInfo myMethod = myType.GetMethod("MethodA");
       // Create an instance.
       object obj = Activator.CreateInstance(myType);
       // Execute the method.
       myMethod.Invoke(obj, null);

Also, you can go to Customization Maintenance every time you make a new version of the DLL and just run a Verify/Recompile from there on a mass scale, that may solve it all together (though I haven’t tried)

Finally you could move that logic in your DLL into something internal within Epicor say a UBAQ and invoke that from your customization. This works well and upgrades cleanly from version to version

3 Likes
4

Yes! This is the cleanest option. It keeps all your code in your database and avoids the extra maintenance of distributing a DLL.

2 Likes
5

Versioning your customizations will also achieve what you’re looking for. We use a similar versioning scheme for our customizations. If we want to ensure the new DLL is picked up we’ll save a copy of our customization with a new version and apply that to the menu. Not the same but just as effective as a recompile without the overhead.

6

But if your users have personalizations, they lose them. My users get mad when that happens.

1 Like
7

That’s why I have been taking them away screen by screen muah ha ha ha ha. Onece we evaluate a screen and get column orders and size all standardized add some hot keys, etc I disable personalizations for that screen via a BPM that is setup to do that for me. It eases the pain vs ripping it away from everyone all at once.

8

That’s why we made it abundantly clear that personalizations are their responsibility. We can’t guarantee they’ll stick around and sometimes we’ve got to remove them (upgrades, etc). So far kept them from doing anything too convoluted, and we haven’t had a single complaint.

9

Well, I have some people that need 29 inch monitors zoomed in, and other people that can see fine. So the same display doesn’t work for everyone, but I get your point.