Any problem with including Umbraco in a single solution?
I work with developers who have gone through the Umbraco training and they mentioned that during said training it was suggested that Umbraco be left in its own solution and all extensions thereof should be put in a separate solution, then use build events to copy everything over. That means that if you want to debug code you need two copies of Visual Studio open and the one containing your extensions needs to use "attach to process." I don't really see any benefit to this setup--is there anything wrong with a one .sln solution where umbraco would remain in its own web project and other projects are included alongside it?
Thanks. I was curious as to why the training included that instruction but if there's no problem with a one solution, er, solution then we will probably try that with our next Umbraco project.
I still use post-build events. I think it's cleaner - I prefer to think of making source changes to umbraco as a last resort, and keeping it separate does mean I have to think twice about doing it. It also means I can go ahead and upgrade my umbraco install, or swap it completely, then just re-run the post-build and I have all my changes in place again.
It also means I can distribute and source control my own code with a far smaller footprint.
I find post build events a bit of a pain sometimes though, I used to have a /batch folder in my projects and call out to .bats in that which works with a little help. I expect however that getting stuck into msbuild or using nAnt might be better all round.
Admittedly, it's not always straightforward. I tend to have two projects for my own extensions, one class library project and one web application so VS behaves with markup files. Of course the validation then chokes because masterpages and includes aren't in scope.
Just as an aside, if the umbraco source is rebuilt locally and you copy pdb files into the right places (maybe this is also possible specifying paths somewhere in VS) you can encourage VS to open up umbraco source files from a non-project location during debugging.
I think the training suggests doing it that way both because the umbraco solution is medium sized with ten to fourteen projects or so, which is an overhead, and because it avoids you getting into a situation where your code is embedded in umbraco dlls which then can't be upgraded independently. Also, keeping your code separate makes it possible to package your custom code cleanly apart from umbraco itself and deploy dev code to a clean production server, or somebody else's umbraco install. Obviously including the umbraco projects doesn't mean you can't still keep your code separate, but it's hard to resist the temptation.
I worked recently on a sizeable umbraco customisation, and we were stuck on 3.0.3 unable to upgrade to 4.0 because we had customisations to the 3.0.3 source and lost track of what those changes were (various bug fixes and so on). Admittedly a decent regression test suite could have mitigated this somewhat but it still would have been a problem.
Incidentally on that large project I mentioned there, I had a built umbraco install running under IIS, a separate solution for the job in question (with 15+ projects of its own) and a third umbraco source solution which built to the IIS path and copied to a lib folder the first solution referenced.
I suspect the approach you take depends on the size of the job, but I'm pretty sure migration and distribution is simpler if it's kept separate.
Note that I wasn't inquiring about running a solution that contained the entire source for Umbraco, merely the compiled Umbraco website as a single project in a solution. The other projects would be included in the website as project references, thereby allowing for debugging of custom code, but NOT the umbraco source itself. I can see slow compilation being a problem if you're including the actual Umbraco source.
Oh I see what you mean. Does that work? It never crossed my mind. So you'd set that up as the startup project for F5 purposes, but configured not to compile? Or do you mean adding the umbraco.presentation project source, extracting the built dlls and redirecting the project references to those?
Actually, if you set it up not to compile you wouldn't get project references copied to the bin would you. So you'd extract and reference the built umbraco.dll then, right?
Maybe I'm missing something really obvious and I'm being dense (wouldn't be the first time) - but that sounds fairly awkward to me, and I'm surprised it works. Not that the post-build scenario doesn't have its awkward aspects of course. I mean I have no problem with using "attach to process" myself - I actually prefer it in some ways rather than using F5 but I tend to find extension projects set up in this way are usually so small, relatively at least, that they build and deploy extremely quickly.
Actually, if the web site has project references as opposed to file references then even if the web project isn't set to compile the DLLs from affiliated class libraries are updated. Thus there's no need for the XCOPY and you can still debug the latest and greatest of your extended projects. It's a pretty smooth integration, actually--and hopefully when we upgrade umbraco it will be seamless. We'll see, we're on 4.5.2 now.
How interesting! Definitely gonna have to look into that. I'm curious to hear of any gotchas or things to watch out for - if indeed there are any! If that works as well as it sounds, it deserves advertising for sure. Wiki page?
@Leon It works just fine, you can still attach to process of course. Have detailed my setup (you need to tweak your project settings a tiny bit) on my blog.
I've been working like this for over a year now and I'm still very happy with this setup!
Presumably this gets around VS express not having the "attach to process" command too? Not that I'd last long without being able to attach to nunit on occasion, but I digress :-P
I could be wrong, but I'm pretty sure you can F5 debug in VS express - not that it affects me personally but somebody might find it useful to know. Unless I'm wrong of course!
Any problem with including Umbraco in a single solution?
I work with developers who have gone through the Umbraco training and they mentioned that during said training it was suggested that Umbraco be left in its own solution and all extensions thereof should be put in a separate solution, then use build events to copy everything over. That means that if you want to debug code you need two copies of Visual Studio open and the one containing your extensions needs to use "attach to process." I don't really see any benefit to this setup--is there anything wrong with a one .sln solution where umbraco would remain in its own web project and other projects are included alongside it?
There isn't any problem with having it as part of your Web Application project in Visual Studio. I outlined why I do it that way in the comment I left here: http://blog.mattbrailsford.com/2010/07/14/visual-studio-project-structure-for-umbraco/
I use to use post-built events but got sick of having to run VS as an admin and attach to w3wp to debug.
Thanks. I was curious as to why the training included that instruction but if there's no problem with a one solution, er, solution then we will probably try that with our next Umbraco project.
I still use post-build events. I think it's cleaner - I prefer to think of making source changes to umbraco as a last resort, and keeping it separate does mean I have to think twice about doing it. It also means I can go ahead and upgrade my umbraco install, or swap it completely, then just re-run the post-build and I have all my changes in place again.
It also means I can distribute and source control my own code with a far smaller footprint.
I find post build events a bit of a pain sometimes though, I used to have a /batch folder in my projects and call out to .bats in that which works with a little help. I expect however that getting stuck into msbuild or using nAnt might be better all round.
Admittedly, it's not always straightforward. I tend to have two projects for my own extensions, one class library project and one web application so VS behaves with markup files. Of course the validation then chokes because masterpages and includes aren't in scope.
Just as an aside, if the umbraco source is rebuilt locally and you copy pdb files into the right places (maybe this is also possible specifying paths somewhere in VS) you can encourage VS to open up umbraco source files from a non-project location during debugging.
I think the training suggests doing it that way both because the umbraco solution is medium sized with ten to fourteen projects or so, which is an overhead, and because it avoids you getting into a situation where your code is embedded in umbraco dlls which then can't be upgraded independently. Also, keeping your code separate makes it possible to package your custom code cleanly apart from umbraco itself and deploy dev code to a clean production server, or somebody else's umbraco install. Obviously including the umbraco projects doesn't mean you can't still keep your code separate, but it's hard to resist the temptation.
I worked recently on a sizeable umbraco customisation, and we were stuck on 3.0.3 unable to upgrade to 4.0 because we had customisations to the 3.0.3 source and lost track of what those changes were (various bug fixes and so on). Admittedly a decent regression test suite could have mitigated this somewhat but it still would have been a problem.
Incidentally on that large project I mentioned there, I had a built umbraco install running under IIS, a separate solution for the job in question (with 15+ projects of its own) and a third umbraco source solution which built to the IIS path and copied to a lib folder the first solution referenced.
I suspect the approach you take depends on the size of the job, but I'm pretty sure migration and distribution is simpler if it's kept separate.
Note that I wasn't inquiring about running a solution that contained the entire source for Umbraco, merely the compiled Umbraco website as a single project in a solution. The other projects would be included in the website as project references, thereby allowing for debugging of custom code, but NOT the umbraco source itself. I can see slow compilation being a problem if you're including the actual Umbraco source.
Oh I see what you mean. Does that work? It never crossed my mind. So you'd set that up as the startup project for F5 purposes, but configured not to compile? Or do you mean adding the umbraco.presentation project source, extracting the built dlls and redirecting the project references to those?
Actually, if you set it up not to compile you wouldn't get project references copied to the bin would you. So you'd extract and reference the built umbraco.dll then, right?
Maybe I'm missing something really obvious and I'm being dense (wouldn't be the first time) - but that sounds fairly awkward to me, and I'm surprised it works. Not that the post-build scenario doesn't have its awkward aspects of course. I mean I have no problem with using "attach to process" myself - I actually prefer it in some ways rather than using F5 but I tend to find extension projects set up in this way are usually so small, relatively at least, that they build and deploy extremely quickly.
Actually, if the web site has project references as opposed to file references then even if the web project isn't set to compile the DLLs from affiliated class libraries are updated. Thus there's no need for the XCOPY and you can still debug the latest and greatest of your extended projects. It's a pretty smooth integration, actually--and hopefully when we upgrade umbraco it will be seamless. We'll see, we're on 4.5.2 now.
Please excuse the double post.
How interesting! Definitely gonna have to look into that. I'm curious to hear of any gotchas or things to watch out for - if indeed there are any! If that works as well as it sounds, it deserves advertising for sure. Wiki page?
@Leon It works just fine, you can still attach to process of course. Have detailed my setup (you need to tweak your project settings a tiny bit) on my blog.
I've been working like this for over a year now and I'm still very happy with this setup!
Ps. Yes, I do have to run VS as administrator, but really, why would I care?
Leon likes this :-)
Presumably this gets around VS express not having the "attach to process" command too? Not that I'd last long without being able to attach to nunit on occasion, but I digress :-P
Well, VS express has no debug features at all built in (last time I checked anyway), so you're on your own there.. ;-)
I could be wrong, but I'm pretty sure you can F5 debug in VS express - not that it affects me personally but somebody might find it useful to know. Unless I'm wrong of course!
You're right, I just checked. Must've been a myth I've been told one too many times. Attach to process indeed doesn't work though.
is working on a reply...