Hello,I have converted a project from ANM2023.
I get these errors after trying publishing it:
d:\APPS\FrontDeskFlux-3\Program.cs(66,30): error CS0104: 'ApplicationUser' is an ambiguous reference between 'ASPNETMaker2024.Entities.ApplicationUser' and 'ASPNETMaker2024.Models.ApplicationUser' [d:\APPS\FrontDeskFlux-3\FrontDeskFlux_1.csproj]
d:\APPS\FrontDeskFlux-3\Program.cs(69,42): error CS0104: 'ApplicationUser' is an ambiguous reference between 'ASPNETMaker2024.Entities.ApplicationUser' and 'ASPNETMaker2024.Models.ApplicationUser' [d:\APPS\FrontDeskFlux-3\FrontDeskFlux_1.csproj]
d:\APPS\FrontDeskFlux-3\Program.cs(69,18): error CS0311: The type 'ASPNETMaker2024.Models.CustomUserStore' cannot be used as type parameter 'TImplementation' in the generic type or method 'ServiceCollectionServiceExtensions.AddTransient<TService, TImplementation>(IServiceCollection)'. There is no implicit reference conversion from 'ASPNETMaker2024.Models.CustomUserStore' to 'Microsoft.AspNetCore.Identity.IUserStore<ASPNETMaker2024.Entities.ApplicationUser>'. [d:\APPS\FrontDeskFlux-3\FrontDeskFlux_1.csproj]
I have deleted all old generated files and the error still persists.
We make use of tables for users, roles and permissions (dynamic roles).Regards.
You should delete all files/folders in the destination folder first before regeneration. Alternatively, generate to a new folder to verify.Do you have a table names “ApplicationUsers”? If so, rename it if possible, there is already a class named “ApplicationUser” in the project.
Actually we have this table [Application.Users].
And we have multiple projects with this naming convention in the DBs: [Application.Users, [Application.UserLevels], [Application.UserLevelPermissions], [Application.Settings], [Application.Languages], [Application.AuditTrail] …
Please update to the latest template (Tools → Update Template) and try again.
OK, the generation went OK.
Now when I access the app it gives me this errors messages:
FileNotFoundException: Could not find file 'D:\APPS\FrontDeskFlux-3\bin\Debug\net8.0\publish\wwwroot\lang\languages.xml'.
...
ASPNETMaker2024.Models.FrontDeskFlux_1+Lang.XmlToDictionary(string file) in Lang.cs
+ private Dictionary<string, dynamic?> XmlToDictionary(string file) => XElementToDictionary(XElement.Load(file));
ASPNETMaker2024.Models.FrontDeskFlux_1+Lang.GetLanguages() in Lang.cs
+ DotAccessData data = new(XmlToDictionary(file));
ASPNETMaker2024.Models.FrontDeskFlux_1.ResolveLanguage(string langId) in aspnetfn.cs
+ SetClientVar("languages", new { languages = Language.GetLanguages() });
ASPNETMaker2024.Models.FrontDeskFlux_1+IndexBase..ctor() in index.cs
+ Language = ResolveLanguage();
ASPNETMaker2024.Models.FrontDeskFlux_1+IndexBase..ctor(Controller controller) in index.cs
+ public IndexBase(Controller? controller = null): this() { // DN
ASPNETMaker2024.Models.FrontDeskFlux_1+Index..ctor(Controller controller) in index.cs
+ public Index(Controller controller) : base(controller)
ASPNETMaker2024.Controllers.HomeController.Index() in ewcontroller.cs
+ index = new GLOBALS.Index(this);
disabling multi-language the app runs OK
downloaded again, from download page and customer’s page and I get the same result.
deleted all the files: project folder, published folder, etc…
Please delete the ASPNETMaker folder as well so it will be reloaded from the latest installation.
Deleting the ASPNETMaker folder fixed the issue.
Now the app runs multi-language.Now, I get 401 Unauthorized on any lookup API call (all pages).
The app is deployed on IIS with Windows Integrated Auth and my role is Admin (Role = -1)
I get the auth prompt form the browser but adding username/password (domain user) is not helping at all.I remember that this kind of issue has occurred in the past after an ANM upgrade.
Make sure that the user has Lookup permission.
The user is an admin, (RoleID -1), I have never granted permissions to this role.
darkdragon wrote:
The app is deployed on IIS with Windows Integrated Auth and my role is Admin (Role = -1)
Windows authentication is not related to ASP.NET Maker’s Advanced Security. If you do not use dynamic user level security, go to User Level settings, check the permissions of each user level under Static User Levels, make sure “lookup” permission is enabled, then generate scripts again. If you use dynamic user level security, login as the super admin, go to the user levels table and check the user level permissions of each user level stored in the database table.
As a long-time user and customer I know what I’m saying. The projects works ok on ANM2023.Authentication mode in Advanced Settings can be set on Windows, and with the help of some code in User_CustomValidate event I know what user is accessing the app.
There is no way I can assign individual permissions on the Admin (RoleID = -1), as the button for permissions assignment is not visibile.
I just made a test:Authentication Mode in project advanced settings: Cookie and remove WIA in IIS and switched to Anonymous Authentication.
This way I prompted with the login page. I just put the Super Admin credentials and I’m able to login in the app.If I access a page which is calling a lookup API, this time I get 403 Forbidden:
Request URL:
http://localhost/frontdeskflux-3/api/lookup
Request Method:
POST
Status Code:
403 Forbidden
Remote Address:
[::1]:80
Referrer Policy:
strict-origin-when-cross-origin
In both cases, WIA or Anonymous Auth in IIS together with Windows Authentication/Cookie at project level, the Payload of the API call is loaded, but I get either 401 Unauthorized or 403 Forbidden
If you believe your settings are correct and you’re a registered user of v2024, you’d better send your project files and database to support for their testing.
Support Team solved my issue. I leave here the solution maybe it will help others:
"You need to change your advanced setting API JWT authorization header from “Authorization” to “X-Authorization” otherwise the JWT token for API will overwrite the header for Windows Authentication."Still my comment is that somehow that setting has been carried over from previous versions (or it was a default setting) as we usually do not interfere with JWT settings.