Multiple UserBase implementations

Along the lines of this post, I have a "guest" account used to access the BOS during the logon process.  Once the user authenticates, I switch to a standard account.

To implement this scenario, I have two custom classes that extend UserBase.  This used to work fine in 6.0.1.0 but seems to randomly break in 6.0.2.0 (I'm sure it's not actually random, but it seems that way). 

Using my good friend Reflector, I see this line of code in UserBase.GetCustomUserType():

Type type = ReflectionFns.GetTypeImplementing(typeof(UserBase), IdeaBladeConfig.Instance.GetAllProbeAssemblyNames(), Cardinality.ZeroOrOne, true);

So it appears you are now expecting only zero or one custom UserBase implementations (that is, you don't expect two like in my case).

What is particularly weird is that sometimes my app works fine...I'm not sure if it has to do with when things get probed or what, but at least in some cases it's a fatal error that breaks my logon process.

I'm confused...you say "we supported only a single custom UserBase implementation" but does that only apply if we're using the AspALM?  Otherwise you do support multiple?

I guess we didn't run into the problem in 6.0.1 because we aren't using the AspALM so this check didn't get hit but then you moved the check to UserBase so now we hit it (if I understand correctly).

We aren't using ASP.NET security and don't use AspALM and also implement our own custom IEntityLoginManager...however, we seem to still hit the limitation of on multiple UserBase's.  The UserBase class checks to make sure there is only one custom UserBase as part of it's static constructor so I can't really do anything related to UserBase without getting an exception (in my case, I'm trying to new up an instance of my custom UserBase class but that doesn't work).

Hope that made sense...

Just to chime in with Stephen (we work together); this 'seems' to only manifest itself (in 6.0.2) as a problem when using a PassThruESQLQuery on the server-side (6.0.1 worked fine).  As part of our intial load of data, we call an RPC method to load up the server-side EntityManager cache with all the necessary entities and then ship the cache back to the client where it's merged back into the client-side EntityManager.

IEntityQuery query = new PassthruEsqlQuery (typeof(MyEntity), "SELECT VALUE u FROM MyEntitySet AS u");

manager.ExecuteQuery(query);

Caught exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> IdeaBlade.EntityModel.EntityServerException: 'MyEntitySet' could not be resolved in the current scope or context.

The problem I'm having does not appear to be related to UserBase.  It seems to be an issue with using a custom login manager and multiple EDMX datasources that use datasource key extensions (a multi-tenant app).

Any progress on this or a timeline when it might be fixed? 

Thanks, the work-around works for both ESQL and for Stored Procedure calls.

Here's the workaround until the next release.  Basically, you need to access the EntityContainer which will force the correct initialization.  Here's some sample code written as an RPC call to the server, but you could also put this in the EntityServerQueryInterceptor.

public static EntityCacheState LoadInitialData(IPrincipal principal, EntityManager serverEm, params object[] args) {

  var manager = (NorthwindIBEntities)serverEm;

 

  // Hack -

  // Get the DataSourceKey used by the problem query.  It's a server-side EdmKey.  Accessing the EntityContainer forces initialization.

  var key = manager.DataSourceResolver.GetDataSourceKey(typeof(Customer)) as IdeaBlade.EntityModel.Edm.EdmKey;

  var ec = key.EntityContainer;

      …..

}