NuGet and Sitefinity

I'm considering doing this for our local instances by seting up my own project files and local NuGet server...

We don't check in bin folders to our repositories. We've been handling upgrades in rather out of band ways to accommodate this, but we are looking to avoid a bunch of the core libraries that are redistributed with Sitefinity in favor of GAC copies. I'm looking at creating local NuGet distributions for the Sitefinity libraries, with dependencies on packages like MVC, etc., instead of doing large binary drops. Also, we would replace the distributed core framework libs with linked references instead.

Are there any pitfalls to this? Is there any interest in this from others? Of course Telerik provided packages would be awesome for development patterns like ours, but until such are available, I'm wondering if anyone else has done similar.

I'm picturing something along the lines of MVC4's current method of distributing itself as a collection of NuGet packages here.

Hey Michael,
Subscribing to this thread since I'm interested.

I've been using linked references since v5 and swear to them, not sure what the value/benefit is from several NuGet drop ins.

Whether its a hotfix a sp or a full release, unless its coming directly from Telerik, you'd waste hours breaking the packages up given the fact you've got no idea which files/folders changed or what web.config settings need to be updated - but I'm open to a fresh perspective.

Jochem.

So let me explain what I see as difficult with the current implementation.

The current project manager upgrade cycle involves doing binary updates of the bin directory. It works great for sites that are doing no development on them. But if you are doing development on them, and I have everything in one solution, then Clean's are pretty much out of the question.

To get around this, we're using the old _bin_deployableAssemblies hack everyone was using in MVC3. In MVC4, Microsoft has cleaned up this workflow by abstracting all of that into NuGet packages that are easily handled by Nuget package restore. This is a "wouldn't be nice if" situation for me.

We are about to start a second project which will have a lot of shared code / modules between the two. To facilitate that, it would be useful to just have them be internal NuGet packages we can subscribe each project to, so we have a centralized source point for them.

Let's look at the libraries that Sitefinity is dependent on in 6.1 that are available as NuGet packages:

1. AjaxControlToolkit
2. DocumentFormat.*
3. Microsoft.Http
4. Microsoft.IdentityModel
5. Microsoft.Practices.ServiceLocation
6. Microsoft.SharePoint.Client.*
7. Microsoft.SqlServer.Types
8. Microsoft.Web.Infrastructure
9. Microsoft.Windows.Azure.*
10. Mono.Cecil
11. mysql.data
12. JSON.NET (Newtonsoft.JSON)
13.  RazorEngine
14. System.Net.Http.*
15. System.Web.Http.*
16. System.Web.Mvc
17. System.Web.WebPages.*
18. NHamcrest

And the ones that aren't:
1. DirectShowLib-2005
2. Interop.DexterLib
3. Microsoft.CompilerServices.AsyncTargetingPack.Net4
4. payflow_dotNET
5. Telerik.*
6. Twitterizer2

Essentially, the vast majority of the (Non Telerik) dependencies COULD be included via NuGet package, instead of us having to check-in these libraries to our repositories.

Now yes, you are correct, I'm kind of trying to put this idea in the head of some young enterprising Telerik person to give us a project file setup this way... What I would PICTURE would be this:

1. Have two types of projects that project manager could generate maybe? A binary distribution (sans-project files, etc.), or a source distribution (which includes a project file setup for NuGet package restore with these packages).
2. Breaking up the Telerik libraries into NuGet packages (They have other packages like Kendo that they do this with already). Now the project file is essentially empty except for supporting files (Sitefinity directory, App_Data, etc.), and some way to include the non-NuGet package dependencies that remain (Twitterizer2, etc., if these are not internal. _bin_deployableAssemblies a possibility here, or they could be included as part of the Sitefinity NuGet super package as well).

Now you brought a good point that I wasn't even considering yet. Right now I'm just thinking about library dependencies, and not about supporting files. But you're thinking about the NuGet packages being the ones responsible for creating / updating these supporting files, and I wasn't quite thinking that.

I was picturing the project manager still being involved here, but instead of just dumping binary blobs in a bin directory, it would examine the packages.config file and update the references there (and add / remove references to their libs in the project). Then all you'd have to do is upgrade through there, and run a build to get the new packages pulled down.

