On Angular, mobile layout, the page scroll is preserved between pages where it should not :
Confirmed on https://demo.abp.io/ which I presume is the latest version
didn't understand the problem here. can you show the correct / expected behaviour?
I believe that what is meant is that when navigating to a new page, it should start from the top rather than at the scroll position of the previous page.
You mentioned that there are several disadvantages compared to the previous approach, but I would appreciate some clarification on this.
For instance, in the scenario where we didn’t use a mono-repo setup, you would move the Angular folder to a new repository. Has this process changed with the new template? Or do you find it more challenging to set up CI/CD pipelines with the new folder structure? What specific aspects are causing more difficulties compared to the old approach?
Please know that we thoroughly considered these factors during the design phase, as the new structure is a significant change for us. If there are substantial disadvantages, we are open to reconsidering the folder structure. However, most of the issues raised so far were already present in the previous setup.
While customizing the folder structure might seem like it breaks the 'intended workflow,' it doesn’t pose any issues for future updates or maintaining the template, as we're only changing the folder structure without affecting core functionalities.
In summary, both approaches have their pros and cons, but we opted for the current design based on the reasons I mentioned earlier.
Lastly, the ABP framework is inherently more aligned with a mono-repo setup. For example, the microservice solution leans towards this approach by default. However, if preferred, it's straightforward to work with multiple repositories. You can find more information here: https://abp.io/docs/latest/solution-templates/microservice/mono-repo-vs-multiple-repository-approaches.
Thanks for responding.
We've mostly used ABP for Blazor stuff before which more naturally is in the same repo as it is .NET so must admit that I have not given to much thought to the multi repo approach until now. But as we are currently doing an Angular ABP project, it pros and cons of a mono repo became more obvious. I am still on the fence here about that, as with regards to a mono repo, I can see both pros and cons. Which is what probably depends a lot on size of team, if you have dedicated people working with only parts of the application etc. From an ABP point of view I can understand how a mono repo could be beneficial, especially with regards to code generation etc.
With regards to CI/CD, it seems like seems like most "deployment tools" are made so that you have more dedicated repos, like when identifying what tech a certain repo have to automatically configure deployment, build paths etc. I am not really a DevOps expert myself so there might be a skill issue here, but at least it seem to require more manual configuration with everything in one repo.
When it comes to folder structure, I just can't come to terms with this new setup and it mixing folder like ".vs" and "etc" from the .NET solution with "angular" and "react native". It just feels wrong to me, and I would much rather having something more along the lines of the old structure. Now, you can of course argue how much of a problem this is, being that you would normally access the files using VS, VS Code etc which would mostly hide this unless you go poking around in the file system. On the other hand, as mentioned before, I can't really see any obvious advantages of this change, at least not to me as an ABP user, even though I can understand that there might be for you as ABP developers when building ABP Suite, Studio etc.
It would seem that if you want to create separate repos instead of a mono repo, for whatever reason, this new folder structure would make that a bit more challenging with one repo being in a subfolder of another etc. I would imagine that moving folders around to simply multi repos would probably break code generation etc. even though I have not tried this myself yet.
It seems like the when using the "old" CLI, it still creates solutions using the aspnet-core folder with react-native etc folders being at the same level as the aspnet-core folder. Does this mean that ABP Suite now supports both folder structures, and if so, is there a way we can choose ourselves which one we prefer?
Yes, the Suite supports both folder structures. Only when the template itself is first created, it is created in a different folder structure than before. So, we expect you to have no problems with the Suite. If you are, you can create a new question with the details of the problem you are experiencing.
Unfortunately, the feature of choosing the structure of the template as you mentioned is not part of our plans. However, we have developed ABP Studio's infrastructure to support custom templates. This means that developers will be able to create their own templates. But we need to work more on this feature, so there is no deadline for this and it is not prioritized. However, you can manually perform the related changes in the template you created for now and there should be no obstacle to this.
With the support being there for both "setups", I think you need to consider again if the new one is actually better than the old one. Having played around a bit with the new structure for 1-2 weeks now, I must admit that my initial impression still stands - I don't really see any obvious advantages to the new structure, but quite a few disadvantages.
Customizing templates is of course an option, but from past experience, I find that doing so and breaking "the intended workflow" often leads to a few challenges when it comes to future updates, maintaining templates etc. ABP to me is a highly opinionated framework, and I feel that you as a developer either has to accept the ABP way of doing things, or you should perhaps look elsewhere. Personally, I really like opinionated solutions in most cases, as my technical and business requirements never seem to be all that special as to warrant going your own way.
I also don't like this change. We have angular in a separate repo. Is there a way to make the ABP Solution work with the "old" folder structure?
Have to agree with this one after having tried out the new structure for a while, having everything in one big repo cause a lot of confusion, especially if you would have different people working only on different projects etc.
Like for the time being I can't deploy to Azure using Microsofts extensions in VS Code as they don't seem to like that I have uncommited changes in the repo, which might have been fine if it wasn't for the fact that those changes are in the backend project and completely unrelated. Also, setting up Ci/CD pipelines etc might also be a bit of a struggle I would imagine with everything in one repo.
This part you can probably fix outside of ABP by deleting default git repo and create separate ones yourself, but not sure if that would cause any additional problems with ABP Studio in future updates etc.
The old CLI is legacy, and we are not adding any new features. This version is for the ones who have old ABP projects and don't want to upgrade (basically for backward compatibility).
You need to use the new CLI and Studio.Where did you see the recommendation to use the old CLI version?
Hi,
Thanks for clarifying this.
It is basically the first thing you see browsing ABP on GitHub (it should probably be updated with a ".Studio")
https://github.com/abpframework/abp
(The link below seems to point to the new API though)
Edit:
Also, there seem to be no mentioning of ABP Studio on that page either, which as I understand it is now available for non commercial version as well.
@berkansasmaz
It seems like the when using the "old" CLI, it still creates solutions using the aspnet-core folder with react-native etc folders being at the same level as the aspnet-core folder. Does this mean that ABP Suite now supports both folder structures, and if so, is there a way we can choose ourselves which one we prefer?
Thanks.
I updated my Studio and Suite to the latest
And I couldn't see any errors like versions conflict etc...
can you pls check it with the latest version @improwise
Hi and thanks for responding,
It seems both ABP Studio and the new CLI has been updated now which was not the case when we tested this a few days ago (after you emailed about the new release of 8.3.1). ABP Studio now seem to have installed "ABP CLI 0.8.4 (Beta)" instead, not sure if that is supposed to be the same as the 8.3.1 even though it says beta?
I find it quite confusing with these 2 separate CLIs which are apparently both being maintained. Depending on where you look, ABP either recommends using ABP Studio and the new CLI, in other places, like GitHub, the old CLI is instead recommended and the new CLI isn't even mentioned. In this case, the old CLI was obviously updated before the new one.
What is the recommended approach to create production ready ABP solutions as an ABP Commercial customer?
Thanks.
Thanks for letting us know more about the process and thinking for these changes.
I've not used MVC in many years so never considered that, but I guess that could be solved with just a "dotnet" folder.
I am still unsure about this change, or rather how it was implemented, as an alternative to just having a root folder with a folder for "dotnet", "angular", "reactnative" etc. and the SLN files, .git folder etc could be there instead. It also feels a bit off to to have angular / reactnative folders right next to a folder for tests and a README file, both which I assume are just for the dotnet stuff (not in front of dev computer right now so can't check). One middle way could perhaps be to allow some kind of customization for this, like options when new solutions are created.
But that it just my opinion, would be interesting to hear from others as well. Also a confirmation that this new folder structure would work with older ABP solutions as well would be welcome (if that is the case).
Thanks
Why start template not published when a new version released?
it is a long time can not get the template 8.3.1 after it released, abp cli and abp studio also upgraded to latest version.It seems like something weird is going on with the CLIs, see my other posts above. ABP needs to comment on this. Short version seem to be that in order to use latest version of ABP, we need to stop using ABP Studio and the new CLI and return to old CLI and ABP Suite. This assuming you can still actually create new versions in that with the old CLI installed. If not it seems we are back to only using the old CLI to create new solutions with the latest version of ABP :)
Edit:
Just tried to create a new solution with ABP Suite having only the old CLI installed (8.3.1) and you can only add existing solutions, not create new ones. Creating it using the old CLI you can then add it to ABPU Suite it seems, but perhaps not ideal DX.
@improwise Sometimes I respond to the feedback, sometimes not. But I'm reading all the feedback and reporting to the team.
Thanks for responding.
And how would we know if anyone at ABP is planing to do something about stuff being reported and also follow the progress?
I suggest just adding a new tag "ABP Commercial" to the normal flow of issues on GitHub and this forum can actually be a support forum instead of what seems mostly to be about reporting bugs/problems these days. Should be a win-win for everyone.
Thanks.
BTW, when creating the new solution with old CLI as described here, the old folder structure was still used even for 8.3.1
https://abp.io/support/questions/7844/Bugs--Issues-v83x?CurrentPage=2
