Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at

  • Frans de Jong 522 posts 1761 karma points c-trib
    May 27, 2019 @ 10:09
    Frans de Jong

    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.


  • Dave Woestenborghs 3272 posts 11111 karma points MVP 5x admin c-trib
    May 27, 2019 @ 10:57
    Dave Woestenborghs

    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.

    • 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.


  • Damiaan 438 posts 1290 karma points MVP 3x c-trib
    May 28, 2019 @ 11:44

    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.

  • Dave Woestenborghs 3272 posts 11111 karma points MVP 5x admin c-trib
    May 28, 2019 @ 13:25
    Dave Woestenborghs

    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.

  • Simon Dingley 1427 posts 3327 karma points c-trib
    May 28, 2019 @ 11:57
    Simon Dingley

    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.

  • Dave Woestenborghs 3272 posts 11111 karma points MVP 5x admin c-trib
    May 28, 2019 @ 13:26
    Dave Woestenborghs

    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.

  • Frans de Jong 522 posts 1761 karma points c-trib
    May 28, 2019 @ 13:31
    Frans de Jong

    The customtool is not supported by HQ as made clear in this issue:

    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:

  • Simon Dingley 1427 posts 3327 karma points c-trib
    May 28, 2019 @ 13:35
    Simon Dingley

    Thanks for sharing that link, I was unaware of that conversation.

  • Frans de Jong 522 posts 1761 karma points c-trib
    May 28, 2019 @ 13:36
    Frans de Jong

    Hence this topic ;-)

  • Bryna 67 posts 231 karma points
    May 28, 2019 @ 20:01

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

  • Dave Woestenborghs 3272 posts 11111 karma points MVP 5x admin c-trib
    May 29, 2019 @ 06:19
    Dave Woestenborghs

    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 :


  • Magnus Eriksson 122 posts 362 karma points
    May 29, 2019 @ 08:00
    Magnus Eriksson

    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

  • Stephen 767 posts 2268 karma points c-trib
    Jun 06, 2019 @ 18:23

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

Please Sign in or register to post replies

Write your reply to: