Defference between NuGet and Backoffice package installs
Hello, Umbracians.
I use to install packages via NuGet, but today I noticed that it is don't appears in backoffice (Developer > Packages > Installed) and it seemed weird to me .
Then, I installed a package that have already been installed with NuGet and It appeard.
So, what is the question?
What way is preferable, NuGet or Backoffice?
Looks like backoffice user will not able to update NuGet packages by himself, or may be some pitfalls.
the type of package you install depends really on how you are managing your umbraco site, but yes "Packages" and "NuGet Packages" are diffrent things and they don't appear in each others lists.
Umbraco Packages install via the backoffice, entirely via the Umbraco API and therfore you can install things like new Document Types or Data Types via a package and you can copy files around. but Packages aren't as easy to upgrade, and there is no idea of package dependency,
NuGet Packages is a standard .net way of installing extra files and config to any Project (irrespective of it being Umbraco) and as such has a large support base, and it means you can add things that are not necessarily umbraco.
Nuget handles upgrades and dependencies which makes it easier to manage from a development point of view. It also makes it easier when it comes to building and deploying your site as the nuget packages can be automatically included as part of automated builds.
Nuget Packages don't natively support creating Umbraco elements (like doctypes) so that is extra lifting you have to do with a nuget package.
I think the long term roadmap for Umbraco is to move everything towards nuget packages, but I don't think that's happening very soon.
If you are creating a package i would say you will probably end up creating both an Umbraco Package and a Nuget package, and there are some steps you can take to make this easier and part of your development workflow.
Another advantage of NuGet that I like in particular is that it is excellent when working with Visual Studio and version control (eg. Git, TFS or similar).
We usually add the entire bin folder to .gitignore, so DLLs in there won't be added to version control. This however means that any DLLs from an Umbraco package are also ignored - unless you do something extra to handle this.
When installing a package via NuGet, it will automatically add the necessary references in the Visual Studio project, so you'll have intellisense for the C# classes within the package. As NuGet takes care of the references, you can also rebuild your solution without losing the DLLs of the package in the bin folder.
With Umbraco packages, you have to add the references to Visual Studio manually. And when installing an Umbraco package, any DLL files from the package are automatically added to the bin folder. But running a rebuild in Visual Studio will clear all DLLs in the bin folder, including the ones from installed Umbraco packages.
To avoid this, you manually have to copy the DLLs of a package to a special folder, and then add the reference there. We usually have an assemblies folder for this similar to how NuGet has it's packages folder. In Visual Studio, you can then add the references manually to the DLLs assemblies folder, and you'll be able to use rebuild in Visual Studio, as the DLLs are then copied from the assemblies folder to the bin folder.
So because of the above, we really love NuGet. But sometimes we have to add an Umbraco package as well (eg. if a given package hasn't been released via NuGet), which is fine. And luckily the two aren't mutually exclusive :D
But then again, there really isn't a right or wrong approach to how you install packages. Go for the ones that fits your setup the best ;)
I noticed another fact: if delete a packege with Nuget (in time it was installed with backoffice), packege does't dissapears from backoffice. So, it means record about package recorded somewhere. But where?
The only thing I would add to this is some nuget packages require a little care in installing to be sure you end up with no missing or invalid dependencies.
Defference between NuGet and Backoffice package installs
Hello, Umbracians.
I use to install packages via NuGet, but today I noticed that it is don't appears in backoffice (Developer > Packages > Installed) and it seemed weird to me .
Then, I installed a package that have already been installed with NuGet and It appeard.
So, what is the question? What way is preferable, NuGet or Backoffice? Looks like backoffice user will not able to update NuGet packages by himself, or may be some pitfalls.
Thanks.
Hi
the type of package you install depends really on how you are managing your umbraco site, but yes "Packages" and "NuGet Packages" are diffrent things and they don't appear in each others lists.
Umbraco Packages install via the backoffice, entirely via the Umbraco API and therfore you can install things like new Document Types or Data Types via a package and you can copy files around. but Packages aren't as easy to upgrade, and there is no idea of package dependency,
NuGet Packages is a standard .net way of installing extra files and config to any Project (irrespective of it being Umbraco) and as such has a large support base, and it means you can add things that are not necessarily umbraco.
Nuget handles upgrades and dependencies which makes it easier to manage from a development point of view. It also makes it easier when it comes to building and deploying your site as the nuget packages can be automatically included as part of automated builds.
Nuget Packages don't natively support creating Umbraco elements (like doctypes) so that is extra lifting you have to do with a nuget package.
I think the long term roadmap for Umbraco is to move everything towards nuget packages, but I don't think that's happening very soon.
If you are creating a package i would say you will probably end up creating both an Umbraco Package and a Nuget package, and there are some steps you can take to make this easier and part of your development workflow.
Thanks for detailed answer, Kevin!
I think Kevin's description is very spot on.
Another advantage of NuGet that I like in particular is that it is excellent when working with Visual Studio and version control (eg. Git, TFS or similar).
We usually add the entire
binfolder to.gitignore, so DLLs in there won't be added to version control. This however means that any DLLs from an Umbraco package are also ignored - unless you do something extra to handle this.When installing a package via NuGet, it will automatically add the necessary references in the Visual Studio project, so you'll have intellisense for the C# classes within the package. As NuGet takes care of the references, you can also rebuild your solution without losing the DLLs of the package in the
binfolder.With Umbraco packages, you have to add the references to Visual Studio manually. And when installing an Umbraco package, any DLL files from the package are automatically added to the
binfolder. But running a rebuild in Visual Studio will clear all DLLs in thebinfolder, including the ones from installed Umbraco packages.To avoid this, you manually have to copy the DLLs of a package to a special folder, and then add the reference there. We usually have an
assembliesfolder for this similar to how NuGet has it'spackagesfolder. In Visual Studio, you can then add the references manually to the DLLsassembliesfolder, and you'll be able to use rebuild in Visual Studio, as the DLLs are then copied from theassembliesfolder to thebinfolder.So because of the above, we really love NuGet. But sometimes we have to add an Umbraco package as well (eg. if a given package hasn't been released via NuGet), which is fine. And luckily the two aren't mutually exclusive :D
But then again, there really isn't a right or wrong approach to how you install packages. Go for the ones that fits your setup the best ;)
Thank you, Anders. It is the info I looked for :)
I noticed another fact: if delete a packege with Nuget (in time it was installed with backoffice), packege does't dissapears from backoffice. So, it means record about package recorded somewhere. But where?
Hi Dmitriy
Sometimes you require manually cleaning up of
~\App_Data\packages\installed\installedPackages.configfile to remove the references in UmbracoThe only thing I would add to this is some nuget packages require a little care in installing to be sure you end up with no missing or invalid dependencies.
is working on a reply...