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.
Related
I'm trying to add .net 45 reference to a asp.net 5 starter web project..and i'm getting this errors.
While it is true that you can target multiple frameworks in a way similar to how you've done in your example, I think you will probably not be able to get the StarterWeb project to run under .NET 4.5 without some significant changes.
When dealing with multiple frameworks, Visual Studio 2015 will actually provide a lot of help if you hover the mouse over the code with errors:
One obvious difficulty in getting the StarterWeb project working is that between MVC 5 and 6, a number of pieces have been moved into new namespaces and broken up into different assemblies. Most notably, the MVC 5 package depends on System.Web, whereas the 6.0 beta that is used by the StarterWeb project does not. With the MVC libraries moved, the Authorize attribute is now in Microsoft.Aspnet.Mvc, whereas in earlier versions it belonged to System.Web.Mvc.
While in theory you could probably target different versions of MVC across the frameworks, in practice that would probably not be worth the trouble. Even if you find Authorize, there's no guarantee that it will be the "same" one, even if it compiles.
If that is a route you want to go (or just when targeting multiple frameworks in general), you have control over which packages are used by which framework in the project.json file.
If packages are compatible with all of the targeted frameworks, you can leave them in the parent dependencies area of the project.json file, but when they are specific to a given framework, you need to add a child dependencies section to that particular framework's configuration. In the case of .NET 4.5, you can also add familiar framework assemblies (as opposed to NuGet packages) by adding a frameworkAssemblies section.
You will end up with something like this:
"dependencies": {
"SomeCommonPackage":"1.0.0"
},
"frameworks": {
"aspnet50":{
"dependencies":{
"Aspnet50SpecificPackage":"1.0.0"
},
"net45":{
"dependencies":{
"NET45SpecificPackage":"1.0.0"
},
"frameworkAssemblies":{
"System.Web":"4.0.0.0"
}
When you target these different frameworks, you will often find that at least some code will have to framework-specific. To handle this, you can add compiler directives for the various using statements and the actual code that depends on packages only available in one framework or another.
For example, you may end up with areas that look something like this:
SomeType result;
#if ASPNET50
result = SomeMethodNotAvailableIn45( );
#endif
#if NET45
result = EquivalentMethodIn45( );
#endif
Obviously that is overly simplistic, but it gives you the basic formula:
Put shared dependencies in the root dependencies section
Put dependencies specific to a given framework in its own dependencies section
Use compiler directives for framework-specific code that can't be shared
I also would recommend you take a look at Rick Strahl's excellent blog post to see a great walk-through of targeting multiple frameworks with more detail and lots of screenshots. One nice feature of the new project system is that it can easily create a NuGet package for all of the frameworks you choose to target, and he goes into more detail about that as well.
Adding a .NET 4.5 project that is in the same solution as a reference to a vNext project still doesn't work in VS2015 RTM/ASP.NET Beta5. The project just can't seem to find the source/binary and tries looking in nuget for it. I followed the recommended steps with global.json, dnx451 dependencies.
My work around was to
Make the .NET 4.5 project pack a nuget package in post build step
Add a package source location to the local package file
This way I can speed up development cycle without requiring a nuget publish. One wrinkle is that relative package source paths using a $ are replaced with absolute paths.
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
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.