not really a workable solution i'm afraid
Why not? We are using a similar approach without any issues.
the solution has 15 projects integrated in it, they are all interconnected as microservices using event based architecture also using common appsettings for multi-tenant processing. unwinding this is not an option as mentioned these projects also make use of the data layer definition from radzen server. #nothingIsEasy
I still don't get it. Is the Blazor application using all other 14 projects from your solutions? I can't imagine it to be using the API project directly - it would be a major design flaw.
no, the blazor application is not using these directly. they are included as they are using assets from the blazor application
It sounds that you can create a copy of your existing solution and remove the API project from it. If this solution builds and has only one web project Radzen Blazor Studio should be able to use it normally.
If it doesn't build - you can try removing any other projects that use code from the API project.
That's the only resolution I can suggest.
i think we are realistically at an impass....
i really want to migrate onto and use Blazor Studio, but this is a blocker unless there is a change in how you determine what is the server project.....
i think i'll have to swap the licence to a Radzen one instead of Blazor S.
quite frustrating....
Did you try my suggestion? What happens if you try to open a solution without the API project? I don't see why having two solutions won't work.
We can't swap licenses I am afraid. We can refund you instead. Keep in mind that we don't plan any major updates to Radzen Studio. For example we won't migrate it to use Radzen.Blazor 5.0.
i'll see if i can split it in some way, but honestly this should have just worked.....
the design i have across the projects is that each project uses a common appsettings. i.e. define once and use many
then we also include the server models and data, so they can easily connect to and use the defined data services... define once use many
breaking this would have some faily big deployment implications that i don't want to unwravel
The second solution I am referring to would only be used by Radzen Blazor Studio. You can keep your existing one without any changes and use it in Visual Studio and deployments. Just create a copy of it and remove the API services project (from Visual Studio) then save the solution and open it in RBS.
yeah but that then means i have to manually link up the APIServices project on every deployment
do you want to raise this issue up with the dev team and see what they have to say?
honestly i'll either be using an updated version of blazorS or revert back to Radzen understanding that i'll be limited in terms of components moving forward
No, it doesn't mean that - you will keep your existing solution and use it as you currently are. The second solution (without the API services) would only be needed by Radzen Blazor Studio.
I happen to be the developer maintaining that feature. Consider it raised already.
No idea what blazorS is.
awesome thanks....
BlazorS = Blazor Studio 
I might be able to pull the APIServices into a separate project as it's really an API frontend... i THINK the only dependency is the shared appsettings.JSON
i'll have to do a review to confirm.... i'll check from my side
There still seems to be a misunderstanding. Here is what I suggest:
- Create a copy of your solution.
- Open the copy in Visual Studio.
- Remove the APIServices projects from the solution and rebuild it. It should build successfully unless any other project has a reference to APIServices. If such projects happen to exist you would need to remove them as well. If other projects have the SDK
Microsoft.NET.Sdk.Web- remove them as well. - Save the solution.
- Open the solution in Radzen Blazor Studio (RBS).
You can use the solution copy to infer the database and perform design time activities. Then use the existing solution for deployment and in Visual Studio. The shared appsettings.json file won't be affected in any way.
hey @korchev,
i have created a new solution and moved the APIServices successfully into it, the only coupling between that and the governance solution was thankfully the appsettings.JSON to not too invasive.
i re-built the application in the governance solution after removing APIServices
i then opened RBS and had access to two data sources (what i would expect to see)
i then did an infer of the datasource just to check things off and i'm whacked with heaps of compile errors.
this is preventing the BRS from loading the razor pages
for example this parameter would have been declared as a set parameter in Radzen
so i thought i'd run the application to see if there was a code build / generation required... that didn't help....
now i can't read the data sources again...
the change from Radzen to RBS has not been a smooth one... is there something i'm missing here??? is there something i need to do to get this to compile and work just like Radzen does ?
it looks like the infer DB has failed on a bunch of tables and now because it's jammed up i can't look to re-infer the data or amend any of the pages
Radzen Blazor Studio uses a different naming strategy for database entities. I suspect this is what is happening. The screenshots from the code are not clear as you didn't show how the old code looked like.
I suggest creating a new data source with the same name and trying different naming settings.
no luck im afraid... i think it's at that point that after removing the problem API Service project, i still can't run a database update in RBS that i look to continue with Radzen and look to re-build in RBS at a later time
right now i need to get the current build uplifted to mult-tenant (individual databases) and deployed to Azure.
i can't waste any more time playing with this
@korchev how shuold we proceed with a refund and a re-purchase of a Radzen licence?
I have refunded your purchase. It may take a few business days for the funds to appear in your statement. Be aware that no major updates are planned to Radzen Studio (.NET version updates and or Radzen.Blazor updates).
thanks @korchev, for the time being it will have to do, as we will use the same underlying databases, etc. the uplift will probably be a bit painful time wise but not impossible.