Version control of packages installed through the Umbraco back office
Hi all,
I've had this issue for some time and have finally got round to asking how you guys handle it.
There are a lot of common packages we use in our Umbraco projects that have NuGet repositories (e.g. Slimsy). These are great as they work perfectly with our version control (Mercurial) meaning we don't have to upload our bin directory when committing changes. When another developer pulls the project down onto their machine, NuGet simply restores the required dependencies and the project just works.
However, a lot of the most popular Umbraco packages do not have NuGet repositories meaning the only way you can install them is via the Umbraco back office. This is fine but when it comes to version control this can really mess things up as when another developer pulls the project down from version control, there will often be dependencies for the packages I have installed in this manner missing because all of the information is typically stored in a .dll file in the bin directory which is not committed.
Has anybody come up with a solution or approach of how best to get around this as it really eats up a lot of time trawling through bin directories to copy dll files across when this happens. Ideally every popular Umbraco package should have a NuGet repository but that is wishful thinking so I was wondering how other people currently approach this issue.
Any help, pointers or experiences dealing with this issue would be greatly appreciated.
One idea that I've had is to have a Solution folder called "Umbraco Packages". In this folder I keep all of the latest package zip files so that when a developer pulls down the solution they can quickly install the packages to ensure they are up to date.
It's a bit on the manual side but it does give the benefits of version control so you can see when a package was updated.
We always copy the assemblies of Umbraco packages to a NonNugetAssemblies folder (which is included in source control) and add a reference to them, you can see a example here
Out of interest which popular packages don't have a NuGet version already?
Is it good to commit the bin .dll files to the source control? Because today, I had the issue that I cloned a repository, (the bin folder was not committed) from git, and I had somes issues related to the Umbraco forms, optimus bundling was not working etc...
Then I replaced the original bin folder files and worked fine..
Version control of packages installed through the Umbraco back office
Hi all,
I've had this issue for some time and have finally got round to asking how you guys handle it.
There are a lot of common packages we use in our Umbraco projects that have NuGet repositories (e.g. Slimsy). These are great as they work perfectly with our version control (Mercurial) meaning we don't have to upload our bin directory when committing changes. When another developer pulls the project down onto their machine, NuGet simply restores the required dependencies and the project just works.
However, a lot of the most popular Umbraco packages do not have NuGet repositories meaning the only way you can install them is via the Umbraco back office. This is fine but when it comes to version control this can really mess things up as when another developer pulls the project down from version control, there will often be dependencies for the packages I have installed in this manner missing because all of the information is typically stored in a .dll file in the bin directory which is not committed.
Has anybody come up with a solution or approach of how best to get around this as it really eats up a lot of time trawling through bin directories to copy dll files across when this happens. Ideally every popular Umbraco package should have a NuGet repository but that is wishful thinking so I was wondering how other people currently approach this issue.
Any help, pointers or experiences dealing with this issue would be greatly appreciated.
Cheers,
Jason
One idea that I've had is to have a Solution folder called "Umbraco Packages". In this folder I keep all of the latest package zip files so that when a developer pulls down the solution they can quickly install the packages to ensure they are up to date.
It's a bit on the manual side but it does give the benefits of version control so you can see when a package was updated.
Hi Jason,
We always copy the assemblies of Umbraco packages to a NonNugetAssemblies folder (which is included in source control) and add a reference to them, you can see a example here
Out of interest which popular packages don't have a NuGet version already?
Jeavon
Hi Jeavon,
Thanks for the reply. So far I have been unable to find a NuGet package for:
All of which we use every project.
Cheers,
Jason
This is how we do it as well.
Dave
You could always try including the bin folder in source control? I don't think its THAT big of a folder.
It's not like committing the Media folder to source control for example.
We had the same issue and found it was easier to include the bin folder for projects we knew may need packages that can't be installed via Nuget.
If you know the project will only need packages with Nuget support then you can go back to ignoring the bin folder.
Probably stating the obvious but i guess it depends entirely on the number of developers and how strict you are about certain things.
Different Git-Ignore files for different types of projects basically :)
Hope this helps!
Cheers
Hi James,
Is it good to commit the bin .dll files to the source control? Because today, I had the issue that I cloned a repository, (the bin folder was not committed) from git, and I had somes issues related to the Umbraco forms, optimus bundling was not working etc...
Then I replaced the original bin folder files and worked fine..
Any idea please?
Hi Jason!
I had the same problem and I always include in my project the files I need, and it works (using VS+TFS):
Hope this help, best regards Stefano
is working on a reply...