Activities of "improwise"

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.

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.

Unless things have changed very recently, we can confirm seeing the same problem, app would not run without the backend available. In our case, that was not a problem so we never bothered to investigate it further. This is true also with the app deployed to my Android with the backend i Azure stopped.

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)?

The error is here in this generated code where it is trying to assign string values for true and false instead of the boolean values (ie remove '' and it will work). Also, the [Validators.required] should probably be removed as well.

  published: [published ?? 'true', [Validators.required]],
  notificationOnPublish: [notificationOnPublish ?? 'false', [Validators.required]],
  

• ABP Framework version: v8.3
• UI Type: Angular (probably more)

ABP Suite incorrectly handles checkboxes, at least when using Angular. It marks the controls as required (*) even though the form can submit regardless of value (selected / not selected) which in correct but it should not be required. It also gets the default value wrong, making it selected for new items even though you have selected the opposite. There are no options in ABP Suite for not required, nullable etc for Boolean values (which renders as checkboxes).

Correct behavior should be that it is not required (at least not unless you can select that in ABP Suite) and also that default value is what you tell it to be in ABP Suite.

Can confirm that we are seeing the same thing for newly created 8.3 Angular app. Have not checked if it is an ABP or Angular problem yet though. We are also getting the same number of warnings, ie hundreds of them just for a single page.

As you kindly pointed out, I was unable to replicate the same issues. I regard the provided GIF as a helpful showcase to demonstrate the situation more clearly.

Hi,

Don't think that I pointed out anything about you ability to replicate this. it also looks like the page width of your browser window in the included GIF is more than 1200 px but that is of course hard to tell. You also seem to use dark mode which could perhaps have an impact on this as maybe could scaling. Please also note that we were unable to reproduce this bug as soon as we made the browser window +/- 10% from 1200 px.

• ABP Framework version: v8.3
• UI Type: Backend

When using ABP Suite to add entities / properties, the test cases generated incorrectly tries to add non filterable properties when calling Get methods which will lead to compile errors as those no filterable properties are not parameters of the get method(s).

Hello, I have investigated this problem by the following the same pattern. Your problem should have occurred only for @abp/ng.feature-management package depending on the optional package selection. Also, thank you for reporting the related deprecations. These issues will be resolved by the next release where you can find details here.

Hi,

Thanks for looking into this. Good to know there will be a general fix coming but will that also fix the deprecated packages warnings? At least they remained for the solution we did as mentioned above. It seems that a fix for that is already in the /dev branch but for whatever reason never made it into 8.3

Please refund ticket as this is now a confirmed bug.

Thanks.