![]() |
#1 |
Участник
|
When you spend more time in C# than C/AL, and you still tell yourself and the world around you that you are developing for NAV, then this post is for you.
I already wrote a three-article series about “DLL hell” and how to resolve it, and in my last post in the series (http://vjeko.com/sorting-out-the-dll...art-3-the-code) I delivered some code that help you take control of your .NET assemblies. This time, I am delivering an updated solution, one that solves all the problems others, and myself, have encountered in the meantime. So, fasten the seatbelt, and let’s embark on another .NET interoperability black belt ride. First of all – a short disclaimer. On the face of this trick that this post is talking about, you could say “whadda heck, this is the same as the standard database deployment feature” – but you’d be wrong. The difference is huge, and over the next few posts I’ll spend some time to explain in what ways it is different specifically. I know that at least a few of you have been impatient and asked for code and everything, so I’ve nicely put all this together and published it on GitHub: https://github.com/vjekob/NAV-Assembly-Resolver So, what do we have there. First is, the Assembly Resolver assembly code. Many of you have asked about the “dll” to put into the Add-ins folder. You can take this C# solution, compile it and you get your assembly that you can put into the Add-ins folder for the development environment. You don’t need it for the service tier (at least not if you are on 2016). These are the differences from the first version:
So, how does it work? First – it checks whether the AssemblyResolver type is available, and if not, then it installs itself: ![]() This “installs itself” does the following:
![]() At this point, if everything is okay, NST will locate the assembly in the Add-ins table, and deploy that assembly from the database and dynamically load it. If something is not okay, you get a message about it, and the codeunit exits. Everything else is already described. Now, you may think again: what the heck – he is using database deployment and is providing a feature that’s purported to replace it. As a matter of fact, yes. Database deployment is – as I said earlier, and as I will show again – not working correctly. I can’t know for a fact exactly what it does at execution level, but I am sure I’ve been able to pretty accurately figure it out from its behavior, and having worked with .NET since 2000 when it was still in beta, you can take my word for it: it’s doing it all wrong. This little assembly that I provide here takes care of all the wrong in there, and fixes it. The end result is this:
One small limitation in multi-tenant environments is that the InstallResolverAssembly function will only execute successfully when ran from a session of a tenant mounted with “allow application database write” setting. And last, but not least, this works in Managed Service – I had problems making the version that binds itself during the OnAfterCompanyOpen works, but if you avoid binding from there, and load it afterwards, then this works nice. Good luck with this, and let me know if it makes your life easier. Read this post at its original location at http://vjeko.com/dynamically-loading...ies-at-runtime, or visit the original blog at http://vjeko.com. 5e33c5f6cb90c441bd1f23d5b9eeca34The post Dynamically loading assemblies at runtime appeared first on Vjeko.com. Читать дальше
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|