Activities of "improwise"

It used to be that at least ABP Commercial came with full (or at least good) support for Docker, including multi stage Dockerfiles with support for Docker Compose etc. But this does not seem to be the case anymore, the included Dockerfiles are very minimal and isn't even recognized by Visual Studio as Dockerfiles it seems. They also does not seem to work so you can publish to Docker Hub etc. (as Visual Studio claim there is no Dockerfile)

Even finding Docker in the current documentation is hard, we've only been able to find it mentioned in the 8.1 documentation and that seems to be outdated now, for example the build-images-locally.ps1 mentioned there does not seem to exist anymore

https://abp.io/docs/commercial/8.1/startup-templates/application/deployment-docker-compose?UI=BlazorServer&DB=EF&Tiered=Yes

Have tried to find information about this change including updated documentation for the changes that have been made but not found it so:

1. What is the current support in ABP for Docker?
2. Where can we find updated documentation?
3. What are the recommended best practices to use Docker with ABP for both development and hosting (besides the stuff on how to use Docker with .NET in general)?
4. If the previous support for Docker was removed (again, besides .NET support in general for Docker), why was this?

You can of course build your own Dockerfiles from scratch etc. but my questions here is about what support you get out of the box for Docker in ABP.

Also created an issue on GitHub for this, but the answers might be different between the free and the commercial version of ABP.

https://github.com/abpframework/abp/issues/21057

Thanks.

After updating my project to 8.3.1 and 0.9.1 for ABP Studio, codemirror Error is popping up. My fix was to add the code mirror v5 files from codemirror's website to my main web app wwwroot/lib/codemirror folder. Then everything started working again. I must admit I am getting extremely frustrated going from a working project to one that completely fails everytime I update or add source code. It is costing many,many hours of development downtime trying to figure out what just broke? I like ABP and Studio, I would really like the product if I wasn't constantly beta testing everything.

I share your concerns about ABP Studio, it seems really promising but also like it is not quite there yet to use for stable production projects. Which creates a kind of weird situation with old stable CLI being phased out and ABP Suite being gimped so you can't create new projects with it.

What is the status of this now?

Microsoft.AspNetCore.Authorization.DefaultAuthorizationService: Information: Authorization failed. These requirements were not met:
PermissionRequirement: SettingManagement.Emailing
Microsoft.AspNetCore.Authorization.DefaultAuthorizationService: Information: Authorization failed. These requirements were not met:
PermissionRequirement: SettingManagement.TimeZone
Microsoft.AspNetCore.Authorization.DefaultAuthorizationService: Information: Authorization failed. These requirements were not met:
PermissionRequirement: AbpAccount.SettingManagement
Microsoft.AspNetCore.Authorization.DefaultAuthorizationService: Information: Authorization failed. These requirements were not met:
PermissionRequirement: AbpIdentity.SettingManagement
Microsoft.AspNetCore.Authorization.DefaultAuthorizationService: Information: Authorization failed. These requirements were not met:

It's hard to understand this authentication problem, can I see your authserver configuration?

Considering that the last post was a year ago, I would imagine that they either have found a solution or given up by now :)

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.