Hi Y'all,
I have created a blazor XAF application, which based on the url goes to a different database connection (connectionstring).
I Created a small service for this:
C#public class MyService : IMyService
{
public readonly NavigationManager _navigationManager;
public MyService(NavigationManager navigationManager)
{
this._navigationManager = navigationManager;
}
public string FindConnectionString()
{
string connectionstring = string.Empty;
var url = _navigationManager.BaseUri;
//do stuff with url and returns connectionstring
return connectionstring;
}
}
public interface IMyService
{
string FindConnectionString();
}
In Startup.cs I have:
C#services.AddScoped<IMyService, MyService>();
Which will be called in the XAF Builder:
C#builder.ObjectSpaceProviders
.AddSecuredXpo((serviceProvider, options) => {
var myservice = serviceProvider.GetRequiredService<IMyService>();
var connectionString = myservice.FindConnectionString();
ArgumentNullException.ThrowIfNull(connectionString);
options.ConnectionString = connectionString;
options.ThreadSafe = true;
options.UseSharedDataStoreProvider = true;
})
.AddNonPersistent();
This worked Fine in 22.1.5 but I upgraded my application to 23.1.4 and now the NavigationManager is not connected to JS anymore.
Hello, Michael.
NavigationManager is a standard ASP.NET Core service, and XAF Blazor does not affect its BaseUri in any way. Probably, some changes were made between ASP.NET Core versions or your application code between v22.1 and v23.1.
In any event, we recommend you look for possible solutions in public community resources like Stack Overflow or Microsoft Docs. If you resolve it, please share your solution with other XAFers here.
Or if I misunderstood you, please clarify what question related to DevExpress/XAF API you want us to answer here? Thanks.
Hi Dennis,
I am very aware that this is a standard ASP.NET Core Service. The changes in behaviour are due to the version of DevExpress lib's.
When I target Devexpress lib's 22.1.5 MyService works fine, If I change this to 23.1.4 It goes in, works fine, after that i goes back in there (seems like it is an underlaying redirect, because it get's back in the constructor) and the NavigationManager throws an exception when we request the BaseUri (or Uri for that matter).
I did not check any DevExpress versions in between.
Hello, Michael.
I am afraid correlation does not imply causation ("after" does not automatically mean "because of") - at least our developers are unaware of product changes that might affect this. So, my previous recommendation still applies. If you received any .NET or JS errors in the latest versions, search public community resources for these errors as well.
Probably, your current approach did not work reliably even in older versions, and a different or more robust approach should be used. While we have not experienced exactly the same task before (with a connection string based on URL), we used the following approach in our E1344 example: https://github.com/DevExpress-Examples/XAF_how-to-change-connection-to-the-database-at-runtime-e1344/blob/3b0719ad2926cfedc23a6deb7489d56dbbd8fdd0/CS/XPO/ASP.NETCore/Blazor/RuntimeDbChooser.Blazor.Server/Startup.cs#L50 - note that IConnectionStringProvider is used more than in one place here (for instance, also to control BlazorApplication.IsCompatibilityChecked).
Hi Dennis,
I Cannot find anything about a change between DevExpress 22.1.5 and 23.1.4 in public community resources.
However I did some investigations by myself. It seems like the changes happen between 22.1.11 and 22.2.3
As this is the only change which breaks the applications (I did not change anything else at all) there should be a correlation. As the behaviour is different.
I went further in my investigation.
It seems to be even weirder then expected.
When I execute my application I added a breakpoint in MyService on the line where states:
var url = _navigationManager.BaseUri;
In 22.1.5 it hits only once.
In 22.2.3 it hits twice. With different call stacks.
The first one (right one, also hitting 22.1.5)
And then the failing one:
So it seems to be failing when creating a "Shared Application"