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)?
13 Answer(s)
-
0
Hello, first of all, sorry for the late reply, I missed this question.
When I create a template with ABP Studio or with the new CLI I see the following solution structure (changing on the configurations selected):
As you said, this structure was different in the old template system and we changed it thinking that this would be more advantageous in the new template system and we adapted Suite according to this change. Therefore, you should not have any problems when generating code with Suite because our expectation is that the new templates are 100% compatible with Suite. I would like to ask a few questions to make your question more specific.
Are you having trouble with a specific case? or Do you think any documents are missing or incorrect?
-
0
Thanks for responding. My initial reaction to this was that it was a bad thing for a few reasons
- I did not expect the change as I have not seen anything communicated about it
- It mixed up .net with angular and react, basically making the latter part of the former instead of being independent
- It creates one big repo for everything (don't remember if that was the case before, but I think it wasn't). That in itself should still be possible with the old structure as well.
- I was (and still am) concerned about if these changes are backwards compatible, and if ABP Suite would be able to support both the old and the new structure, like if we install latest ABP Suite and then tries to open and older solution.
That said, I would imagine that if this isn't a but (which does not seem to be the case), there should be good reasons behind the changes and there might be advantages to it that I have simply missed. This is mainly why I want to know WHY things have changed and what improvements you think it will bring. So, I am not saying this is bad, more that it was unexpected and that I don't see the obvious reasons for it (and still doesn't), that does not have to mean it is a bad thing though :)
Regardless, unless I have just missed it and it does exist, making a change like this without communicating it I feel is not ideal regardless of what it might bring.
-
0
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
-
0
First of all, thank you very much for your valuable feedback. We rarely encounter such questions, but such inquisitive questions are very valuable to us, so we are grateful to you.
With ABP Studio, we made our templates from scratch, and in this process, we had the opportunity to re-evaluate and change many decisions made in the past as a result of the knowledge and feedback we gained over time. Here are the main reasons that led us to this decision:
- First of all, we prevented duality. There was no folder like
aspnet-corein MVC UI, but there was for Angular. This meant that the location of the files on the ASP.NET Core side was different according to the UI type and we had to constantly consider this in our code generation and other systems. - We want ABP Studio's
abpslnfile and .NET'sslnfile to be aligned so that we don't need to go above solution root for angular or other projects. - Finally, since we accepted ASP.NET Core as the main (default), it made more sense to have it at the root.
Apart from these, it has no serious advantages or disadvantages. This is how we decided and implemented it, while making all ready-made templates from scratch, we thought about this from scratch and decided like this.
However, despite all this, we apologize to you that there is a communication problem here. We have been working on this kind of change for quite a long time and from time to time we have announced it a little bit with community events and social media posts as far as I know, and we tried to support this process with blog posts close to its release. Despite all this, I agree with what you say, we needed to produce more content on this subject. I will try to constantly mention this matter in the decisions we will take for the future, I am sure we will achieve a much better result. Thanks again for your feedback.
Regards.
- First of all, we prevented duality. There was no folder like
-
0
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
-
1
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?
-
0
@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.
-
1
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.
-
0
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.
-
0
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.
-
0
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.
-
0
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.
-
0
Thank you for your detailed response and for sharing your thoughts on the mono-repo vs. multi-repo approach and the new folder structure. I understand that these changes can feel a bit different, especially when transitioning from what we're used to, like the previous folder structure.
We’ve had a thorough discussion, and I believe we’ve covered the key aspects. Ultimately, it comes down to personal preferences and workflows, and I understand that the new folder structure may not fit everyone’s needs perfectly. That said, we’ll certainly take your feedback into consideration.
Thanks again for the constructive conversation!
Regards, Berkan
Closing the issue. Feel free to re-open or create a new issue if you have further questions.