Service packs or upgrades often also change/add some .svc file so I didn't initially saw the benefit of a NuGet vs external reference. And besides, swapping the empty proj files is a matter of two minutes copy/pasting - it's often the web.config changes that take the most time with an upgrade.

---
I always 'build & publish' locally to IIS and store the .config files in the target directory.
So other than the /App_Data/WebsiteTemplates folder the SitefinityWebApp proj is basically completely the same as an _emptyproject.

All customizations reside in other projects that are part of the solution. That way you could simply unload the 'SitefinityWebApp60' project from the solution and add a 'SitefinityWebApp61' to it again. Then by building & publishing your website would get upgraded.

Now an upgrade (aside from testing) is basically doing that already but manually editing/checking the web.config and add/editing the custom projects references and copying the websitetemplates folder back in cause Thunder doesn't allow it to be an external project.

If they could come up with a proper way to make themes & templates an project part of the solution, we'd be home on time for dinner :)

I have two main things I see that make this advantageous:

1. VCS repositories don't have to get bloated with big binary blobs that can be easily included by NuGet package references instead.
2. Module development can be done in completely separate projects without requiring the full Sitefinity distribution for references (Include only what you need).

Again, this has nothing to do with running upgrades through NuGet, etc. This would not remove the Project Manager from the workflow here. This is all about reference management. Just instead of having binary blobs in your repository for this, it would be easy to setup NuGet package restore to pull them from a (Telerik?) NuGet server.

And I hear ya on the Theme thing.

And yes, to do it right would be a little bit of work, and having a Telerik person who knows what goes where would be beneficial... Of course, just dumping the whole bin directory into a single NuGet package would be suboptimal for this purpose, as in order to accomplish the "include only what you need" for module development part, you'd want different libraries broken out into different packages.

So these, libraries don't get updated with EVERY upgrade, but just the ones I named are about 30 megs, to give you an idea of how quickly these would bloat a DVCS system.

Throw into this ALSO OpenAccess "enhanced" DLL needs, and there is another interesting reason to abstract some of this out into NuGet packages (One could easily tie the enhancer version to the Sitefinity version and we could all avoid downloading the big SDK every time a new version gets released...).

Perhaps Telerik isn't ready for such a system to be in place, and that's fine, I just wanted to throw it out there as something that would simplify a lot of stuff for those of us already using NuGet in our daily development work. I'd suspect it would make managing the library updates a crap-load easier on their side as well when doing actual version bumps, so there's added benefit from their side too.

Edit: Also I came across this: blogs.telerik.com/.../power-your-projects-with-telerik---now-with-the-convenience-of-nuget

If you read the comments, it seems others are clamoring for a private Telerik repo with the libraries all split out properly by dependency. Keeping my fingers crossed here!

