With Blazor comming close to build once - run everywhere with MAUI and Blazor Hybrid, wouldn't it be nice with just one "Blazor" template for which you could select which Blazor UIs (WASM, Server, native) you want and then that generated components were but into a Razor Component Library instead?
Perhaps from the start it could just be WASM + Server but with MAUI becoming more mature, perhaps become WASM + Server + MAUI. AFAIK, unless you start using Native controls, the Blazor components themselves and their markup should be very similar regardless of hosting environment.
Not sure what amount of work this would mean, but just floating the idea in general.
This was also posted as https://github.com/abpframework/abp/issues/13710 and has two votes on there which should count, one of them I believe is from a core team member :)
This is the only thing I've been able to find about this:
"12.2 ABP Commercial products cannot be publicly shared or cannot be licensed as an open-source product without asking written permission of Volosoft Bilişim Anonim Şirketi. "
hi
You can't make public the
commercialsource code or packages.https://commercial.abp.io/faq
Hi,
I've read that already but I don't think it really answers the question. I also don't see anything in there about distributing the applications to clients (with or without the source code) like when you build a system for a client. Ie the FAQ seems to be lacking information about runtime vs development time etc. We have just assumed that it is probably working in the same way as other tooling, like development time licenses for DevExpress, Telerik etc.
(We have yet to actually build and distribute a real application with ABP, but we plan to do it in the future).
hi
You just need to add the
commercialpackages to your project. You can check thecommercialtemplate project.
Does this mean that we can include commercial packages in open source then on GitHub etc without breaking the license? Will it still be something that a non ABP customer could still compile even though they probably could not use it? Mostly interested in the legal aspects here so that we don't break any rules etc. Thanks.
This is an interesting question. I guess the actual question here is it is possible to generate a new CRUD GUI based on existing CRUD business layer, which is something we have also pondered but never tried. Will start a new project soon though to evaluate pros and cons of different GUI solutions, and in that, we would like to build out several different GUIs in Angular, Blazor etc. but still use the same ABP solution for backend stuff.
Good question. I would also like some feedback in general of how to use ABP Commercial in an open source project, if it is all doable and if so how to do it without breaking any licenses etc. There might already be some article etc on this but haven't seen anything and thought about it from time to time.
One alternative way could perhaps be to add AutoMapper mappings so that you could convert between the generated DTOs if that is what you need, not sure how much extra work this would be though.
OK, thanks.
One reason why this might be a good thing is if you want to use some other component library like DevExpress, Telerik etc. but still use ABP Suite to generate some boilerplate for it. Those components usually have just one DTO for all CRUD operations which might not be best practice but then again, the real world rarely is :)
Of course, this is still doable but it would require changing more of the generated code which would not be necessary if there was an option to use a simpler DTO structure.
I would guess that many customers of the Commercial version would build enterprise applications, for which you would normally have higher requirements regarding "data components" than typica free component libraries like Blazorize can offer.
Not sure if there is a better way to submit suggestions for improvements, as GitHub Issues are only for the non commercial version? Don't want a suggestion to lower our number of support tickets.
ABPSuite by default creates DTOs with different DTOs for each AGUD/CRUD operation. While this might be the most fancy solution, in many cases, just having one simple DTO for all operations is sufficient and also much easier to maintain for simple projects.
Suggestion, consider implementing an option in ABP Suite to use one simple DTO for all AGUD/ CRUD operations instead of separate ones.
BTW, the link in this sticky isn't working
https://support.abp.io/QA/Questions/954/We-are-listening-to-you
Hi @improwise, I've just created an angular application and followed the steps that you've provided, but I didn't get any error and I could successfully create a migration even without specifying
-Contextparameter on Package Manager Console.And also I could successfully run the Angular side by following the documentation.
Did you upgrade your application to v5.1.4 and what is your ng version?
Not sure why but after having reinstalled Visual Studio, the migration problem seemed to go away. Still getting this though:
An error occurred while accessing the Microsoft.Extensions.Hosting services. Continuing without the application service provider. Error: Unable to build IHost
We never really bothered with angular for this sample, but it seems it is using Angular 11 in the samples so I guess it hasn't been updated in a while.