Multiple plugin assemblies inside Nuget package and LINQ query issue

(0) Share

Report

Posted on by PeterPeter

Hello Experts.

I have the following situation on my Dataverse environment.

I’ve a Visual Studio Dataverse plugin solution which contains 4 separate .NET 4.6.2 projects. My data model classes (generated with PAC CLI tool) are stored in one of the above-mentioned projects and are built into separate assembly which is used by other 3 DLLs. Context class is marked with Microsoft.Xrm.Sdk.Client.ProxyTypesAssemblyAttribute attribute.

Components architecture of this solution looks like on the screen below:

The whole solution is released into Dataverse as a NuGet plugin package (containing 4 DLLs mentioned above). When the following LINQ query is executed inside a plugin everything works fine.

public Account GetByAccountNumber(string number)

{

using (var ctx = new DataverseContext(this.service) { MergeOption = MergeOption.NoTracking })

{

return ctx.CreateQuery<Account>()

.Where(x => x.AccountNumber == number)

.FirstOrDefault();

}

However, when I run similar query against SystemUser table or any kind of custom tables – I’m getting the following error:

Unable to cast object of type 'Microsoft.Xrm.Sdk.Entity' to type 'XXX.Customer.Project.Model.SystemUser'

This is a very interesting situation because for account table I’m not getting this error. It happens only when I try to use LINQ query against SystemUser or custom tables. I’ve tried to merge all the 4 assemblies into single one and it eliminates the problem, but it does not make sense for me to use NuGet package and store single merged assembly inside.

Has anyone met with the similar situation?

Any ideas?

Categories:

Power Apps Pro Dev & ISV

I have the same question (0)

All responses (5)

Answers (1)

cchannon 4,702 Moderator on at

Like (0)

Report

I am sure that with enough bughunting you can find a solution to this, but why introduce all this complexity? Why not just have all four projects in one sln, then deploy as a single Plugin assembly instead of as a Plugin Package?

The only reason why Plugin Packages were introduced was to enable you to bring in other assemblies where you cannot control the source code and would otherwise need to ilmerge them in (the most commonly cited example being Newtonsoft). But in your case, you do control all the source code, so it is much, much simpler to just put all four projects under one sln and deploy them as one assembly (NOT a package).

Was this reply helpful? Yes No
PeterPeter 36 on at

Like (0)

Report

Yep, I'm aware we can place all the code inside single assembly. We've been doing this for many years or just use ILMerge to make deployment of external assemblies possible.

When Nuget packages were introduced we decided to switch our architecture to the one mentioned above to reduce complexity of single Visual Studio Project (we have projects for enterprise organizations where hundreds of plugins are used), make solution more component-oriented and make unit and integration testing easier and faster.

So for us - multiple assemblies approach is more about reducing solution complexity and getting rid of big ball of plugins' mud than introducing more of it :).

Was this reply helpful? Yes No
Verified answer

PeterPeter 36 on at

Like (2)

Report

Ok. I believe the following code, used during OrganizationServiceFactory initialization, solved the problem:

var serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
var proxyProvider = serviceFactory as IProxyTypesAssemblyProvider;
if(proxyProvider != null)
{
proxyProvider.ProxyTypesAssembly = typeof(DataverseContext).Assembly;
}

Where DataverseContext is the name of my strong-typed tables classes context.

Was this reply helpful? Yes No
DD12 7 on at

Like (0)

Report

@PeterPeter Thank you, your code snippet made my day. I have been trying to resolve this for a while now. Looks like you are writing clean code using clean architecture. I fully hope this is the future of plugin projects now we have dependent assemblies.

@cchannon not everyone only has a plugin project. There might be multiple plugin projects, by feature. Additionally complex Dataverse environments with integrations have an invested interest to have one shared early bound assembly that is reused in plugins, integrations services and potentially API's.

Was this reply helpful? Yes No
bastiE 2 on at

Like (0)

Report

Hello, another thing that works without the code of @PeterPeter is to just not use early casting like this "(systemuser)service.Retrieve(...)" but use "service.Retrieve(...).ToEntity<systemuser>();" This will also solve the "can not cast" exception. 🙂

Was this reply helpful? Yes No