Xamarin.Android - Setting linker to "Sdk and User Assemblies" causes "Csla Authentication Provider specified does not implement IAuthorizeDataPortal" exception

[GreatBarrier86]

Describe the bug
When the android application first runs, I get an exception in LoadApplication(new App()) that Csla Authentication Provider specified does not implement IAuthorizeDataPortal. This does not happen when the linker is set to None.

I know that you don't normally use the linker during Debug, but this issue was occurring after a build/release from Azure DevOps so i needed to set the same conditions to reproduce the problem.

Version and Platform
CSLA version: 5.5.3
OS: Android 12
Platform: Xamarin

Stack Trace or Exception Detail
at Csla.Server.DataPortal..ctor (System.Type authProviderType) [0x00036] in <445611070cd74943b7ded50b0f3dc60c>:0
at Csla.Server.DataPortal..ctor (System.String cslaAuthorizationProviderAppSettingName) [0x00007] in <445611070cd74943b7ded50b0f3dc60c>:0
at Csla.Server.DataPortal..ctor () [0x00000] in <445611070cd74943b7ded50b0f3dc60c>:0
at Csla.DataPortalClient.LocalProxy..ctor () [0x00000] in <445611070cd74943b7ded50b0f3dc60c>:0
at (wrapper dynamic-method) System.Object.lambda_method(System.Runtime.CompilerServices.Closure)
at Csla.Reflection.MethodCaller.CreateInstance (System.Type objectType) [0x0002a] in <445611070cd74943b7ded50b0f3dc60c>:0
at Csla.DataPortalClient.DataPortalProxyFactory.Create (System.Type objectType) [0x000ef] in <445611070cd74943b7ded50b0f3dc60c>:0
at Csla.DataPortal1[T].GetDataPortalProxy (System.Type objectType, System.Boolean forceLocal) [0x00021] in <445611070cd74943b7ded50b0f3dc60c>:0 at Csla.DataPortal1[T].GetDataPortalProxy (System.Type objectType, Csla.Reflection.ServiceProviderMethodInfo method) [0x00015] in <445611070cd74943b7ded50b0f3dc60c>:0
at Csla.DataPortal`1[T].DoCreateAsync (System.Type objectType, System.Object criteria, System.Boolean isSync) [0x0009a] in <445611070cd74943b7ded50b0f3dc60c>:0

Additional context

[rockfordlhotka]

I often wonder about the linker and dependency injection, because so many injected types are never directly referenced or used, and so presumably are candidates for "optimization". I suspect that's what is happening here, is that the default authentication provider type has been optimized away.

In CSLA 6 the default authorizer is Csla.Server.ActiveAuthorizer. The other prebuilt option is Csla.Server.NullAuthorizer (which allows all requests to flow through).

You could try explicitly specifying the type in the AddCsla call as you configure your services to see if that prevents the linker from optimizing away the type. Something like this:

services.AddCsla(o => o
  .DataPortal(dp => dp
    .AddServerSideDataPortal(sso => sso
      .RegisterAuthorizerProvider<Csla.Server.NullAuthorizer>())
    .UseHttpProxy(hp => hp.DataPortalUrl = "https://localhost:7289/api/dataportal")));

[GreatBarrier86]

I bet you're right. Since turning off the linker helped, it makes sense what you said.

I THINK your example is on the web side. Where would I call services from within the Android project?

[rockfordlhotka]

What I showed is client-side configuration. Any RunLocal type stuff goes through the logical server-side data portal, but on the client, and that must be what's happening in your case.

[GreatBarrier86]

Where would I call your example then? What type of object is 'services'? Where should that be called?

[rockfordlhotka]

The CSLA 6 upgrade doc might help, especially here: https://github.com/MarimerLLC/csla/blob/main/docs/Upgrading%20to%20CSLA%206.md#xamarinforms-app

[GreatBarrier86]

Ah that makes sense. Thank you!

[rockfordlhotka]

If you weren't calling AddCsla during the client app startup code at all, you probably don't need to explicitly reference the authorizer type. It would be registered automatically by the AddCsla call - and I was under the assumption that AddCsla was already being called.

What I'm saying, is that I'd start with just calling AddCsla without explicitly setting the authorizer type and see if that helps, because I suspect it will solve the problem.

[rockfordlhotka]

Also note that you need to call AddCsla on the client and also the server. CSLA 6 requires that DI services be configured at app startup for all app types.

[GreatBarrier86]

I'm using CSLA 5 right now. I don't know the plans for the CSLA 6 upgrade. Do i still need to call it for 5?

[GreatBarrier86]

@rockfordlhotka, just calling AddCsla() didn't help. I was going to use your example, but it doesn't appear that DataPortal() has any arguments. Is this something your Xamarin libraries don't have?

I'm on 5.5.3 if that matters. I tried this but I can't access NullAuthorizer because it's marked protected.
new ServiceCollection().AddCsla(o => o.DataPortal().ServerAuthorizationProviderType(typeof(Csla.Server.DataPortal.NullAuthorizer));

Strangely enough, IntelliSense says that an overload exists.

[rockfordlhotka]

The code I showed was for CSLA 6, not 5.

iirc, in CSLA 5 you might need to call AddCsla and also UseCsla - at least that's true in aspnetcore.

But I'm assuming the issue is only on the client, because it only happens when you've used the linker, so we can hopefully assume the app server is working as expected.

In the v5.x branch in GitHub you can look at the XamarinExample, which is configured like this:

csla/Samples/XamarinExample/XamarinExample/XamarinExample/App.xaml.cs

Line 17 in e4855c6

CslaConfiguration.Configure().

That's the basic scheme for CSLA 5 client configuration.

I believe the CslaConfiguration.Configure method has a property or method you can call to set the authorization provider (or its type).

[GreatBarrier86]

Unfortunately for my purposes, this fix has become moot. The linker is also removing references to the Microsoft OpenIdConnect libraries so I just need to keep it to None and be done with it.