Copied to clipboard

Flag this post as spam?

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


  • Will Waggoner 17 posts 38 karma points
    Oct 27, 2010 @ 22:48
    Will Waggoner
    0

    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?

  • Aaron Powell 1708 posts 3046 karma points c-trib
    Oct 27, 2010 @ 23:09
    Aaron Powell
    0

    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.

  • Will Waggoner 17 posts 38 karma points
    Oct 27, 2010 @ 23:15
    Will Waggoner
    0

    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. 

  • Leon Jollans 41 posts 65 karma points
    Oct 31, 2010 @ 22:39
    Leon Jollans
    0

    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.

  • Leon Jollans 41 posts 65 karma points
    Oct 31, 2010 @ 22:47
    Leon Jollans
    0

    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.

  • Leon Jollans 41 posts 65 karma points
    Oct 31, 2010 @ 22:52
    Leon Jollans
    0

    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.

  • Will Waggoner 17 posts 38 karma points
    Nov 01, 2010 @ 16:59
    Will Waggoner
    0

    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.

  • Leon Jollans 41 posts 65 karma points
    Nov 01, 2010 @ 17:25
    Leon Jollans
    0

    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.

  • Will Waggoner 17 posts 38 karma points
    Nov 01, 2010 @ 18:20
    Will Waggoner
    0

    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.

  • Will Waggoner 17 posts 38 karma points
    Nov 01, 2010 @ 18:23
    Will Waggoner
    0

    Please excuse the double post.

  • Leon Jollans 41 posts 65 karma points
    Nov 01, 2010 @ 18:56
    Leon Jollans
    0

    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?

  • Sebastiaan Janssen 5060 posts 15522 karma points MVP admin hq
    Nov 01, 2010 @ 18:56
    Sebastiaan Janssen
    0

    @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!

  • Sebastiaan Janssen 5060 posts 15522 karma points MVP admin hq
    Nov 01, 2010 @ 18:57
    Sebastiaan Janssen
    0

    Ps. Yes, I do have to run VS as administrator, but really, why would I care?

  • Leon Jollans 41 posts 65 karma points
    Nov 01, 2010 @ 19:14
    Leon Jollans
    0

    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

  • Sebastiaan Janssen 5060 posts 15522 karma points MVP admin hq
    Nov 01, 2010 @ 19:23
    Sebastiaan Janssen
    0

    Well, VS express has no debug features at all built in (last time I checked anyway), so you're on your own there.. ;-)

  • Leon Jollans 41 posts 65 karma points
    Nov 01, 2010 @ 22:06
    Leon Jollans
    0

    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!

  • Sebastiaan Janssen 5060 posts 15522 karma points MVP admin hq
    Nov 01, 2010 @ 22:30
    Sebastiaan Janssen
    0

    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.

Please Sign in or register to post replies

Write your reply to:

Draft