Multiple plugin assemblies inside Nuget package and LINQ query issue

[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?

[cchannon]

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).

[PeterPeter]

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 :).

[PeterPeter · Accepted solution]

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. 

[DD1231]

@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. 

[bastiE]

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. 🙂