Eliminiate Microsoft.CodeAnalysis from builds?

Microsoft.CodeAnalysis and Microsoft.CodeAnalysis.CSharp dlls (wasm) are included when building my Blazor app. These are by far the largest references included, and even several times larger than the Radzen dll itself.

It seems they are included as they are referenced by the Radzen library. Is this correct? If so, is it possibly to eliminate this dependency? It is adding quite much to the build size of my application.

This dependency is needed and cannot be eliminated.

OK, thank you for clarifying that.

I was looking into the same issue for the same reasons - I noticed that it's loading a 5 MB Microsoft.CodeAnalysis.CSharp.wasm, which is by far the biggest class...

Looking through the Radzen source, it seems it's only used by ExpressionParser.cs...

Then ExpressionParser.ParsePredicate<T> is used by DynamicExtensions Where<T> - Which is used by QueryableExtension Where<T> which is then used by RadzenDataGrid.razor.cs:

        view = viewList.AsQueryable()
            .Where(i => childData.ContainsKey(i) && childData[i].Data.AsQueryable().Where<TItem>(allColumns).Any()
                || viewList.AsQueryable().Where<TItem>(allColumns).Contains(i));

It would seem like there must be a better way to parse Where Predicates on a datagrid other than loading a 5 MB wasm and using a CSharpSyntaxTree...

For now best solution seems to be to switch back to Radzen.Blazor 5.9.9

The reason for moving from Dynamic LINQ to Roslyn was highlighted here:

We will not risk another similar event where some of our dependencies or our own library to be marked as vulnerable.

Yea, it's not an ideal solution, that's why I said "For now best solution seems to be [...]"

Is this "string to C#" stuff used internally by Radzen?

            var expression = ExpressionParser.ParsePredicate<OrderDetail>("it => (it.Product.ProductName == null ? \"\" : it.Product.ProductName).Contains(\"Queso\") && (it.Quantity == 50 || it.Quantity == 12)");

Otherwise if this is only for consumers, maybe there's a way to compartmentalize this and put it in a separate library? Like a Like a Radzen.Blazor.DynamicLinqSupport kinda extension?

A lot of people probably don't need "string to linq" support, and in a Blazor WASM context I'm trying to keep the size small... So loading a 5 MB dll for this is not ideal

5MB size is a huge increase, and is there any way to exclude the feature ?

This will break almost every user of Radzen Blazor Studio. We won't do that.

This has already been answered earlier in the thread. Use a 5.x.x version if you don't want this dependency.

We are currently working on a new way to enable this feature without those assemblies which will be introduced at a later point in time as a new major release.

1 Like

I've made a fork to get rid of this:

Should be allowed by the MIT License I assume

It should sync every day with the sync action (unless there are merge conflicts) - and publish a new version if possible with the build action

Obviously using the string to linq syntax doesn't work anymore with this package, but if you're just using typed linq expressions everything should be fine

Hey @RonSijm,

You might need to check this:
https://forum.radzen.com/t/upcoming-new-major-version-7-0-0/20202/2

Radzen.Blazor 7.0 was just released without dependency to Microsoft.CodeAnalysis.