For whatever reason, we had problems updating to the latest 8.3.1 version. Even after uninstalling and then doing a "dotnet tool install -g Volo.Abp.Studio.Cli" it still installed ABP CLI 0.8.3 (Beta) but still claimed it was the latest version of the CLI.
dotnet tool update -g Volo.Abp.Studio.Cli Tool 'volo.abp.studio.cli' is already installed.
abp cli check-version [13:49:48 INF] You are running the second generation of the ABP CLI. If you're interested in the legacy CLI, see https://abp.io/new-cli 📌 ABP CLI 0.8.3 (Beta) 📌 You are using the latest ABP CLI.
The old CLI can be installed as 8.3.1 though
dotnet tool install -g Volo.Abp.Cli You can invoke the tool using the following command: abp Tool 'volo.abp.cli' (version '8.3.1') was successfully installed.
Should we just wait?
BTW, do we still need to setup ABP as a Nuget Package Source if if so, what should it be? Same for free and commercial?
As it seems a bit uncertain how much attention posts in the "Bugs & Issues v8.3.x" thread gets, and I feel this is an important and kind of urgent question, I post it in a separate ticket. This is especially true if it isn't an intended change as it would most likely mean that solutions created now would not work with future updates of ABP Suite / ABP Studio.
What is the reasoning for the new directory structure of solutions created with ABP Suite / ABP Studio? It used to be that you got a folder for each "application" under the main directory like "MyApplication" = > "aspnet-core", "angular", "react-native" etc but now it seems to be that angular and react-native folders are moved within what used to be the aspnet-core folder. So now you have SLN file and "test" folder for aspnet-core stuff right next to your angular and react-native folders, even though they are stand alone applications (kind of).
Is this even an intended change or some kind of bug? There might be advantages of this as well, like using only one repo for everything etc (which could be both good or bad depending on personal preference).
You can of course change this after creation, but I would imagine that doing that would break code generation etc?
Is there a guide on if we want to tidy this up a bit and still make sure that ABP Suite etc works (and that won't break with updates etc)?
Hi Support Team,
Let me know when the issue will be fixed so that we can plan to deploy our application.
Best Regards
Not ABP Support but have you looked into if this is an ABP or Angular problem? Have never had time to do that myself, but recall that the warnings included links to Angular errors so might be worth checking into if you have not already. Please share any findings into how to solve this if you find them. Thanks.
Thanks!
What is the reasoning for the new directory structure of solutions created with ABP Suite / ABP Studio? It used to be that you got a folder for each "application" under the main directory like "MyApplication" = > "aspnet-core", "angular", "react-native" etc but now it seems to be that angular and react-native folders are moved within what used to be the aspnet-core folder. So now you have SLN file and "test" folder for aspnet-core stuff right next to your angular and react-native folders, even though they are stand alone applications (kind of).
Is this even an intended change or some kind of bug? There might be advantages of this as well, like using only one repo for everything etc (which could be both good or bad depending on personal preference).
You can of course change this after creation, but I would imagine that doing that would break code generation etc?
Is there a guide on if we want to tidy this up a bit and still make sure that ABP Suite etc works (and that won't break with updates etc)?
I also want to know why change the structure, difficult to maintain code changes history in git
I am a bit unsure what the purpose of these "Release X" threads are and if someone from ABP is actually monitoring them. ABP really needs to implement something similar to GitHub Issues for Commercial customers so you can track progress of active items like you can for the open source version.
hi
https://github.com/abpframework/abp/issues/20864#issuecomment-2378895635
This is about the ABP Framework and solutions created using that, not the ABP website :)
It seems ABP is missing several languages that has been translated, some of them even months back, but they still do not seem to be included in ABP releases. Created an Issue about it over att GitHub but would like to highlight this as several people, including me, have probably spent some time it translating this and it would seem like a quite simple job just to include them as they have already been merged into /dev. Obviously, being able to provide an application in the correct language is kind of a big deal when targeting local audiences/clients. Also, not sure if there are differences here between ABP and ABP Commercial, as the later includes additional modules etc. which we are unsure how to translate as they are probably not in the public repo.
https://github.com/abpframework/abp/issues/20864
Or are we missing something here that we need to do ourselves (besides translating and submitting a PR)?
If it had just been one or maybe a few files we could have done it manually for the time being, but these are quite a lot of files and I am not sure if you can even override translations for commercial modules etc.
Thanks.
I guess this can be closed now?
Note sure if it is related but it seems like ABP Suite / ABP Studio for whatever reason have changed the folder structure and no longer creates a aspnet-core folder for .NET stuff, instead it just puts angular and react native folder right alongside SLN files etc. in the SOLUTIONNAME folder where there used to be an aspnet-core folder. Either that or it breaks when putting a "." in the solution name like CompanyName.Project but that has worked before.
Wrote about that in the 8.3 thread but no feedback on why yet.
Honestly, not due to ABP but we have given up on MAUI for now even tough we are .NET people. Would really like to use it though if/once it becomes ready for prime time including tooling that does not break as soon as you try to install Firebase packages etc. The dream to finally get rid of JS continues to be a dream but one day :)
But that is probably another discussion, but that is the main reason we did not continue trying to get it to work properly with ABP. I hope you manage to get it sorted for your needs.
Thanks for the heads up, we've had great success with Blazor Server and the ABP libraries that utilise that architecture, with the rapid development due to not having to duplicate all dto's in C# and javascript and the magic SignalR connection between server and browser, but our mobile journey is just beginning.
We seem to have hit a very large brick wall at the moment, and we really want to utilise HTML, CSS and razor pages rather than .XAML......but we shall have to see how this all ends up!
Xamarin Forms AFAIK is EOF now so it's all MAUI. Don't think that neither ABP nor Blazor is the main problem here for the time being. Would be really nice to be able to reuse Blazor though all the way.
