I know this is no proper technique to work with D365. But actually we needs this. So anybody explain in how we can pass arguments through reflection in D365.
This hack would introduce a dependency on implementation details that can change at any time and it wouldn't be detected at compile time; you would get an ugly runtime error when the code was executed. Are you sure want ignore all rules and introduce such a risk for a mission-critical ERP system of your client?
Don't you want top rather discuss how to solve your business requirement in a correct way?
Wondering if this "soft/hard sealing" is the correct way to go, developers are forced to use reflection, technically this is the way to go, but the code is getting harder to maintain. If every place has to go this way, AX will be a different product and uncomfortable platform for us. Developers lose the freedom to do things in the reliable way...Painful trade off result...
Martin, you should let Microsoft know about this, it doesn't have to be Microsoft's choice, even though there are other software vendors doing this 'sealing' thing... We don't know how it's going to be like in the long term, but we see negative things here for sure...
No, you're not forced to use reflection to hack into private members. You shouldn't do it.
First consider if your requirement really can't be achieved without accessing private members. It often require some research; we shouldn't give immediately when the most straightforward approach doesn't work.
If you have a valid scenario which can't be implemented without accessing private members, you should ask authors to make their solution extensible. In the case of Microsoft, it means logging an extensibility request on LCS.
I don't agree that overlayering with code and metadata conflicts on every update was easier to maintain. We don't have to speculate; we saw how difficult, expensive and error-prone upgrades used to be.
That every company manages their own code and there no overlayering conflicts anymore certainly makes things easier, not harder to maintain.
The problem is different - that AX wasn't ever designed for extensibility; Microsoft started changing this only in D365FO and it's near to impossible to retro-fit extensibility to such a large codebase. There are some unusual features such as the ability to attach code to most methods, which basically adds thousand extension points to the application, and Microsoft is refactoring places which people need to be extensible. This is what extensibility requests are for.
What we're getting into is how development usually work. If you're a SharePoint developer, for instance, you also don't change all the standard code. Instead, you extend SharePoint by custom controls, content types, business logic etc.