Closed mistyn8 closed 3 years ago
Just had a poke around with this, and it doesn't seem like kestrel actually crashes. When we generate the models the watch
command sees that a file has been created/updated, and restarts the server, which is intended behaviour from Microsoft POV, unfortunately, this also stops the model generation.
I honestly don't think there's much we can do to stop this from Umbraco's side of things, but you can opt out of files being watched, by adding the following to your csproj file:
<ItemGroup>
<Compile Remove="umbraco\models\**"/>
<Compile Include="umbraco\models\**" Watch="false" />
</ItemGroup>
This way the watch command no longer restarts when models are being created/updated, and model generation works with no problem, it does, however, mean that your site won't automatically restart after you've generated your models.
I did see an error "Attribute Watch is not allowed here", but I think that's just my IntelliSense that's a bit out of whack, cause it seems to work fine when I test it.
Yep exactly that, however, I do see that kestrel is no longer running (waiting for a file change to rebuild) and I can't access the site, front or backoffice until kestrel is stopped and run without watch and the few models.generated.cs that have been produced deleted. As there are more than just the one model created, didn't know if it was a max reload times issue, rather than just model changed so site restarted and generation halted? (as if that is the case shouldn't there only be 1 model generated file?) Thanks for looking.
hmm, I haven't be able to reproduce that, when I try kestrel just restarts, I can then load the front end, and the back office with no problem, there is something sort of weird going on though, if I try to generate models again a second time they manage to generate before kestrel restarts.
For me looks like I generate about the same amount of models as that before grinding to a halt.. but I have significantly more and of the larger set the remainder don't generate.. At which point the site rebuild fails as models aren't available for my front end render. (that would be the reason no site for me.. doh) I've gone back to not watching and restarting as required.. :-)
Ah yes, that makes more sense then, but yeah, unfortunately as I mentioned I don't think there's really anything we can do about it, so I think the go-to approach is either not using watch, or using the workaround I posted above to ignore model changes, at least the site will start restart for your own code changes.
But I'll go ahead and close this then 😄
Just had a poke around with this, and it doesn't seem like kestrel actually crashes. When we generate the models the
watch
command sees that a file has been created/updated, and restarts the server, which is intended behaviour from Microsoft POV, unfortunately, this also stops the model generation.I honestly don't think there's much we can do to stop this from Umbraco's side of things, but you can opt out of files being watched, by adding the following to your csproj file:
<ItemGroup> <Compile Remove="umbraco\models\**"/> <Compile Include="umbraco\models\**" Watch="false" /> </ItemGroup>
This way the watch command no longer restarts when models are being created/updated, and model generation works with no problem, it does, however, mean that your site won't automatically restart after you've generated your models.
I did see an error "Attribute Watch is not allowed here", but I think that's just my IntelliSense that's a bit out of whack, cause it seems to work fine when I test it.
The workaround does not work in Umbaco 10.1.0. It still breaks when trying to generator the models from backoffice.
Which exact Umbraco version are you using? For example: 8.13.1 - don't just write v8
v9-rc001
Bug summary
dotnet watch run
with ModelsBuilder"ModelsMode": "SourceCodeManual",
Causes kestrel to crash and leaves you with incomplete models generation
Specifics
No response
Steps to reproduce
dotnet watch run
with ModelsBuilder"ModelsMode": "SourceCodeManual",
use the backoffice to rebuild models.
Expected result / actual result
Not sure if this is avoidable or not, just FYI.