16 Mar 2012
Link to this post
18 Sep 2013
in reply to
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.).