One more point: Most of these dependency libraries are woefully out of date (e.g. AjaxControlToolkit is 3.0.... the latest is 7.0! DocumentFormat.OpenXml is 2.1, latest is 2.5, Microsoft.Http is up to 4.0 now and it's still 1.0 in Sitefinity,  etc.). Switching to a Nuget package restore model for the Telerik Sitefinity development team would make updating these dependencies much easier...

Are there any plans to begin updating these dependencies, NuGet package route or not?

Ok, I went ahead and setup an internal NuGet server to try this out. I love it. This allows me to isolate all of our shared module code into separate repositories, and still keep those repositories small by using NuGet package restore. I just used the NuGet.Server setup so create a simple internal feed, and split all of our stuff into different repositories with separate build scripts, and added them to our CI environment (TeamCity) to checkout, package, and deploy to the NuGet feed.

Essentially, I just made a Telerik.Sitefinity.Core NuGet package that just included the entire bin directory. This is less than ideal, but proves that this is viable (ideally, all of the libraries would be split up into separate dependent NuGet packages of a Telerik.Sitefinity super package, but I'm not going to manage 80 different internal packages at this time...).

I ALSO created a Telerik.OpenAccess.Enhancer NuGet package that contains just the enhancer stuff for OpenAccess enhanced modules (makes enhancing projects soooo much easier).

This centralizes the binary distribution between different instances, as well as shared code, and makes repositories (besides the Telerik.Sitefinity.Core one) MUCH smaller.

This doesn't solve the upgrade process in terms of updating project files, web.config, or other files, but it takes care of library dependencies splendidly. This may look like an exercise in futility because of that, but when you have many different Sitefinity instances that all need to be upgraded, it makes the whole "Upload a new checkin with 150 megs worth of new binaries" part much cleaner.

Hey Michael,

Not an exercise in futility at all, but interesting approach I'd love to put in place.
While I understand the packages approach that get pulled in, I'm not 100% on board yet ;)

What I usually do is break-up an empty/clean project so I'll have 'default' files as well.
This always gives me the ability to checkout a(ny) sitefinity version (dlls/default folders+sample configs) and keep the actual development files separated and easily checked-in.

Inside VisualStudio I set the references to the lib folder and exclude it from the project and thus keep it minimized while at the same time I've got actual + original files on hand.

---

How'd you solve that with NuGet? I know you said you've not gotten around to that but eager to hear in which direction you're thinking before switching myself.

Jochem.

That's a good question, and one I haven't even really thought about tackling yet. My biggest concern was excluding those binaries, and providing a way to abstract out all of my modules without having to have multiple copies of those binaries.

If I were going to do the FILES as well, I'd likely abstract that into another NuGet package separate from the core libraries, just so I could handle the file adding logic completely separate from the binaries and not have issues in projects that only depend on certain libraries.

Most of the files in the project could easily be added this way I think actually, now that I think about it... web.config transforms and anything in the App_Data/Sitefinity directory would be the biggest issues there. Overwriting any custom implementation stuff you might have overridden during upgrades could be an issue (e.g. any .svc files, etc.). I would think you'd have to just exclude the entire App_Data/Sitefinity directory from this deployment strategy (which I do anyway).

==

I have two issues right now I'm trying to tackle: How to deploy NON-dll files to the bin directory on build (e.g. the one config file thats in there... which god knows why it isn't in the web.config instead of in there), and a way to selectively include the references in the dependent project (e.g. right now the first time I install the package in a module project, it loads all 80 references in it, and then I have to use "Remove unused assemblies" to remove the references I don't need). Not sure theres a really good work around for that last one, and the first one might just end up being a post-build action at some point.

Also, I'd like to look into adding targets for Enhancer to my project file automatically through NuGet, so I can remove that manual step real quick (I know it's possible, just gotta figure out how you do it)

I'm in the middle of a fast moving project right now, so exploring the above is going to have to wait for me, but I think I will be doing so when I get the chance... IDEALLY my mega-Sitefinity package would be split up into smaller subsets of packages (e.g. Telerik.Sitefininty.* should be in one package, and OpenAccess in another, and then all the other dependencies in separate ones, etc.).

I've gone down a similar route although I'd dumped everything in one package including all the services, config files etc.  Found it works much better as it means my developers don't need to go download the project manager to create new projects, they just create an empty webapp and install the package.

It does mean I need to download the package manager and upgrade the package once every release but it's fairly easy.

Pitfalls
* NuGet doesn't seem to be able to reference any dll that ends in resources, I believe this was done by design but it is rather annoying.  Currently add this reference manually.
* Upgrades don't play nice with TFS - a package upgrade uninstalls the existing version then installs the new one, problem being that you get lots of errors that an item can't be added due to a pending delete. Way around this is to uninstall, check in, then install new version.  Any modified files aren't removed or overwritten so you don't lose anything, although you sometimes have to merge web.config changes manually (haven't gotten around to making the web.config a merge file instead of just a web.config). Unsure if other source controls play nice in terms of this.
* Everything is in one package - would be nice to split into Sitefinity.Core (dlls), Sitefinity (service references) and then reference any required nuget packages

Ideally Telerik would be creating these packages and updating them every release, would save me a bit of a work, however with the two problems I mentioned above I can't see them doing this.

Would also be nice if Sitefinity could also update it's own license to new versions, the current license activation feature doesn't seem to play nicely with multiple licenses.

Hi, I am new to sitefinity. I have the need to upgrade sitefinity through Telerik.Sitefinity.All NuGet package, for about half a dozen Sitefinity systems the company maintains. There are version-specific upgrade, I have used docs.sitefinity.com/upgrade as reference but this is the basic approach. Please do the needful my mentioning the upgrade procedure from 9 -> 10 version.