Moving it to .net standard (1.2 because of .net framework 4.5.1)

[aochmann]

IMO we should move it to .net standard (it will help us with future .net core movement and re-use it in another project that are not Umbraco related) and rewrite the Umbraco extension for TryConvertTo. I saw implementation and lot of logic use internal (.net) mechanism, but just the model Attempt comes from Umbraco.

We can also look at:

• https://codereview.stackexchange.com/questions/17982/trycastt-method

Here Umbraco code base links:

• https://github.com/umbraco/Umbraco-CMS/blob/v8/contrib/src/Umbraco.Core/AttemptOfTResult.cs
• https://github.com/umbraco/Umbraco-CMS/blob/v8/contrib/src/Umbraco.Core/Attempt.cs
• https://github.com/umbraco/Umbraco-CMS/blob/v8/contrib/src/Umbraco.Core/AttemptOfTResultTStatus.cs
• https://github.com/umbraco/Umbraco-CMS/blob/a0aad045fb7267650b4330c26d391d1788cec7fd/src/Umbraco.Core/ObjectExtensions.cs#L75

Or we can find another way, not using TryConvert -> maybe some another library.

What do you think guys @trt @mzajkowski

[aochmann]

IMO we should delete the Umbraco tryConvert (possible no updates there or hard to maintenance) and use just GetConverter. It has lots of converters and we have abilities to create our own - https://www.hanselman.com/blog/TypeConvertersTheresNotEnoughTypeDescripterGetConverterInTheWorld.aspx

Also played with library TypeConvert (https://github.com/deniszykov/typeconvert) and here's the performance:

• tryConvert - 00:00:00.0100070
• GetConverter - 00:00:00.0009975
• TypeConvert - 00:00:00.2069999

We can perfom try catch on GetConverter to handle all not supported converters.

When we will do it by removing Umbraco dependency then we would use this library everywhere -> .net standard.

[mzajkowski]

I think it's a very good idea (removing dependency from Umbraco + being .net independent). The only thing which spotted my eye and made me conscious is if we should go that granular with the libraries 🤔

I mean "Configuration" for example vs. "Essentials" (or whatever else naming we can set there). It's good to have a division into domains/logical sets of features and functionalities, but ending up with 100 libraries with 1 class in each is not the desired destination I presume.

TBD for sure!