I am trying to create a version 5.3.4 project with IdentityServer4. When I downgrade abp CLI and SUITE to v5.3.4 and create a project via ABP CLI using --version 5.3.4 the CLI creates a standard tiered MVC APP project, not an MVC APP-PRO project. When I try to open the project with ABP SUITE v 5.3.4 I get a message "Suite works only with app-pro and module-pro templates!" . Question: How do I use CLI v 5.3.4 to create a v 5.3.4 APP-PRO templated project . I have a specific need for .net core 6 and IdentityServer4.
Next, How do I add Volo.Account.Pro to an v 5.3.4 project created from the command line so it replaces the nuget packages with the source code project?
Thanks for looking into this.
Hi,
you need to remove the project reference form
.csprojtoo (identityserver, publicweb)
I created a fresh project using abp suite and added the Account and Identity sources. I removed the projects that were not needed. I still get a project publish error. IMPORTANT NOTE* I can successfully build and PUBLISH if I don't add the Account and Identity packages in a non-tiered project. In a tiered project or non-tiered project as soon as I add the Account and Identity sources I get a PUBLISH build failed due to the Account resources having the same relative path. This was not an issue in .NET core 5 or 6. Seems to be related to .NET CORE 7 and later. If I exclude from the project, the _viewstart, etc from one of the dup project issues, I can safely publish. Currently, I just make sure the necessary files (at least one with all taghelpers is included in the build). I exclude from the project the others in the path that are causing errors.
Here are the publish errors and the file contents of _ViewImport and _ViewStart which I included for reference.
Severity Code Description Project File Line Suppression State Tool Details
Error Found multiple publish output files with the same relative path:
D:\abp\myweb2\MyWeb2\modules\Volo.Account.Pro\src\Volo.Abp.Account.Pro.Public.Web.Shared\Pages\Account\_ViewImports.cshtml,
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
@addTagHelper *, Volo.Abp.AspNetCore.Mvc.UI
@addTagHelper *, Volo.Abp.AspNetCore.Mvc.UI.Bootstrap
@addTagHelper *, Volo.Abp.AspNetCore.Mvc.UI.Bundling
D:\abp\myweb2\MyWeb2\modules\Volo.Account.Pro\src\Volo.Abp.Account.Pro.Public.Web\Pages\Account\_ViewImports.cshtml,
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
@addTagHelper *, Volo.Abp.AspNetCore.Mvc.UI
@addTagHelper *, Volo.Abp.AspNetCore.Mvc.UI.Bootstrap
@addTagHelper *, Volo.Abp.AspNetCore.Mvc.UI.Bundling
@addTagHelper *, Owl.reCAPTCHA
D:\abp\myweb2\MyWeb2\modules\Volo.Account.Pro\src\Volo.Abp.Account.Pro.Admin.Web\Pages\Account\_ViewImports.cshtml,
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
@addTagHelper *, Volo.Abp.AspNetCore.Mvc.UI
@addTagHelper *, Volo.Abp.AspNetCore.Mvc.UI.Bootstrap
@addTagHelper *, Volo.Abp.AspNetCore.Mvc.UI.Bundling
D:\abp\myweb2\MyWeb2\modules\Volo.Account.Pro\src\Volo.Abp.Account.Pro.Public.Web\Pages\Account\_ViewStart.cshtml,
@using Volo.Abp.AspNetCore.Mvc.UI.Theming
@inject IThemeManager ThemeManager
@{
Layout = ThemeManager.CurrentTheme.GetAccountLayout();
}
D:\abp\myweb2\MyWeb2\modules\Volo.Account.Pro\src\Volo.Abp.Account.Pro.Admin.Web\Pages\Account\_ViewStart.cshtml. MyWeb2.Web 0
@using Volo.Abp.AspNetCore.Mvc.UI.Theming
@inject IThemeManager ThemeManager
@{
Layout = ThemeManager.CurrentTheme.GetAccountLayout();
}
Created a Master/Child project using ABP studio following your orders example from the screen shot produced in the Master entity link. The ABP studio latest version failed to create the detail record form or any part of it. Reverting back to abp suite 8.2.1 and completely uninstalling the latest version of studio ending in .4 and I am able to produce parent child data again. Also, ran into the infinite upgrade loop even after upgrading to latest version as mentioned by @MRBRL
ABP Studio is too painful to use because it breaks everything it touches.
Provide us with the following info:
ABP Framework version: v8.2.0
UI Type: MVC
Database System: EF Core (SQL Server)
Tiered (for MVC) or Auth Server Separated (for Angular): NOT tiered
Exception message and full stack trace:
No Stack trace.
Error after running Publish from Visual Studio 2022
C:\Program Files\dotnet\sdk\8.0.303\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5): Error NETSDK1152:
Found multiple publish output files with the same relative path:
C:\abp\MYNewApp\modules\Volo.Account.Pro\src\Volo.Abp.Account.Pro.Public.Web.Shared\Pages\Account_ViewImports.cshtml, C:\abp\MYNewApp\modules\Volo.Account.Pro\src\Volo.Abp.Account.Pro.Public.Web\Pages\Account_ViewImports.cshtml, C:\abp\MYNewApp\modules\Volo.Account.Pro\src\Volo.Abp.Account.Pro.Admin.Web\Pages\Account_ViewImports.cshtml, C:\abp\MYNewApp\modules\Volo.Account.Pro\src\Volo.Abp.Account.Pro.Public.Web\Pages\Account_ViewStart.cshtml, C:\abp\MYNewApp\modules\Volo.Account.Pro\src\Volo.Abp.Account.Pro.Admin.Web\Pages\Account_ViewStart.cshtml.
Steps to reproduce the issue:
NOTE: this application is using ACCOUNT PRO source, IDENTITY PRO source code installed via abp suite.
Create an ABP SUITE application; add the Account pro source and Identity pro sources.Remove the IdentityServer 4 project from the MyNewApp.Web project. in the MyNewApp.Web module file: remove these entries:
[DependsOn(typeof(AbpAccountPublicWebModule))]
[DependsOn(typeof(AbpAccountPublicWebIdentityServerModule))]
Remove Blazor and Maui reference projects added by ABP Suite (not used) Remove the IdentityServer4 Project. Build and correct any remnant references to identityserver4 by removing or commenting out. Build and run the app. Should run fine. PUBLISH the app to a Folder for deployment. Publish for deployment fails with the above errors.
Hi,
you can try to enable SSL to check if it's work
Hi Support; As I mentioned earlier, it works with SSL. It does not work when you attempt to browse the /SettingManagement page via NON-SSL connection. For example: If I browse the new server using the HTTPS url and accept the untrusted self-signed SSL certificate in IIS browser warning, I can connect to /SettingManagement page no problem, even though the browser Chrome/Edge warn that the connection is not private. If I click the advanced button then click the link to the unsecured url, I can navigate successfully.
From there, I can use the /SettingManagement link.
I am perplexed because this link is the only one that fails out of all of the Administration links when it is navigated via non-SSL.
Was hoping you could shed light on why this is an issue for only this one resource link.
Meanwhile, I will use our internal CA server to generate a trusted certificate for this server so that it may continue being used uninterrupted.
Thank you for looking into this matter.
There are no errors. I think Chrome or EDGE is actually passing an XHR POST that is not hitting the generated proxy script.
The main differences: The internal site is not using SSL/TLS - is there a browser reliance on SSL for AJAX for cross site scripting? is there a launchsettings.json that needs to change? Browser shows /MYWEBAPP/_bundles/Pages.SettingManagement.Components.EmailSettingGroup.Default.ACFAD1EB35F39 in the working application.
In the moved application, no references to the PROXY scripts are showing.
headers: Request url: https://mysite.mywebsite/myapp/SettingManagement?handler=RenderView&id=Volo.Abp.EmailSetting show up in the working web site.
In the local site I am not getting this far. Is SSL required for the SettingManagement piece?
Id ApplicationName UserId UserName ExecutionTime ExecutionDuration ClientIpAddress ClientName ClientId CorrelationId BrowserInfo HttpMethod Url Exceptions Comments HttpStatusCode ExtraProperties ConcurrencyStamp
5CC515ED-16B5-395A-C7F7-3A13FC87439C MYWEBAPP.Web 3C4F055A-9E56-8450-4B9A-3A0D47AB47DC admin 2024-07-25 07:45:12.7315718 0 10.22.168.190 NULL NULL 8acdf5632a70446588eb614033bd80ab Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 POST /SettingManagement NULL 400 {} ded99a5c4b7d470091cc7d2eb07aa5e8
45222F8B-D0A5-1A02-A199-3A13FC7954F1 MYWEBAPP.Web 3C4F055A-9E56-8450-4B9A-3A0D47AB47DC admin 2024-07-25 07:29:59.6648106 0 10.22.168.190 NULL NULL b1f057e368344f8ea5eaa1d8f20289b4 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 POST /SettingManagement NULL 400 {} cb2faf4b2fb74941aff4bd14931b661d
6F288DF8-EC60-ADBE-2FE4-3A13FC790C3C MYWEBAPP.Web 3C4F055A-9E56-8450-4B9A-3A0D47AB47DC admin 2024-07-25 07:29:41.0522510 1 10.22.168.190 NULL NULL 0dd3a362bac54001ac70ffc944df70b4 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 POST /SettingManagement NULL 400 {} 35b2dccf6fd041519b6a2479f648696b
3BB8A0CB-BAB7-B59D-9494-3A13FC7901E0 MYWEBAPP.Web 3C4F055A-9E56-8450-4B9A-3A0D47AB47DC admin 2024-07-25 07:29:38.3999505 1 10.22.168.190 NULL NULL 54ffc8c26aee47dbada26c796be409ac Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 POST /SettingManagement NULL 400 {} 6c6c16f438eb4e5aa3ad8c487cae03c4
DB32A4A6-D22B-6F00-90F1-3A13FC78F81B MYWEBAPP.Web 3C4F055A-9E56-8450-4B9A-3A0D47AB47DC admin 2024-07-25 07:29:35.8987819 0 10.22.168.190 NULL NULL 055f04475fd84bc5b7e10d1992e5eb1a Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 POST /SettingManagement NULL 400 {} 18e31554eed640ac882d381c3706049a
95189E19-588F-260A-1A28-3A13FC78EC21 MYWEBAPP.Web 3C4F055A-9E56-8450-4B9A-3A0D47AB47DC admin 2024-07-25 07:29:32.8331461 0 10.22.168.190 NULL NULL b653d3d515094b938c44b75a89892e23 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 POST /SettingManagement NULL 400 {} 180e0c2559ca4a9097a449ceee980b5b
EA656637-95DC-4434-C8FA-3A13FC78E014 MYWEBAPP.Web 3C4F055A-9E56-8450-4B9A-3A0D47AB47DC admin 2024-07-25 07:29:29.7474094 1 10.22.168.190 NULL NULL 84cfebd98201432a9d0eb764ea1dbd22 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 POST /SettingManagement NULL 400 {} 430321663121486cafad781d36508020
HI，
Could you share the error logs?
When you say error logs, do you mean the logs stored in SQL server, or logs stored in the Log folder (none are generated in logs folder)?
NOTE: this application is using CHAT source, Forms source and File Management source code installed via abp suite.
Create an abp suite application and publish to a subapplication on Windows 19 server IIS with a /appname url like https://appserver.host.org/subapp
move the application to a new server
The new server is not using ssl as it is internal.
Setup the internal server and login with same credentials used on the SSL server.
Everything works fine.
Navigate to Adminstration=>Settings
On the newly minted internal server I get this error: A Sweet alert Error popup appears with this message. An error has occurred! Error detail not sent by server.
Browser debug shows Error?httpStatusCode=400 Type: xhr
URLs in Fetch/XHR: http://myiisserver.somesite.local/subapp/SettingManagement?handler=RenderView&id=Volo.Abp.EmailSetting next an error Error?httpStatusCode=400 Type: xhr Then http://myiisserver.somesite.local/subapp/SettingManagement?handler=RenderView&id=Volo.Abp.FeatureManagement
The original server, still works although it is pointed to a different database. The application files are a complete copy of the external server. The internal urls in appsettings.json were changed to the server urls for the internal server on the new internal server.
Everything works except the settings management. I tried this with a new app and moved it to a different server and ended up with the same problem when it came to setting management. Is there a change I am missing in the database or config files after moving to a new server? Thank you for looking into this issue.
Greetings; Thank you for your quick resolution to this issue. I implemented the suggested changes in the web module and removed the reference to identity server. Login is now successful. I consider this particular issue closed. Thank you.