I'm still learning about NuGet and have a (hopefully not stupid) question: how are the components/assemblies in NuGet packages intended to be distributed to end users? The docs I've found are all about how NuGet packages get installed on developer systems, but nothing addresses how the resulting software is shipped/installed.
My best guess is that the developer using the package must decide how to get the components or assemblies to the end users, presumably by including them inside whatever installer the developer builds. The developer is also presumably responsible for any required registration (if side-by-side installation is not sufficient). Basically I'm guessing that NuGet and the concept of packages are out of the loop at this stage. Is that right?
They aren't intended for end users. NuGets purpose is to help developers manage their software dependencies. The developers still package and deploy their application and its dependencies the same way they always have.
This can be via an MSI installer, exe installer, ClickOnce or Windows Store installation.
NuGet adds the assemblies as references to your application's project. When you compile your application, you'll see all the assemblies you pulled in via NuGet in the output directory (typically bin\debug or bin\release).
The idea here, as Andy says, is that these assemblies are now part of your application just as if you had found the assembly and referenced it manually.
Basically I'm guessing that NuGet and the concept of packages are out of the loop at this stage. Is that right?
Yep. However you plan to ship your application binary is the same way you distribute the assemblies that were "installed" by the NuGet packages. You don't need to distribute the packages, just the assemblies that were referenced by your application.
Related
In setting up Sitecore 7.2 at my organization for our public facing .com I have run into a hiccup while trying to implement proper CI, Release Management, and Deployment Management. I am able to, using MSBuild, compile my Sitecore MVC code, compile .update packages from TDS, and package each of these in .nupkg files for Octopus Deploy. What I am running in to is that once I have deployed the MVC code I must also deploy the Sitecore Structure/Content which requires me to install .update packages. I have tried the solution provided at https://github.com/adoprog/Sitecore-Deployment-Helpers but for a fairly lightweight site this is timing out around 20 minutes within Octopus Deploy for only my System package, let alone having not touched Structure or Content. I am looking for a way, preferably through PowerShell (not strictly speaking, the Sitecore PowerShell Extensions built into the sitecore web interface after installing that package). Using the SPE would be acceptable if, and only if, I can use SPE's Cmdlets from Octopus Deploy's PowerShell workflow.
Please Advise.
Jason Bert has a great series of blogs on using Octopus Deploy with TeamCity and TDS for deploying to Sitecore instances:
http://www.jasonbert.com/2013/11/03/continuous-integration-deployment-with-sitecore/
You can also use TDS itself to deploy the items in the solution, but this uses direct calls to a webservice on the target Sitecore instance which may not meet with your requirements.
Also, are you deploying the entire System tree? 20 minutes to deploy changes made to the System tree seems unusual, unless you've made a LOT of changes in there (for example, the Dictionary). Even then, you shouldn't be source-controlling author content, only the elements crucial to the solution that are owned by development.
You can install the update package via sitecore utility at /sitecore/admin/UpdateInstallationWizard.aspx
If you experience that installing the package via this mode takes a lot of time, you might want to modify the Deployment Property Manager settings for the TDS project.
You can do this by right clicking your TDS project in Visual Studio and selecting "Deployment Property Manager".
Once the Deployment Property Manager window opens up, set the Deploy property to Once for every node which does not need to be updated. For any items which are to be updated, mark them as Always.
This will drastically save you on the time required to install the package.
I have several ASP.NET application running under a common IIS Site and would like to use a NuGet package to transform their config while copying versioned JavaScript file to the IIS Site's Root application Content folder.
Can NuGet be used like this? I.e. can it be determine during package installation/updating which IIS Sites root application an ASP.NET project is being run under (using the preinit powershell script for example).
The tool you are looking for is Octopus Deploy It install nuget packages on IIS, as windows service, etc. Moreover it gives raeally nice GUI for management.
NuGet is a dependency manager, and as such is appropriate for use at development/build, not deployment time.
Take a look at Inedo's BuildMaster. It can take care of the process from source control through production deployment. There's also a free version that will most certainly handle your requirements, and it also has a module to manage your configuration files so you don't need to worry about doing transforms.
(disclaimer: I work for Inedo)
We are currently using web deploy for creating packages for our .net web applications. It got some pros and cons. Now we are going to use nuget for dependency management but given the ease of packaging in nuget .. i am debating on should i still use web deploy + remote service or try to use nuget to bundle my web application and use powershell or something like octupus to deploy ??
For my web deploy becomes little complex when even try to do simple things like include , exlcude , gac or registry or iis config ( which again not very flexible ).
But on the other hand it comes with remote service and all i need to do is through the package to the service and i am done..
Please give your inputs on this comparison.
-raj
NuGet is a dependency manager, and as such is appropriate for use at development/build, not deployment time. From a deployment perspective, it doesn't offer you any more than what a zip file does... except all the overhead of trying to fit NuGet in the process.
Take a look at Inedo's BuildMaster. It can take care of the process from source control through production deployment. There's also a free version that will most certainly handle your requirements, and it also has a module to manage your configuration files so you don't need to worry about doing transforms.
(disclaimer: I work for Inedo)
I am setting up a system that uses NuGet and Webdeploy.
NuGet is used as the repository format, so the build system publishes NuGet packaged artifacts.
The Deployment systemn uses NuGet to get the RIGHT packaged artifact from the NuGet repository.
The build artififact happens to be WebDeploy for easy installation.
I am still working out if I am going to use puppet, chef or octupus to orchastrate the deployment.
Having (presumably) understood the motivation behind Nuget, I want to know, whether we still require internet access to download a package which is already being downloaded earlier for different project in different solution?
I believe you can even set up your own feed stored on the file system as described here.
You can setup your own local NuGet repository as As Denis Ivin has already said.
NuGet also has its own local machine cache which keeps NuGet packages that you have installed previously (C:\Users[UserName]\AppData\Local\NuGet\Cache). You can install these by selecting the Recent packages tab in the Manage Packages dialog.
Having your own local NuGet repository is probably better since the cache could be cleared.
My plugin DLL is really simple but references fifteen or so other DLLs. How do I register this?
Ways I know about are:
a) Put the other assemblies in the GAC (I think this is SDK preferred method). Will have to install on each client if needs to be taken online.
b) Use ILMerge to merge all of your assemblies into one assembly. You can deploy this to the database and have it used by your offline clients without a seperate install.