Is there a way to register custom types without compiling the whole thing ?
Hi,
I am completely new with Umbraco. Just downloaded it, set it up and tried few stuff, published a page etc...
I'd like to use the CMS part and security part (members, permissions...) out of the box, but I'd like to customize the app part of the web site I want to build, using custom Controllers.
I would like to have a separate VS solution for that and just reference the Umbraco dlls to write my own stuff, so that in the development process I would not break the Umbraco deliveries.
I have looked everywhere in the documentation because I thought it obvious there would exist a way to register types in a config file so that at startup Umbraco would link my stuff to its own stuff. I think it's better for upgrading with a future delivery of Umbraco : just have to modify the references to the old dlls with the new one, upgrade my own code, and deploy and register my types in the new Umbraco delivery on the server side.
but it seems I am wrong and that I am obligated to modify the Umbraco's code and deploy the thing as a whole... is it right ?
Not at all, you should very rarely needs to actually modify Umbraco. It is fully extensible and uses a variety of points where you can hook in to register behaviour etc.
The easiest way to hook into startup events is by creating a class that inherits from ApplicationEventHandler
As for controllers, you can look at inherting from SurfaceControllers and from RenderMVCControllers. Upon app start up, Umbraco looks for any occurrences of these found in dll's in the Bin or in code found in App_Code.
Finally, you can also implement route hijacking to push to your own MVC controllers as well.
I'm sure there are various other options but from my experience these seem to be the most common.
Thoses solutions are the one I was intending to use but I missed the part that at startup the types were browsed in the deployed assemblies... which is a good news.
I realize this is an IIS feature and not a specific Umbraco feature... that's why it's not part of the documentation and it's normal because everyone building web apps should know that.
There's a long time I've not developped a web app and I forgot this point : assemblies located in the bin directory are loaded by the asp_net process in a pool AppDomain so type resolution is made inside the w3 process, and not by Umbraco of course.
Same thing for the AppCode. I was looking for an AppCode folder under Umbraco and I wasn't finding it... obviously.
I have switched to WinForms developpment for some years and type resolution is different since of course it's made once for all when a specific type from a specific assembly is required; once it's loaded in the AppDomain there's no way to reload it either by restarting the app.
Same thing than IIS is doing by restarting the application pool when changes are dectected under the bin and App_Code directories (and config files also, and may be some other I don't know / remember).
Is there a way to register custom types without compiling the whole thing ?
Hi,
I am completely new with Umbraco. Just downloaded it, set it up and tried few stuff, published a page etc...
I'd like to use the CMS part and security part (members, permissions...) out of the box, but I'd like to customize the app part of the web site I want to build, using custom Controllers.
I would like to have a separate VS solution for that and just reference the Umbraco dlls to write my own stuff, so that in the development process I would not break the Umbraco deliveries.
I have looked everywhere in the documentation because I thought it obvious there would exist a way to register types in a config file so that at startup Umbraco would link my stuff to its own stuff. I think it's better for upgrading with a future delivery of Umbraco : just have to modify the references to the old dlls with the new one, upgrade my own code, and deploy and register my types in the new Umbraco delivery on the server side.
but it seems I am wrong and that I am obligated to modify the Umbraco's code and deploy the thing as a whole... is it right ?
Hi JPL,
Not at all, you should very rarely needs to actually modify Umbraco. It is fully extensible and uses a variety of points where you can hook in to register behaviour etc.
The easiest way to hook into startup events is by creating a class that inherits from ApplicationEventHandler
As for controllers, you can look at inherting from SurfaceControllers and from RenderMVCControllers. Upon app start up, Umbraco looks for any occurrences of these found in dll's in the Bin or in code found in App_Code.
Finally, you can also implement route hijacking to push to your own MVC controllers as well.
I'm sure there are various other options but from my experience these seem to be the most common.
Thoses solutions are the one I was intending to use but I missed the part that at startup the types were browsed in the deployed assemblies... which is a good news.
so it seems I have all what I need. thank's
No problem at all, I don't think that element of things is particularly clear in the documentation. :-)
I realize this is an IIS feature and not a specific Umbraco feature... that's why it's not part of the documentation and it's normal because everyone building web apps should know that.
There's a long time I've not developped a web app and I forgot this point : assemblies located in the bin directory are loaded by the asp_net process in a pool AppDomain so type resolution is made inside the w3 process, and not by Umbraco of course.
Same thing for the AppCode. I was looking for an AppCode folder under Umbraco and I wasn't finding it... obviously.
I have switched to WinForms developpment for some years and type resolution is different since of course it's made once for all when a specific type from a specific assembly is required; once it's loaded in the AppDomain there's no way to reload it either by restarting the app.
Same thing than IIS is doing by restarting the application pool when changes are dectected under the bin and App_Code directories (and config files also, and may be some other I don't know / remember).
is working on a reply...