I'm relatively new to the Umbraco developer scene and I still haven't found the perfect way to structure my Umbraco projects.
I work in Visual Studio, and it seems that there are two fundamental ways of setting Umbraco up:
1. Install Umbraco via Nuget and have all the Umbraco-files in the Visual Studio solution. This of course enables things like debugging (without having to attach to the IIS process). 2. Have the Umbraco installation and your custom C# code in separate folders. In this case build events are set up in the VS solution which copy dlls etc. from the VS bin-folder to the Umbraco bin-folder.
I much prefer solution #1.
Now I'm starting to work on an Umbraco project which is going to use uCommerce. When I install the uCommerce package via Umbraco (uCommerce is not on Nuget, is it?), it puts some dll files into the bin folder. I usually wouldn't have my bin-folder in source control, since the files in it are usually created when building the solution.
But since the Umbraco packages (in this case uCommerce) in some cases put dlls into the bin-folder, maybe it's no longer a viable solution to leave the bin-folder completely out of source control, since these files are not (re)created when building the solution, since they aren't a part of the solution.
What do you guys usually do? Add just the Umbraco-installed/non-solution dll's to source control or just say "to heck with it" and add the whole bin folder to source control? Something else?
Are there any advantages to solution #2 that I have overlooked? I really hate having to attach to the IIS process in order to debug, and having to set up build events for copying files from VS to Umbraco.
Any tips and suggestions would be highly appreciated :-)
Copy the new dll files into a folder in the root of your project, I usually call the folder libraries
Set up a prebuild event in VS which does a copy of those libs XCOPY "$(ProjectDir)..\libraries\*.dll" "$(ProjectDir)bin\" /S /Y (you may need to play with the path a little but make sure to use $(ProjectDir) as TeamCity and other build servers understand this properly, unlike some of the other build variables).
I commit the libraries folder to source control (no good way to get around that I'm afraid)
The advantage is I can still use NuGet for things that ARE available on NuGet, I also don't have to put my complete bin folder in source control, just the few libs that aren't in NuGet.
The advanced (and too much work) option would be to create MyGet ( http://www.myget.org/ ) packages for the libraries that aren't on NuGet so that you can share those between projects as well.
I think it depends on how your team is working. In our team, the developers working with Umbraco also uses Visual Studio, so the following structure in Visual Studio is what works for us:
A web project (empty ASP.NET project)
In this project we install the UmbracoCms package via NuGet. The project is used for storing MVC views, master page, macro fils and similar. Since we use a build server/Grunt, we store CSS and JavaScript resources elsewhere, but they could be added in this project as well. Essentially all non-binary files should go here.
A code project (class library)
In this project we install the UmbracoCms.Core package via NuGet. You could instead just add references to the relevant DLLs in the web project - it pretty much gives the same result in the end. In general this project is where all your C# code should be.
Also in Visual Studio, make sure web has a project reference to code. This way you won't have to copy the DLL manually.
When talking about source control, our bin folders are ignored by default. But sometimes we need to add DLLs - such as uCommerce in your case. In such scenarios you can force add those files to your source control even though they match your ignore patters. Sebastiaans suggestion with a custom NuGet feed/package is another option. What approach is the best i hard to hard, since it comes down to what works best for you.
Our take Marriane is to not add bin to source control, but to make a separate lib folder and reference dlls from there. We'll use NuGet when available. And in the case of a package that's not on NuGet, we'll pull out the dll, copy it, and re-reference it in the project. For most things that works fine without any post build events.
BUT... we had problems with this with uCommerce which I see you mentioned, as I expect you either have or will run into too. I'm afraid it was a while ago and can't remember the details, but we got various conflicts trying to do this, and there are number of dlls that the solution comes with. In the end we had to just install the package directly into our different environments.
Ah yes, adding a reference is what I do these days, thanks Andy, good tip!
With regards to installing it, I think it's mostly because uCommerce needs to make a lot of changes, also in the database so when you install it before a deploy has been done everything should be fine like this. If things are already deployed then it's best to do the install to each environment (make backups..).
I've also gone with the lib-folder in the root of my project and referenced the dlls there.
uCommerce was what really tripped me up because it has so many dlls that it puts into the project's bin-folder. I don't want to move all these dlls to the lib-folder and reference them there since I think (I only first now starting up my first uCommerce project) that the VS project won't be needing all those dlls.
I ended up running a Clean solution in VS and then adding the remaining dlls in the bin-folder (= uCommerce's dlls) to source control. It seemed the most pragmatic way to solve the problem.
All developers in the team share the same database, so it's just the uCommerce files that need to be distributed to each developer machine.
Still open to input if someone has a better solution. I haven't had time to try out the MyGet option.
Package dlls in bin-folder in source control?
Hi
I'm relatively new to the Umbraco developer scene and I still haven't found the perfect way to structure my Umbraco projects.
I work in Visual Studio, and it seems that there are two fundamental ways of setting Umbraco up:
1. Install Umbraco via Nuget and have all the Umbraco-files in the Visual Studio solution. This of course enables things like debugging (without having to attach to the IIS process).
2. Have the Umbraco installation and your custom C# code in separate folders. In this case build events are set up in the VS solution which copy dlls etc. from the VS bin-folder to the Umbraco bin-folder.
I much prefer solution #1.
Now I'm starting to work on an Umbraco project which is going to use uCommerce. When I install the uCommerce package via Umbraco (uCommerce is not on Nuget, is it?), it puts some dll files into the bin folder. I usually wouldn't have my bin-folder in source control, since the files in it are usually created when building the solution.
But since the Umbraco packages (in this case uCommerce) in some cases put dlls into the bin-folder, maybe it's no longer a viable solution to leave the bin-folder completely out of source control, since these files are not (re)created when building the solution, since they aren't a part of the solution.
What do you guys usually do? Add just the Umbraco-installed/non-solution dll's to source control or just say "to heck with it" and add the whole bin folder to source control? Something else?
Are there any advantages to solution #2 that I have overlooked? I really hate having to attach to the IIS process in order to debug, and having to set up build events for copying files from VS to Umbraco.
Any tips and suggestions would be highly appreciated :-)
What I usually do involves a bit of manual work:
librariesXCOPY "$(ProjectDir)..\libraries\*.dll" "$(ProjectDir)bin\" /S /Y(you may need to play with the path a little but make sure to use$(ProjectDir)as TeamCity and other build servers understand this properly, unlike some of the other build variables).The advantage is I can still use NuGet for things that ARE available on NuGet, I also don't have to put my complete bin folder in source control, just the few libs that aren't in NuGet.
The advanced (and too much work) option would be to create MyGet ( http://www.myget.org/ ) packages for the libraries that aren't on NuGet so that you can share those between projects as well.
I think it depends on how your team is working. In our team, the developers working with Umbraco also uses Visual Studio, so the following structure in Visual Studio is what works for us:
A web project (empty ASP.NET project)
In this project we install the UmbracoCms package via NuGet. The project is used for storing MVC views, master page, macro fils and similar. Since we use a build server/Grunt, we store CSS and JavaScript resources elsewhere, but they could be added in this project as well. Essentially all non-binary files should go here.
A code project (class library)
In this project we install the UmbracoCms.Core package via NuGet. You could instead just add references to the relevant DLLs in the web project - it pretty much gives the same result in the end. In general this project is where all your C# code should be.
Also in Visual Studio, make sure web has a project reference to code. This way you won't have to copy the DLL manually.
When talking about source control, our bin folders are ignored by default. But sometimes we need to add DLLs - such as uCommerce in your case. In such scenarios you can force add those files to your source control even though they match your ignore patters. Sebastiaans suggestion with a custom NuGet feed/package is another option. What approach is the best i hard to hard, since it comes down to what works best for you.
Our take Marriane is to not add bin to source control, but to make a separate lib folder and reference dlls from there. We'll use NuGet when available. And in the case of a package that's not on NuGet, we'll pull out the dll, copy it, and re-reference it in the project. For most things that works fine without any post build events.
BUT... we had problems with this with uCommerce which I see you mentioned, as I expect you either have or will run into too. I'm afraid it was a while ago and can't remember the details, but we got various conflicts trying to do this, and there are number of dlls that the solution comes with. In the end we had to just install the package directly into our different environments.
Andy
Ah yes, adding a reference is what I do these days, thanks Andy, good tip!
With regards to installing it, I think it's mostly because uCommerce needs to make a lot of changes, also in the database so when you install it before a deploy has been done everything should be fine like this. If things are already deployed then it's best to do the install to each environment (make backups..).
Thanks for all your input.
I've also gone with the lib-folder in the root of my project and referenced the dlls there.
uCommerce was what really tripped me up because it has so many dlls that it puts into the project's bin-folder. I don't want to move all these dlls to the lib-folder and reference them there since I think (I only first now starting up my first uCommerce project) that the VS project won't be needing all those dlls.
I ended up running a Clean solution in VS and then adding the remaining dlls in the bin-folder (= uCommerce's dlls) to source control. It seemed the most pragmatic way to solve the problem.
All developers in the team share the same database, so it's just the uCommerce files that need to be distributed to each developer machine.
Still open to input if someone has a better solution. I haven't had time to try out the MyGet option.
is working on a reply...