So I have Umbraco v6 currently setup via a release download and split into a class library and a website. I need to upgrade to v7 at some point and have some question on how I should setup.
What are the pros/cons of setting up through Nuget vs Downloading source and creating project?
Devin
The pro of using nuget is that you don't have to build the project from scratch. If you have a need and/or desire to understand how umbraco is built, by all means pull down the source code, but if you just want to use umbraco, and customized it thru the hooks it provides, then the nuget packages will be easier.
I've done both (though not with the latest version), and using nuget is far easier and quicker to get going.
Related
What is the difference between umbraco and vanila umbraco.
i'm currently using umbraco 6.2.1 version in my website.
Any special procedure available for upgrading this version to Vanila umbraco version.
Vanilla Umbraco means a fresh clean installation of Umbraco, without any customization.
Vanilla is a general term used for software, see also on wiki
Related to upgrading, one approach is to do a new installation of Umbraco (we can called it a vanilla installation) and then deploy your code, and migrate the content. Instead of the General Umbraco upgrade instructions.
I'd say that there is no running website with a vanilla Umbraco install. Umbraco is not a typical CMS. You are customizing it as soon as you start setting up your site in it. This is partly due to a choice on the Umbraco HQ team's decision to store their settings in the same files where you change settings by using Umbraco, requiring you to merge certain files during the upgrade.
As for upgrading, I'll warn you, there are a few ways to install Umbraco (Web PI, Nuget, Zip file), and if you upgrade in a way different than you installed, it can be hell. Step one, back up your site (front-end file-system files and db)! If you did not install Umbraco via Nuget (in Visual Studio), do not upgrade via Nuget. You will regret it.
Umbraco upgrades are a problem.
If the versions are minor running the update-package umbracocms nuget might work, but it often leaves the project mismatching version assemblies elsewhere.
Upgrading Umbraco is a bit of a minefield. Soz
Umbraco is now at version 11 and have moved their code base from the .NET framework into .NET core. Newer version is offering so much more, block-list, block-grid, inline editing, so many new and improved property editors. Editing experience and working with the CMS has changed so much since version 6.
Vanilla Umbraco would a term for a non-configured, fresh install.
You can find out everything you need to know about Umbraco on their documentation pages.
https://docs.umbraco.com/getting-started
Umbraco is a free open source project so there is no cost if you want to roll your sleeves, dig in and move over to the newest version. There are some paid offerings as well that would give support if you needed it.
Now that they have moved away from the .NET framework and moved their code base over to .NET Core there is no longer a direct path to upgrade from version 8 and earlier to the most recent version 11.
I would recommend you set up a fresh install, configure and customize as desired and then move any relevant content over to your new site.
There are many articles out there detailing how others moved over to the newer version.
Good article here on how they upgraded from version 7 to the newer version 11.
https://skrift.io/issues/how-i-upgraded-my-umbraco-v7-project-to-umbraco-v11/
Worth the read if your planning on going down that path.
Good luck.
This question is about how to set up a project template to satisfy dependencies.
First, some context.
I have a MVC4/Durandal project that I'm trying to turn into a project template that distils all the goodness from a recent project, for re-use.
After creating a new project, adding all the non-standard good bits and shaking down the stub project so that it compiles and runs properly, I copied the project folder and plonked it on another computer with a freshly minted VS2013 installation, to see what broke.
The following were MIA:
Antlr.Runtime
System.Net.Http.Extensions
System.Net.Http.Primitives
System.Web.Optimization
WebActivator
WebGrease
There are a couple of issues making it less than obvious to me as to how I should proceed.
Installation of these things happened so long ago that I really couldn't say how they got onto my development workstation
In many cases package dependencies mean that installing one NuGET package will implicitly satisfy other dependencies
I don't know how set up a project template so that it causes NuGET package(s) to be installed
A bit of guidance would be appreciated, not to mention advice on best practice.
Update
It appears there is direct NuGet support for project templates, I'm still reading about it here and also here.
Since allowing NuGet to automatically resolve dependencies is a good way to ensure compatible versions are installed in the right order, the remaining question is looking at the missing assemblies, how can I determine the most dependent package(s)?
It seems that omitting the packages folder produces a slim template, and the projects produced therefrom install the missing files as soon as you start a build. That's good enough for me.
I would simply start with a blank ASP.NET 4.5 MVC project. The most basic dependencies should be satisfied then. NuGet has basic packages for Mvc and other packages you may need. NuGet packages are designed to self contain the missing assemblies they need. They'll get published in IIS when you deploy so you don't install anything on the server.
Related to: Package an ASP.NET MVC application with Nuget
I'm trying to get a mode where I can edit an MVC project and package it easily.
As often suggested it is wise to replace a namespace using NuGet pre-processor functionality.
This would mean that I would have to edit my source files and add the pp extensions to each pre-processed source file.
Are there any tips and tricks to make this less labourious?
There is such a tool, that did almost exactly what I wanted. It's on Codeplex so I could participate in the development, yay!
https://nugetpackager.codeplex.com/
It has a common-line interface too, so I can script my updates.
I have added few packages from NUGETin visual studio 2012. I see nuget.exe in the project. I have not come across this before as I have not yet seen nuget.exe in my other web applications. I searched in GOOGLE about this but have not found good answer. Why is nuget.exe added? Is there any reason I might need it? Any help would be apperciated!
I think you might have installed "NuGet.CommandLine" package or some other packages related to it.
Using "nuget.exe", you can installing NuGet packages directly from the command line.
The good things about "nuget.exe" , is if you just want NuGet to download the assemblies for you,
it'll leave the rest to you. It saves you time by letting you easily download the pieces
and their dependencies, it doesn’t force you into a development model you don't want.
If you don't need it, you also can use NuGet to uninstall it.
I would like to activate continuous integration for a Prism application on a TFS build server. Actually the build controller is not able to compile the application because it does not have the Prism Library. Prism is registered in my Visual Studio on my developing machine and the project simply reference it. I was wondering if I should checkin the library within the project or should I install the library on the build server.
So what practice do you use to integrate application using dependencies on a build server?
In general, checking in the necessary Libs provides you with the advantage that setting up a new build controller requires less time.
We use a mixed approach on the matter:
- log4net, Rhino, NHibernate etc reside on a shared Dir within the source control
- Other packages that require setup and/or licensing (Infragistics, NCover etc) are installed on the build controller
I have only very basic knowledge on Prism, by 'Prism lib' do you actually mean the 5 Microsoft libraries
Microsoft.Practices.Composite.dll
Microsoft.Practices.Composite.Presentation.dll
Microsoft.Practices.Composite.UnityExtensions.dll
Microsoft.Practices.ServiceLocation.dll
Microsoft.Practices.Unity.Silverlight.dll
If yes, we would have placed them definitely within the source control
I finally opted for a solution based on pantelif idea.
Instead of manually checking in and managing depedencies manually, I used NuGet to reference packages. Firstly it is perfectly suitable for source control as it checks-out any file required to build the project. Secondly it supports easy updates of the libraries.
Thanks for your help.