-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ease Transition From XrmToolKit #492
Comments
|
So I got a new collegue that spent some time on generating earlybounds that could be used to migrate off from XrmToolkit. We didn't generate 1:1 - some refactoring is required for our code that relies on earlybounds. But that is one-time operation. Our custom serviceSo we have some code. It is written as a custom service. Some of those things could be useful in upstream project, say custom base class or being able to change name of field. And actually this code also requires 1 change to be made in upstream project that deals with setting nullable types - additional ignores must be added to InvalidStringsForPropertiesNeedingNullableTypes - I believe this can easily be a configuration option to not break existing code: Settingify?I was thinking whether ALL the changes could be upstreamed in a way that it takes only configuration to generate this kind of code. A configuration that doesn't involve a single checkbox: make xrmtoolkit compatible code. As xrmtoolkit on itself has different configuration options and we only generated stuff in a way configured for our use case. Moreover it would be more flexible to have different configuration options and a settings template that would work for xrmtoolkit users to provide a migrate path be used. Here be some struggles with providing configuration options for some tasks:
static Account()
{
BaseProxyClass.RegisterProxyType(typeof(Account), "account");
_textOptions = new Dictionary<string, eTextOptions>();
_numberOptions = new Dictionary<string, eNumberOptions>();
_errorStrings = new Dictionary<string, string>();
TextError = "The value for attribute \'{0}\' cannot be longer than {3} characters. The length of" +
" the value is {2} characters.";
NumberError = "The value for attribute \'{0}\' must be between {2} and {3}. The value is {1}";
} RefactoringAs for refactorings required to code that uses ebg:
Still, without this custom generator class we wouldn't be able to use EBG as we heavily rely on entities being inherited from custom base class and calling Upstream?Soo... I want your thoughts @daryllabar - whether you would like this code to be upstreamed or not. And in such case we can be open whether you don't want to put any effort into taking existing code and weaving into your project or only PR way from our part will work for you. Additional files.Attached Account.cs you can diff what we achieved. There are still some work that needs to be done to preserve previous constructors. I'll send you a link to our source in DM. |
The XrmToolKit has it's own custom entity generation: https://xrmtoolkit.com/General/GlobalSettings (https://github.com/NHS-Blood-and-Transplant/IRDP/blob/3e380cfc085ff2e7f4768c3e2b5b5573dbffd8a4/NHSBT.IRDP.Plugins/ProxyClasses/Contact.cs)
Some things that would ease the transtion from that to the EBG:
public class SystemUser: BaseProxyType
The text was updated successfully, but these errors were encountered: