Should the modelsbuilder customtool be maintained by HQ?
I had a discussion with people on and offline about who should maintain the modelsbuilder custom tool.
At the moment the tool is maintained by one person. This means that if a breaking change is done to Umbraco-Cms or Modelsbuilder we are depending on one individual to fix it.
We as an agency only use the Modelsbuilder Api in our projects because it's the most powerful way to work with modelsbuilder. This is also the easiest way to work with models over multiple projects.
The advantages of the tool being maintained by core are:
changes to modelsbuilder could be tested on the custom tool and be discovered before release
in case of a bug in a holiday of the maintainer work can go on and we don't have to wait for a solution or we don't have to downgrade the project just for the tool.
I'm curious what HQ and other agencies' opinions are.
As you know I'm a big fan of the API-mode in combination with the custom tool as well. For me this is the only option I would recommend to people
All the other modes can cause issues.
All the other modes besides api mode require you to be able to run the roslyn compiler if I am correct. Which can be a issue when on shared hosting where it's not allowed to run.
With dll modes you need include the generated dll's in to your source control to have them available on other environments when you deploy. I actually had a issue where I wanted to customize the models and made a mistake. When I clicked the generate button it actually broke my site and wasn't even able to login to the backend.
With App_Models mode you still need to compile the models to be able to use them. So you need to include them in your solution and source control. So there is not real benefit in this mode compared to using the visual studio custom tool.
So i would love this all modes and tools to be supported by HQ. Maybe a first step is to move the repository to the actual Umbraco organisation on github.
Yes...models builder is moved to core...but not the visual studio extension. This causing issues for people on V8. That is why Frans raised this topic.
It is not only in V8 that this can lead to issues but it will also lead to issues when modelsbuilder is changed and no one tests the change on the tool because it's not in scope.
It's the most powerfull way to use modelsbuilder for enterprise customers but its risky to use it because what hapens id Stephan can't or won't develop the tool any further?
That is my main issue. At the moment the tool is broken in V8 in combination with VS2019 and the workaround is nasty:
I think at one point I was having such trouble with DLL mode that I switched the mode to PureLive to get the site to run. Once I resolved whatever the issue was, I was able to put it back into DLL mode with no problem. It was a pretty painless work around.
Along the same vein, is there any way to disable Models Builder[or perhaps have a fallback in place that doesn't cripple the whole website(s) on failure]? I've been toying with making various model updates and I am not finding a very good mode to use.
My experience has yielded the following:
A: PureLive mode will recycle the application pool EVERY time you add/edit your model. Consequently, not the best setting on production as it yields a yellow screen for the first visitor after you make a change to your document Type. Also, no intellisense in Visual Studio, making custom controllers rather cumbersome to do.
B: DLL Mode will solve the PureLive issue by mitigating the issue to when you generate the models in the back end. This causes large issue when you have multiple people developing/maintaining a site.
C: AppData Mode. Haven't tested yet
D: API models. Haven't tested yet, but only because I see almost no difference in it and DLL mode.
I am almost of the mind to only use models builder to build out my models on a development box in a model.dll file and copying that dll up to production where the models builder is disabled. This works great from a developer standpoint, but for someone who maintains models using ONLY the back office, this solution would not be great.
For the alternative, maybe every time the models are generated successfully a backup of the models is created. When the models FAIL to generate, instead of generating out the models, the working models should be restored and an error written to the log indicating that the models failed to build. The only drawback to this that I see is directly related to how well the testing team checks new features that required a model change(not an Umbraco/developer issue, but an issue needing resolved on case by case of the business users of Umbraco).
C. Here models builder will generate the c# files. But you need to take care of the compiling. So you probably need to include them in a Visual Studio solution.
D. I think this more close to AppData than to dll. Think AppData but then integrated in Visual studio.
To me C) & D) is basically the same but you have to use D) if you need the models in a reference project.
Using the custom tool is (or was at least) HQs recommended way of working with Umbraco Cloud? Given that Umbraco Cloud is a core business of HQ the tool probably should be maintained/supported by HQ?
Mmm... the whole purpose of PureLive is to not recycle the AppDomain on rebuild - if that is the case (as in, you see a domain restart in Umbraco's log) then that would be a new bug.
I kinda like the idea of not trashing everything when generating fails, but keep the "old" dll in place, if any. Maybe that can be a feature request on MB's tracker?
All other concerns are valid - figuring out the workflow for generating models is not easy. Each project has its own way. That's why there are many options ;-)
Should the modelsbuilder customtool be maintained by HQ?
I had a discussion with people on and offline about who should maintain the modelsbuilder custom tool.
At the moment the tool is maintained by one person. This means that if a breaking change is done to Umbraco-Cms or Modelsbuilder we are depending on one individual to fix it.
We as an agency only use the Modelsbuilder Api in our projects because it's the most powerful way to work with modelsbuilder. This is also the easiest way to work with models over multiple projects.
The advantages of the tool being maintained by core are:
I'm curious what HQ and other agencies' opinions are.
Frans
Hi Frans,
As you know I'm a big fan of the API-mode in combination with the custom tool as well. For me this is the only option I would recommend to people
All the other modes can cause issues.
So i would love this all modes and tools to be supported by HQ. Maybe a first step is to move the repository to the actual Umbraco organisation on github.
Dave
We are not using the custom tool and API mode because you depend on visual studio solely.
To be honest, I really thought it was maintained by HQ.
IMHO opinion that is a good thing when using Models builder.
Edit : the dependency on VS is a good thing to be clear. All the other modes will get you in trouble some where down the road.
As far as I know it's maintained by Stephan Gay who is on the Core team?
The source for the custom tool is here in case that helps also. That said, the package page says ModelsBuilder was moved to the Core so it could all do with some clarity perhaps to avoid confusion.
Yes...models builder is moved to core...but not the visual studio extension. This causing issues for people on V8. That is why Frans raised this topic.
The customtool is not supported by HQ as made clear in this issue: https://github.com/umbraco/Umbraco-CMS/issues/5399
It is not only in V8 that this can lead to issues but it will also lead to issues when modelsbuilder is changed and no one tests the change on the tool because it's not in scope.
It's the most powerfull way to use modelsbuilder for enterprise customers but its risky to use it because what hapens id Stephan can't or won't develop the tool any further?
That is my main issue. At the moment the tool is broken in V8 in combination with VS2019 and the workaround is nasty:
https://github.com/zpqrtbnk/Zbu.ModelsBuilder/issues/199
Thanks for sharing that link, I was unaware of that conversation.
Hence this topic ;-)
I think at one point I was having such trouble with DLL mode that I switched the mode to PureLive to get the site to run. Once I resolved whatever the issue was, I was able to put it back into DLL mode with no problem. It was a pretty painless work around.
Along the same vein, is there any way to disable Models Builder[or perhaps have a fallback in place that doesn't cripple the whole website(s) on failure]? I've been toying with making various model updates and I am not finding a very good mode to use.
My experience has yielded the following:
A: PureLive mode will recycle the application pool EVERY time you add/edit your model. Consequently, not the best setting on production as it yields a yellow screen for the first visitor after you make a change to your document Type. Also, no intellisense in Visual Studio, making custom controllers rather cumbersome to do.
B: DLL Mode will solve the PureLive issue by mitigating the issue to when you generate the models in the back end. This causes large issue when you have multiple people developing/maintaining a site.
C: AppData Mode. Haven't tested yet
D: API models. Haven't tested yet, but only because I see almost no difference in it and DLL mode.
I am almost of the mind to only use models builder to build out my models on a development box in a model.dll file and copying that dll up to production where the models builder is disabled. This works great from a developer standpoint, but for someone who maintains models using ONLY the back office, this solution would not be great.
For the alternative, maybe every time the models are generated successfully a backup of the models is created. When the models FAIL to generate, instead of generating out the models, the working models should be restored and an error written to the log indicating that the models failed to build. The only drawback to this that I see is directly related to how well the testing team checks new features that required a model change(not an Umbraco/developer issue, but an issue needing resolved on case by case of the business users of Umbraco).
Hi Bryna,
A. You are complety right
B. You are complety right
C. Here models builder will generate the c# files. But you need to take care of the compiling. So you probably need to include them in a Visual Studio solution.
D. I think this more close to AppData than to dll. Think AppData but then integrated in Visual studio.
I wrote a article once where I do an attempt to explain the differences between the different modes : https://24days.in/umbraco-cms/2016/getting-started-with-modelsbuilder/
Dave
To me C) & D) is basically the same but you have to use D) if you need the models in a reference project.
Using the custom tool is (or was at least) HQs recommended way of working with Umbraco Cloud? Given that Umbraco Cloud is a core business of HQ the tool probably should be maintained/supported by HQ?
Regards, Magnus
Mmm... the whole purpose of PureLive is to not recycle the AppDomain on rebuild - if that is the case (as in, you see a domain restart in Umbraco's log) then that would be a new bug.
I kinda like the idea of not trashing everything when generating fails, but keep the "old" dll in place, if any. Maybe that can be a feature request on MB's tracker?
All other concerns are valid - figuring out the workflow for generating models is not easy. Each project has its own way. That's why there are many options ;-)
is working on a reply...