I'm building websites in Umbraco and they all use similar components and base templates. The obvious best practice is to create packages that install these things ready. But I can't tell how to do things like add project references in Umbraco, and I can't tell how to create document types (a database object) in NuGet.
I've not been able to find a good comparison of abilities - what one package can do that the other can't - to be able to choose one or the other types of package. Or will I have to use both types of packages for different jobs (I don't want to go down this route if I can help it, since some features may require both packages).
EDIT for clarification, hopefully this will help. I'm trying to ask a blanket question to find out whether it is possible to use only one packaging system, rather than two. I want to avoid installing 2 different packages to get something to work properly.
Can a NuGet package trigger an automatic install of an Umbraco package?
Can a NuGet package create Umbraco objects, like document types, etc?
Can an Umbraco package add assembly references to a project?
I'm not sure where you're trying to use NuGet in Umbraco, the Umbraco packaging system isn't NuGet based, it's entirely different to NuGet (caveat - the next version of Umbraco will use NuGet for packaging).
The Umbraco package system, as currently defined, is capable of deploying any file into your target project be that CSS, JavaScript, Templates, Assemblies, User Controls, etc, as well as data into your database (Document Types, Content, etc).
Related
I have Microsoft.VisualStudio.Web.CodeGeneration.Design nuget in a project.
Can it be safely excluded from publishing (<ExcludeAssets>runtime</ExcludeAssets>)?
Is there scenario, when during runtime, code has dependency on this package?
As I understand this package is used only for generating the code during development.
I don't see any reason to add its dll in published code.
Is it safe to exclude Scaffolding packages from publish version?
As the package describes,
Code Generation tool for ASP.NET Core. Contains the
dotnet-aspnet-codegenerator command used for generating controllers
and views.
It only works for generating code for views or controllers during developing and the project itself does not depend on the package at runtime.
So it is safe to exclude that nuget package from publishing using your method. And you do not have to worry too much about it.
Using Kentico for the first time and have inherited a version 7 project with custom web parts. There are folders with .cs files, folders with .dlls, and folders with .ascx/ascx.cs web parts. Most are active. Some are not.
What's the best way to assess what is used and what is compiled when looking at a Kentico instance? I'm trying to sort what Kentico stores for configuration, how Kentico knows what to compile, and how Kentico provides a pathway for custom ascx/ascx.cs webparts to use (via using) various libraries in folders on the Kentico instance folder structure.
Having worked with Kentico for quite a while it's pretty easy to identify them simply by looking in a few directories.
If you haven't worked with it before you might try to do a fresh install of version 7 which you can get from the Kentico Client Portal and compare them.
If the install was done with best practices, you can look in the following documentation and the "custom code" should be in the green and blue directories in the documentation.
There is an open-sourced utility called KInspector (it`s made by Kentico consulting team). This utility should show you your custom code (among the others) in Kentico instance (afaik it is in the Analysis module).
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 am working on an open source project MvcSiteMapProvider getting it ready for deployment. It is a library package that supports MVC2, MVC3, and MVC4 as well as .NET 3.5, .NET 4.0, and .NET 4.5.
Based on Nuget Package: Use Different MVC Version When Available, I have come to the conclusion that I need to make a Nuget package for each version of MVC and let Nuget's internal version detection take care of the different .NET versions, like this:
MvcSiteMapProvider.MVC2
MvcSiteMapProvider.MVC3
MvcSiteMapProvider.MVC4
However, in addition to a library DLL, I have different files (Dependency Injection configuation, MVC DisplayTemplates, etc.) that need to be deployed to the target project. These files MUST NOT be updated when the new version of the main project is updated because they will likely contain end-developer edits that I don't want to overwrite.
So, it is clear that these need to be in their own Nuget packages for this and other reasons. However, these other packages need to depend on the main MvcSiteMapProvider.MVCx projects, just to ensure one of them has been installed.
It doesn't make sense to make a separate Nuget package for each version of MVC for each of these other packages - they are all exactly the same except for this one dependency. Ideally what I would like to do is make a single Nuget package that depends on either MvcSiteMapProvider.MVC2, MvcSiteMapProvider.MVC3, or MvcSiteMapProvider.MVC4 and if none of them are available, install the one that matches the MVC version of the target project, but how would I accomplish this? If that is not possible, what other options do I have than creating large number of Nuget packages (one for each MVC version dependency) that grows exponentially with each new MVC release?
To clarify, I have other Nuget packages like this:
MvcSiteMapProvider.Web
MvcSiteMapProvider.Configuration.Autofac
MvcSiteMapProvider.Configuration.Ninject
MvcSiteMapProvider.Configuration.StructureMap
MvcSiteMapProvider.Configuration.Unity
MvcSiteMapProvider.Configuration.Windsor
I am trying to avoid having to change that to:
MvcSiteMapProvider.MVC2.Web
MvcSiteMapProvider.MVC2.Configuration.Autofac
MvcSiteMapProvider.MVC2.Configuration.Ninject
MvcSiteMapProvider.MVC2.Configuration.StructureMap
MvcSiteMapProvider.MVC2.Configuration.Unity
MvcSiteMapProvider.MVC2.Configuration.Windsor
MvcSiteMapProvider.MVC3.Web
MvcSiteMapProvider.MVC3.Configuration.Autofac
MvcSiteMapProvider.MVC3.Configuration.Ninject
MvcSiteMapProvider.MVC3.Configuration.StructureMap
MvcSiteMapProvider.MVC3.Configuration.Unity
MvcSiteMapProvider.MVC3.Configuration.Windsor
MvcSiteMapProvider.MVC4.Web
MvcSiteMapProvider.MVC4.Configuration.Autofac
MvcSiteMapProvider.MVC4.Configuration.Ninject
MvcSiteMapProvider.MVC4.Configuration.StructureMap
MvcSiteMapProvider.MVC4.Configuration.Unity
MvcSiteMapProvider.MVC4.Configuration.Windsor
Looking at your source code, it seems like you are referencing multiple versions of the Microsoft.AspNet.Mvc package in MvcSiteMapProvider project. I am not sure this is working as you expect it to since there can be only one version of System.Web.Mvc that can be put in the bin folder during the compilation process (the latest version 5.0.0 will be used).
So any code in your package that depends on Mvc V3 or V4 is not really getting the dll it expects.
Since most of the packages you referenced above like Autofac also have integration package that target specific MVC versions,you may not have an option but to split your package into smaller packages like you mentioned in your post.
A better approach to this problem would be to separate the Core functionality provided by your package which does not have dependency on any version of MVC. You can then create different wrapper packages that depend on your core package and also on a specific version of Microsoft.AspNet.Mvc. And create similar packages for each different Configuration has a nuget dependency on third party packages like Autofac (eg Autofac.Mvc5) and its corresponding version of your MvcSiteMapProvider.MvcX package