New location is here: https://github.com/aspnet/homebrew-dnx

This shouldn't affect most existing users because GitHub automatically does a redirect from the old name to the new name. If you see any issues due to the rename, please let us know.

If on a Linux machine, dnvm upgrade -u will download new DNX bits but not make dnu or dnx executable. This has already occurred on your machine if you attempted to install dnx-mono.1.0.0-beta6-12085 or later without first updating dnvm.

To avoid the problem, do the following prior to downloading DNX:

dnvm update-self
. ~/.dnx/dnvm/dnvm.sh

If you already have broken DNX packages, either rm -r ~/.dnx/runtimes before doing the above commands and downloading the latest DNX or

chmod +x ~/.dnx/runtimes/dnx-mono.1.0.0-beta6-12085/bin/dnu
chmod +x ~/.dnx/runtimes/dnx-mono.1.0.0-beta6-12085/bin/dnx

(may need to be repeated for later builds as well)

A new command has been added to the dnu command: dnu feeds list. The command lists the NuGet Package Feeds in effect for a particular directory.

If you have a hierarchy of NuGet.Config files defining sources at different levels of the file system, this command allows you to view the feeds that will be used at a particular location in that hierarchy.

For example, if you have the following:

• root\NuGet.Config defines Source1 and Source2
• root\sub\NuGet.Config disables Source1 and adds Source3

Running this command in root\sub would yield results like the following:

Registered Sources
1. Source1 http://... [DISABLED]
2. Source2 http://...
3. Source3 http://...
4. https://www.nuget.org/... ...

(Source 4, nuget.org, is automatically added by default, see the NuGet Documentation for further discussion of NuGet.Config and package sources)

Running the same command in root would yield different results:

Registered Sources
1. Source1 http://...
2. Source2 http://...
3. https://www.nuget.org/... ...

This allows a user to see what sources dnu restore would use before actually running the restore.

In the future, other commands may be added under dnu feeds, but nothing has been decided yet.

See aspnet/dnx#1113 (Issue) and aspnet/dnx#2121 (Pull Request)

I just upgraded my build script (powershell in teamcity) to use dnu and saw that the build was failing. I noticed when I tab-completed the path at the command line everything worked but not when running my build script:

...
try
{
    Push-Location .\src\webapi
    & "C:\Users\dpeden\.dnx\runtimes\dnx-clr-win-x64.1.0.0-beta4\bin\dnu.cmd" build --configuration %Configuration%
    Pop-Location
}
...

I noticed that I had typed the path in all lower case letters which produced the following error:

Building webapi for DNX,Version=v4.5.1
System.InvalidOperationException: Unable to resolve project 'webapi' from C:\TeamCity\buildAgent\work\a6e7f08e2650d279\src\webapi
   at Microsoft.Framework.Runtime.ApplicationHostContext..ctor(IServiceProvider serviceProvider, String projectDirectory, String packagesDirectory, String configuration, FrameworkName targetFramework, ICache cache, ICacheContextAccessor cacheContextAccessor, INamedCacheDependencyProvider namedCacheDependencyProvider, IAssemblyLoadContextFactory loadContextFactory, Boolean skipLockFileValidation)
   at Microsoft.Framework.PackageManager.BuildContext.GetRuntimeLoadContextFactory(Project project)
   at Microsoft.Framework.PackageManager.BuildContext.<>c__DisplayClass16_0.<GetApplicationHostContext>b__0(CacheContext ctx)
   at Microsoft.Framework.Runtime.CacheExtensions.<>c__DisplayClass0_0`1.<Get>b__0(CacheContext ctx)
   at Microsoft.Framework.Runtime.Cache.CreateEntry(Object k, Func`2 acquire)
   at Microsoft.Framework.Runtime.Cache.<>c__DisplayClass5_0.<AddEntry>b__0()
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.LazyInitValue()
   at Microsoft.Framework.Runtime.Cache.Get(Object key, Func`2 factory)
   at Microsoft.Framework.Runtime.CacheExtensions.Get[T](ICache cache, Object key, Func`2 factory)
   at Microsoft.Framework.PackageManager.BuildContext..ctor(IServiceProvider hostServices, IApplicationEnvironment appEnv, ICache cache, ICacheContextAccessor cacheContextAccessor, Project project, FrameworkName targetFramework, String configuration, String outputPath)
   at Microsoft.Framework.PackageManager.BuildManager.Build()
   at Microsoft.Framework.PackageManager.Program.<>c__DisplayClass3_4.<Main>b__8()
   at Microsoft.Framework.Runtime.Common.CommandLine.CommandLineApplication.Execute(String[] args)

Changing Push-Location .\src\webapi to Push-Location .\src\WebApi corrected the problem and produced a successful build.

Hi Team,

Problem:

with things ramping up and more announcements coming forth there's starting to be more noise around each announement, which IMO defeats the purpose of each actual announcement.

TLDR: there's starting to be too much noise from this GH Repo which defeats the purpose of this repo.

Example: The mega discussions about #24 and #28

Suggested Solution

• Discussion Issue: Create an issue about the announcement in the exact repo. This is where any discussion will occur.
• Announcement Issue: Create an announcement issue in this repo and link to the discussion issue.
  Authorised people create a new Issue (which is the actual announcement) in this repo provide a reference to the discussion issue, then lock this issue ASAP.

Example: New command: dnu sources (lets assume this is part of the /aspnet/dnx repo).

• Jump over to https://github.com/aspnet/dnx/issues and create a new issue. eg. [Announcement] New command: dnu sources. Body => Discuss the announcement here. Copy the issue URL for reference.
• Jump back to https://github.com/aspnet/Announcements/issues.
• Create a new issue in this Announcement repo: New command: dnu sources
• Add a reference to the original issue created in /aspnet/dnx/issues
• Lock this issue.

So now, we have the announcement issue which has lots of subscribers and we get notified - yay! 🎉

If anyone wants to chat/discuss this announcement, they have a link to it .. which they click and voila! off they go .. chat chat chat.

... and I (and many others) don't get hit by that conversation.

Rather than have a single LoginPath browsers are redirected to with cookie based authorization fails we have introduced a new AccessDeniedPath property on CookieAuthenticationOptions.

If the LoginPath property is set and a request generates an http error with a status code 401 the request will be redirected to the path specified.

If the AccessDeniedPath property is set and a request generates an http error with a status code 403 the request will be redirected to the path specified.

If the properties are not set then the status codes are returned to the browser.

The VS project file *.kproj was renamed to *.xproj.

An example of this change can be seen here: aspnet/Options@28168db

The contents of the xproj file have also changed slightly for the Props and targets filenames and folders:

Old:

<?xml version="1.0" encoding="utf-8"?>
<Project ...>
  ...
  <Import Project="$(VSToolsPath)\AspNet\Microsoft.Web.AspNet.Props" Condition="'$(VSToolsPath)' != ''" />
  ...
  <Import Project="$(VSToolsPath)\AspNet\Microsoft.Web.AspNet.targets" Condition="'$(VSToolsPath)' != ''" />
</Project>

New:

<?xml version="1.0" encoding="utf-8"?>
<Project ...>
  ...
  <Import Project="$(VSToolsPath)\DNX\Microsoft.DNX.Props" Condition="'$(VSToolsPath)' != ''" />
  ...
  <Import Project="$(VSToolsPath)\DNX\Microsoft.DNX.targets" Condition="'$(VSToolsPath)' != ''" />
</Project>

An example of this change can be seen here: aspnet/Options@ebca4ac

We implemented a new JSON parser in Microsoft.Framework.Runtime and removed the dependency on Newtonsoft.Json.

Using Newtonsoft.Json in the runtime prevents customers from choosing a specific version of Newtonsoft.Json in their applications. This change will allow customers to use any version of Newtonsoft.Json in their applications.

The new JSON parser is customized for internal use. It is used to parse only the project.json, project.lock.json and global.json files.

The new JSON parser doesn't support the following syntax:

1. Comments in the form of // ... and /* ... */
2. Trailing commas after the last member of objects and arrays

Other components, such as Microsoft.Framework.PackageManager, still use Newtonsoft.Json to parse JSON files.

In response to your feedback, we've moved the antiforgery system into its own package: Microsoft.AspNet.Antiforgery. There's now nothing tying this system to MVC, and it has a very lean dependency footprint.

You can find the repository here: https://github.com/aspnet/antiforgery Please use the Antiforgery repo for any issues or suggestions that you have. We'd especially like to know if we've covered all the necessary points of extensibility for using antiforgery outside of MVC.

Beta-6 builds of MVC have now been updated to use the separate package: aspnet/Mvc@2f554c4

Breaking Changes

The new namespace for antiforgery is Microsoft.AspNet.Antiforgery. The Antiforgery facade class now implements IAntiforgery, which is the primary service needed to interact with the antiforgery system. Several APIs on this interface/class have been renamed for clarity.

If you're using MVC, you don't need to do anything extra to add antiforgery services.

If you're not using MVC and want to use antiforgery, there's a new API for adding the required services.

new (Startup.cs)

services.AddAntiforgery();

As antiforgery is now a stand-alone package, configuring options has changed.

old (Startup.cs)

services.ConfigureMvc(options =>
{
    options.AntiForgeryOptions.CookieName = "My-Cookie";
});

new (Startup.cs)

services.ConfigureAntiforgery(options =>
{
    options.CookieName = "My-Cookie";
});

The MVC form TagHelper has add the asp-anti-forgery attribute renamed to asp-antiforgery.

Microsoft.AspNet.Authentication.AuthenticationMiddleware classes now must take ILoggerFactory and IUrlEncoder as constructor arguments. The new Constructor signature is as follows;

    protected AuthenticationMiddleware(
        [NotNull] RequestDelegate next, 
        [NotNull] IOptions<TOptions> options, 
        [NotNull] ILoggerFactory loggerFactory,
        [NotNull] IUrlEncoder encoder,
        ConfigureOptions<TOptions> configureOptions)

We now have separate packages for configuration sources
Microsoft.Framework.Configuration.Ini
Microsoft.Framework.Configuration.EnvironmentVariables
Microsoft.Framework.Configuration.CommandLine

RE: aspnet/HttpAbstractions#190

These two packages have swapped names. Http.Core now contains the abstract base classes for HttpContext, etc, and interfaces like IApplicationBuilder. Http now depends on Http.Core and contains an implementation of those base classes and interfaces with like DefaultHttpContext. Most projects will only need a reference to the Http.Core package.

Note that there is no longer an Http.Core namespace, the items from both packages have been put into the Http namespace.

The aspnet50/aspnetcore50 target framework monikers (TFMs) changed to dnx451/dnx452/dnxcore50.

These monikers are typically used in project.json files in the frameworks section as well as in NuGet packages as subfolders of the lib folder, e.g. lib/net45, lib/dnx451, etc.

The aspnet50 TFM changed to several TFMs, starting out with dnx451 and dnx452 that specify a DNX-compatible assembly based on .NET 4.5.1 and .NET 4.5.2, respectively. A dnx46 TFM will later be added to indicated an DNX-compatible assembly based on .NET 4.6.

The aspnetcore50 TFM changed to dnxcore50 that specifies a DNX-compatible assembly based on .NET Core (Core CLR).

The compiler preprocessor #defines match the TFMs, and for example changed from #if ASPNET50 to #if DNX451.

Example of this change: aspnet/Options@002d3a2

Old project.json:

{
  "frameworks": {
    "net45": { },
    "aspnet50": { },
    "aspnetcore50": {
      "dependencies": {
        "...": "..."
      }
    }
  }
}

New project.json:

{
  "frameworks": {
    "net45": { },
    "dnx451": { },
    "dnxcore50": {
      "dependencies": {
        "...": "..."
      }
    }
  }
}

Old C# file:

#if ASPNET50
    ...
#endif

New C# file:

#if DNX451
    ...
#endif

The Microsoft.AspNet.Security.DataProtection.* packages were renamed to Microsoft.AspNet.DataProtection.*.

In Beta 6, the Entity Framework packages have been renamed to EntityFramework7.*. The meta-package EntityFramework has also been removed. For more information, see NuGet Package Naming and dotnet/efcore#2508.

This issue has been locked to avoid spamming folks subscribed to this repository. Please use dotnet/efcore#2508 for any further discussion.

Update (we reverted this change)

Thanks for all the feedback. We discussed this at length and ultimately decided to revert this change (thus removing the major version from the package names). While we have not been able to come up with any concrete scenarios where the major-version-in-name approach was broken, and there does seem to be value in preventing inadvertent upgrades across major version boundaries, we ultimately agreed that we shouldn't try and do anything special in EF to solve this.

BTW it is worth noting that providers may choose to still use a different package name for each EF major version (in fact some already do this for EF5/6). We will leave this decision up to individual provider writers to do what they feel is best.

In the global.json file the sources node changed to projects.

Example of this change: aspnet/Mvc@833cb1e

Old:

{
    "sources": ["src", "test"]
}

New:

{
    "projects": ["src", "test"]
}

The @layout "...." directive was equivalent to writing:

@{
    Layout = "....";
}

Due to its odd behavior/little value it's been removed.

Razor PR which removed it: aspnet/Razor#367
Razor Issue: aspnet/Razor#359

Adding Microsoft.AspNet.Mvc.Abstractions

We've added a .Abstractions package to consolidate the common extensibility points for MVC and support a simpler dependency management story for authors of redistributable extensions to MVC.

Dependencies

The new Microsoft.AspNet.Mvc.Abstractions package has minimal dependencies. We may try to find a few ways to slim down this list further.

• Routing
• Http (several packages)
• Logging
• Options

Extensibility Contracts

Currently Mvc.Abstractions houses the core interfaces/contracts for:

• Action Constraints (nee ActionMethodSelectorAttribute)
• Action Descriptors / Parameter Descriptors
• Filters
• Formatters
• Model Binders
• ModelStateDictionary
• Model Metadata
• Validators
• Value Providers

Our first cut at creating this package is intentionally conservative, we haven't moved everything, just the most common extensibility points and their dependencies. If you feel a need for something else to be moved into .Abstractions for use in a redistributable extension library please file an issue at: https://github.com/aspnet/Mvc/issues

Merging Microsoft.AspNet.Mvc.ModelBinding

At this time we've also merged our implementations of Model Binders, Model Metadata, Value Providers, and Validation into Mvc.Core. This reinforces the role of Mvc.Core as the package where runtime stuff is located. Since the contracts for these extensibility points are now located in Mvc.Abstractions we saw no great need to keep this package around.

Impact

If your application was referencing Microsoft.AspNet.Mvc then there should should be no impact, continue as you were 👍

If your application was referencing Microsoft.AspNet.Mvc.ModelBinding then remove it and reference Microsoft.AspNet.Mvc. There's no need for applications to include references to the sub-packages, just .Mvc will do.

If your library of extensions to MVC was referencing Microsoft.AspNet.Mvc think about simplifying your dependency management by referencing Microsoft.AspNet.Mvc.Abstractions instead.

If your library of extensions to MVC was referencing Microsoft.AspNet.Mvc.ModelBinding then replace it with Microsoft.AspNet.Mvc.Abstractions instead. If you were referring to our concrete implementations of Model Binding / Validation, then add a reference to Microsoft.AspNet.Mvc.Core.

We changed the assembly name and namespace of Microsoft.Framework.ConfigurationModel to Microsoft.Framework.Configuration.

Configuration class name is changed to ConfigurationSection.

Entity Framework 7 projects that use migrations may encounter breaking changes when upgrading from beta4 to beta5.

Problems

ModelSnapshot

'ApplicationDbContextModelSnapsnot.Model': no suitable method found to override

This error occurs when upgrading an application that used the beta 4 template and EntityFramework is upgraded to beta5.

Fix

To fix this error, delete the file Migrations/ApplicationDbContextModelSnapshot.cs. Regenerate the model snapshot by adding a new migration by running this command from the command prompt in the root folder of the MVC project. dnx . ef migration add Empty.

CreateIdentitySchema migration

A few errors make occur until Migrations/000000_CreateIdentitySchema.cs is changed to match the new Migration API.

'CreateIdentitySchema.Target': no suitable method found to override

The type or namespace name 'BasicModelBuilder' could not be found

Fix

Modify Migrations/000000_CreateIdentitySchema.cs to match the new migrations API.

Convert the Target property in the CreateIdentitySchema class to a method

public override void BuildTargetModel(ModelBuilder builder) 

Remove the instantiation of new BasicModelBuilder() and use instead the ModelBuilder instance passed into this method.

The foreign key API has also changed. Fix the broken foreign key configuration using this pattern:

 builder.Entity("Microsoft.AspNet.Identity.EntityFramework.IdentityRoleClaim<string>", b =>
                {
                    b.Reference("Microsoft.AspNet.Identity.EntityFramework.IdentityRole")
                        .InverseCollection()
                        .ForeignKey("RoleId");
                });

A new distributed cache implementation based on Microsoft SQL Server was checked in few days back.

There are two nuget packages related to this:

• Microsoft.Framework.Caching.SqlServer - Has the actual cache implementation
• Microsoft.Framework.Caching.SqlConfig - Has the 'global' command to set up the database table and indexes

Using this cache requires setting up the database and tables that this implementation understands. Follow the steps below for that:

• Create a database in the SQL server manually.
• Run dnu commands install Microsoft.Framework.Caching.SqlConfig to install the command called sqlservercache
• Run sqlservercache create <connectionstring-to-database> <schema-name> <table-name> to set up the table and indexes.
• Register this cache in DI. Example:

services.AddSqlServerCache(o =>
{
    o.ConnectionString = "Server=localhost;Database=CacheSampleDb;Trusted_Connection=True;";
    o.SchemaName = "dbo";
    o.TableName = "CacheSample";
});

And End-to-end example of using this cache is with Session middleware where session data is stored in database making it available across multiple servers behind a load balancer.

// Registering services
services.AddSqlServerCache(o =>
{
    o.ConnectionString = "Server=localhost;Database=CacheSampleDb;Trusted_Connection=True;";
    o.SchemaName = "dbo";
    o.TableName = "CacheSample";
});
services.AddSession();

// Registering session middleware
app.UseSession();
app.UseMvcWithDefaultRoute();

Code:

• https://github.com/aspnet/Caching/tree/dev/src/Microsoft.Framework.Caching.SqlServer
• https://github.com/aspnet/Caching/tree/dev/src/Microsoft.Framework.Caching.SqlConfig

Samples:

• https://github.com/aspnet/Caching/tree/dev/samples/SqlServerCacheSample

Feedback is welcome

As we know [NotNull] is very helpful to avoid null checking and throw ArgumentNullException, also using nameof operator is helpful too instead of magic strings, I have seen those widely in almost the repos, i already checked them before month ago and made the fix, nothing but i have notice the same thing happen last few weeks. I did the same fix again yesterday and today in almost the repos. Please can someone have a look and merge these changes:
aspnet/HttpAbstractions#327
aspnet/WebSockets#40
aspnet/SignalR-SqlServer#13
aspnet/Testing#123
aspnet/MusicStore#498
aspnet/Mvc#2690
aspnet/Security#287
aspnet/SignalR-ServiceBus#8
aspnet/FileSystem#109
https://github.com/aspnet/HttpClient/pull/26
aspnet/Identity#485
aspnet/dnx#2047

I hope you take this in mind before merge any PR to avoid such things in the future

Will package versions be specified in global.json?

"sources" will be removed in beta5

Hi all, I wanted to share with you some of the changes that are coming for beta-5 of MVC and some of the rationale about why we're changing [Activate]

What's changing

We're removing [Activate] totally and simplifying some of the things it was possible to accomplish using it. Where [Activate] was used to access context-objects from the current request, it will be replaced by bespoke attributes to handle the supported cases. We've also trimming down the number of context-objects that are available so that it's clear what is supported. Where [Activate] was used to access items from the HttpContext.RequestServices (DI), use constructor injection in its place.

[FromServices] is still supported in controllers on action parameters, public controller properties and model properties. There are no changes to [FromServices] in beta-5.

There are no changes to @inject for beta-5.

Overall there should be very little impact on MVC code unless you're making very heavy use of POCO-style controllers and view components.

POCO Controller Sample

Before:

public class MyController
{
    [Activate]
    public ActionContext ActionContext { get; set; }

    [Activate]
    public HttpContext HttpContext { get; set; }
}

After:

public class MyController
{
    [ActionContext]
    public ActionContext ActionContext { get; set; }

    public HttpContext HttpContext => ActionContext.HttpContext
}

POCO ViewComponent Sample

Before:

public class MyViewComponent
{
    [Activate]
    public IRespository Repository { get; set; }

    [Activate]
    public ViewContext ViewContext { get; set; }
}

After:

public class MyViewComponent
{
    public MyViewComponent(IRepository repository)
    {
        Repository = repository;
    }

    public IRespository Repository { get; }

    [ViewComponentContext]
    public ViewComponentContext ViewComponentContext { get; set; }
}

TagHelper Sample

Before:

public class MyTagHelper : TagHelper
{
    [HtmlAttributeNotBound]
    [Activate]
    public IHtmlEncoder Encoder { get; set; }

    [HtmlAttributeNotBound]
    [Activate]
    public ViewContext ViewContext { get; set; }
}

After:

public class MyTagHelper : TagHelper
{
    public MyTagHelper(IHtmlEncoder encoder)
    {
        Encoder = encoder;
    }

    public IHtmlEncoder Encoder { get; }

    [HtmlAttributeNotBound]
    [ViewContext]
    public ViewContext ViewContext { get; set; }
}

About [Activate]

We originally created [Activate] to solve an implementation problem - how do you get ActionContext and other things into a controller without requiring the user to do this?

public class MyController : Controller
{
    public MyController(ActionContext context)
        : base(context)
    { }
}

We want writing controllers to have the minimum of boilerplate possible, so we created an attribute ([Activate]) that would tell the controller factory to inject certain known types. When we introduced new concepts (TagHelpers, ViewComponents), [Activate] came along for the ride to get the required context into those types.

Once we added the ability to inject arbitrary types from DI with [Activate], we realized that we'd built a secondary DI system that was specific to MVC and that only applied to a few concepts in the framework.

Our goal had always been to play nicely with 3rd party DI so that we could enable the use of the advanced concepts that dedicated DI systems can provide. Each piece of functionality we layer on top is another puzzle to solve for integration with a system like Ninject or Autofac (or your container of choice). We'd rather reset this and build towards a good integrated experience.

We've heard plenty of feedback on aspnet/Mvc#2151 asking us to embrace a merger between DI concepts and [Activate]. Our decision for now is that if there's a significant demand for more powerful DI features, then we should prioritize hooking up existing 3rd party DI solutions to fill the gap. We've done some enabling work for using DI to construct controllers, we might need to go further.

About [FromServices]

This is something we invented when revisiting model binding, and really grew independently of [Activate]. We've heard feedback in the context of the [Activate]/@inject discussion that [FromServices] is a bit awkward and oddball. We're still listening, but have chosen to do nothing for this release.

About @inject

We really feel like @inject is doing what we want it to from a usability standpoint. We heard the feedback loud and clear that everyone is happy with it, so it's staying put.

We don't feel like the many of the concerns we have about [Activate] can be applied to Razor code. Razor has a unique programming style and wouldn't support configuring many of the advanced DI features anyway (since you're not declaring constructors and properties).

The Future

We're still listening to feedback about this even though we're moving in a different direction. We want DI to be part of the Asp.Net platform as a whole, and don't want MVC to have a 'quirks mode' for certain framework pieces. Nothing here is set in stone, this is an iteration and it's still a beta release.

We'd love to see code samples of things you think are too hard or too verbose to do with these changes.

Entity Framework 7 beta 5 contains minor change to a commonly used API that will affect users upgrading from previous betas. The class DbContextOptionsBuilder was temporarily renamed to EntityOptionsBuilder for this release. This class rename will break users' code that overrides the OnConfiguring method of DbContext.

This issue only affects beta 5 and will be fixed in upcoming beta releases.

Solution
Change the signature of OnConfiguring to match the renamed class.

     protected override OnConfiguring(EntityOptionsBuilder optionsBuilder)

Remember
This will need to be changed back when upgrading to beta 6 because this build reverts to DbContextOptionsBuilder.

The kvm (K Version Manager) command was renamed to dnvm (applies both the *nix shell scripts and to Windows PowerShell *.ps1 script).

The _GlobalImport.cshtml file introduced in MVC 6.0 Beta 3 has been renamed to _ViewImports.cshtml in Beta 5. Rename files in your projects for MVC to continue to honor the contained directives.

For more information please see MVC issue aspnet/Mvc#2489. For an example change reacting to this update, please see aspnet/MusicStore@3bdaec5.

What is it?

We've split up the MVC runtime features into a set of more granular packages based on what features they provide and what dependencies they have.

For most users there will be no change, and you should continue to use AddMvc() and UseMvc(...) in your startup code.

For the truly brave, there's now a configuration experience where you can start with a minimal MVC pipeline and add features to get a customized framework.

public void ConfigureServices(IServiceCollection services)
{
    services
        .AddMvcCore()
        .AddAuthorization()
        .AddJsonFormatters(j => j.Formatting = Formatting.Indented);
}

AddMvcCore() is an advanced experience that gives an application developer fine-grained control over what features are provided by MVC - you can mix and match dependencies with 3rd party frameworks, or avoid dependencies altogether that aren't needed.

For 3rd party library authors, this change allows you to target a more minimal set of dependencies if your requirements allow it.

Breaking Changes

Some options that used to be on MvcOptions have moved:

• AntiforgeryOptions - use ConfigureAntiforgery(...)
• ClientModelValidatorProviders - use ConfigureMvcViews(...)
• HtmlHelperOptions - use ConfigureMvcViews(...)
• SerializerSettings (JSON.NET) - use ConfigureMvcJson
• ViewEngines - use ConfigureMvcViews(...)

If you're using AddMvc() we don't intend any changes in functionality other than the options changes.

If you're using AddMvcCore() configuring relevant options is more streamlined when adding a feature to the builder. The various Add<feature>(...) extensions methods take an Action<T> which will point you more directly to what's configurable for that feature.

    services
        .AddMvcCore()
        .AddJsonFormatters(SerializerSettings json => json.Formatting = Formatting.Indented);

Feedback

For anyone experimenting with AddMvcCore(...) we'd like to know about any surprises you encounter. Does something work that shouldn't? Does something break that should be available?

Regarding the layering, what chunks of features are the right size? What should be broken down smaller? Are things to granular?

Please include what you're trying to accomplish (what kind of site are you building) when leaving feedback. If you don't include this information, I'm just going to ask for it anyway 👍

Description of Packages/Features

Here's an updated listing of each package, as well as what Add<feature>(...) methods are exposed by each.

Microsoft.AspNet.Mvc.Abstractions

Defines the core abstractions for MVC.

Microsoft.AspNet.Mvc.Core

Defines the implementation of the MVC runtime features. This is the only required reference to produce something that can serve requests using AddMvcCore(...).

AddMvcCore(...) - adds the minimal runtime services, and returns an IMvcBuilder to compose with other features.

Also

AddFormatterMappings(...) - adds support for maping file-extensions in the URL to content-types.

And

AddAuthorization(...) - adds support for discoving [Authorize(...)] attributes on controllers and actions and applying authorization policy. This must be used with an authorization middleware, and only adds support for MVC to recognize the attributes.

Microsoft.AspNet.Mvc.ApiExplorer

Defines the implementation of the IApiDescriptionProvider and other infrastructure for describing API endpoints in an application. Required if using Swashbuckle or a similar package.

AddApiExplorer(...) - adds the API Explorer services.

Microsoft.AspNet.Mvc.Cors

Defines the discovery and implementation of CORS policies to be applied at the action or controller level in MVC. Adding these services will allow MVC to recognize [EnableCors(...)] and [DisableCors] attributes.

AddCors(...) - adds the CORS services. Also adds the services from Microsoft.AspNet.Cors.Core to the service collection (like calling services.AddCors()).

Microsoft.AspNet.Mvc.DataAnnotations

Defines the ModelMetadata and validation support for the attributes defined in System.ComponentModel.DataAnnotations. Almost no request validation will take place without including these validators.

AddDataAnnotations(...) - adds model metadata and validation support for data annotations attributes.

Microsoft.AspNet.Mvc.Formatters.Json

Includes the JSON input and output formatters and also the JSON-patch input formatter - using Json.NET. Includes JsonResult.

AddJsonFormatters(...) - adds the JSON and JSON-patch formatters

Using AddJsonFormatters(...) isn't required to use JsonResult, but it's the recommended way to configure the shared SerializerSettings.

Microsoft.AspNet.Mvc.Formatters.Xml

Includes the XML input/output formatters for using XmlSerializer or DataContractSerializer.

For now for don't have an updated way of configuring these formatters 😞. You'll have to use options.AddXmlDataContractSerializerFormatter(...) for DCS, and using XmlSerializer is somewhat more manual.

Microsoft.AspNet.Mvc.Localization

Includes services for producing localized text in Razor Views.

For now we don't have an updated way of configuring these services. Use services.AddMvcLocalization(...).

Microsoft.AspNet.Mvc.Razor

Includes services for using the Razor view engine implementation in MVC.

AddRazorViewEngine(...) - adds the Razor view engine. Calling AddRazorViewEngine(...) also calls AddViews(...) to add the basic view support and rendering features.

Microsoft.AspNet.Mvc.Razor.Host

Includes implementation of Razor code generation for MVC. Used as a dependency by Microsoft.AspNet.Mvc.Razor and by tooling.

Microsoft.AspNet.Mvc.TagHelpers

Includes implementations of TagHelpers for MVC. Used as a dependency by Microsoft.AspNet.Mvc.ViewFeatures.

Microsoft.AspNet.Mvc.ViewFeatures

Includes the definitions of view abstractions IView, IViewEngine and implementations of IHtmlHelper, View Components, IJsonHelper and other view rendering features. Includes the definition of Controller.

AddViews(...) - adds view rendering features. Will also add services for AddDataAnnocations(...) as well as Antiforgery, Data Protection, and Web Encoders.

Note that AddViews(...) on its own isn't complete, you will need to add a view engine to actually use views.

Microsoft.AspNet.Mvc.WebApiCompatShim

This is a compatibility package for porting WebAPI 2 applications. It doesn't mix and match with the AddMvcCore(...) experience.

Microsoft.AspNet.PageExecutionInstrumentation.Interfaces

Infrastructure for BrowserLink. Ignore this.

RE:
aspnet/HttpAbstractions#295
#8

Http.Abstractions – HttpContext (abstract), referenced by middleware, Http, and applications
Http – DefaultHttpContext (implementation), referenced by Hosting (no change)
Http.Features – Feature interfaces & POCOs, referenced by Http and Servers

Note that all of these items are use the Http namespace, there are no Abstractions or Features namespaces.

TL;DR;

dnu sources get <package-name> will retrieve the source code for the package named <package-name>

The feature is in a very early stage and we've rolled it out to get feedback. Please let us know what you think. See Limitations at the end of this post.

A few months ago I wrote an article about debugging ASP.NET 5 framework code. While not impossible, it is hard to determine which commit produced a particular package if the commit was not tagged.

Today, we are excited to announce dnu sources, a new feature that will simplify the process of getting source files for packages.

dnu sources allows you to get the source code for a particular package, without you having to look online for it.

How to add repository information to a package

In order for a package to support dnu sources it must include some new information in the project.json file.

"repository": { 
    "type": "git", 
    "url": "https://github.com/aspnet/options" 
}

source

In addition to the new repository property, the following conditions must be satisfied:

1. The source code must be in a Git repository at build time
2. Git must be installed on the machine and added to the PATH

The embed repository information, simply build the package (dnu pack),

How to get the sources for a package

If a package has source information, you will be able to run dnu sources get <package> name to retrieve the sources for <package>.

Conditions for running dnu sources

1. The project must have a reference to package you are trying to source.
2. The package must be installed locally

Try it out

1. Add the following reference to project.json: Microsoft.Framework.OptionsModel.
2. Restore the packages using Visual Studio or by running dnu restore
3. In the project's folder, run dnu sources get Microsoft.Framework.OptionsModel

Limitations

1. If you don't have the dev feed (myget.org/aspnetvnext) as a NuGet source and the package references any of the *.Sources packages (like Microsoft.Framework.NotNullAttribute.Sources), you will not be able to compile the new sources. The workaround is to add the feed to NuGet.config.
2. If you application references multiple versions of the same package, you will not be able to use dnu source
3. Each version of a package will create a new folder under %userprofile%\.dnx\sources. That folder is never cleaned up.
4. Currently, only the packages shipped by the ASP.NET and EF teams have source information. The CLR packages (System*), Roslyn or any other packages does not have source information. You will get an error message if you try to source them.
5. Only Git is supported.
6. There is no first class Visual Studio support.
7. dnu sources works only for packages produced in beta6 or later. Any beta5 or earlier packages do not have source information in them.

Use this thread for further discussions.

DNX builds from the aspnetvnext feed (starting with 1.0.0-beta7-12264) contain some changes that break older packages. If you encounter issues using a Beta7 DNX or Package, ensure your DNX and Packages are all up to date with the latest from the aspnetvnext feed.

I'll collect a set of known symptomatic error messages below. If you are seeing one of the below error messages, you're probably falling victim to this issue.

Related Issue: aspnet/dnx#2225
Related PR: aspnet/dnx#2261

for beta3 I set KRE_TRACE to have debug log, what's the equivalent for beta4 ?

The core runtime, tools, and NuGet packages are installed into a sub-folder in %USERPROFILE%. Previous names of these folders were .k, .kpm, and .kre.

The new folders are all structured under a top-level .dnx folder, but otherwise have very similar contents to what they used to have.

%USERPROFILE%\.dnx\alias\default.txt
%USERPROFILE%\.dnx\packages\<NuGet packages>
%USERPROFILE%\.dnx\runtimes\dnx-clr-win-x64.1.0.0-beta4\...
%USERPROFILE%\.dnx\runtimes\dnx-clr-win-x86.1.0.0-beta4\...
%USERPROFILE%\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta4\...
%USERPROFILE%\.dnx\runtimes\dnx-coreclr-win-x86.1.0.0-beta4\...

You can now use the latest DNX builds from the dev feed alongside the Beta6 version of the ASP.NET Tools (available here: http://blogs.msdn.com/b/webdev/archive/2015/07/27/announcing-availability-of-asp-net-5-beta-6.aspx) without the environment variable described below. As long as you have the beta6 tools and a DNX build greater than or equal to 1.0.0-beta7-12290, the environment variable should not be necessary (in fact, you should remove it).

Visual Studio 2015 RTM shipped with code to handle a new set of names for DNX runtime assemblies. Unfortunately, these renames have not yet landed in the aspnetvnext feed, so the Visual Studio experience is broken when working with the latest DNX builds from aspnetvnext.

A fix is coming soon in the form of an updated version of the ASP.NET Visual Studio tools, but in the interim, you can set the WEBPROJ_ENABLEBETA7RENAMES environment variable to 0 to disable the use of the renamed assemblies. We recommend setting this value in your User-level environment variables until you can install the updated version of the tooling.

If you are seeing IntelliSense issues with DNX projects, this may fix the problem.

If you are working with Beta6 (or lower) packages and DNX, NO ACTION IS REQUIRED

We no longer support [Authorize(Users="")].

You should migrate to role based authorization, or implement your own authorization policy which authorizes based on user names.

Authentication handlers have now dropped their synchronous methods and are fully async

In addition to this there has been method renames;

protected override AuthenticationTicket AuthenticateCore()

has now become

protected override async Task<AuthenticationTicket> HandleAuthenticateAsync()

protected override void ApplyResponseChallenge()

has been split and now becomes

protected override async Task<bool> HandleUnauthorizedAsync(ChallengeContext context)
protected override async Task<bool> HandleForbiddenAsync(ChallengeContext context)

Discussion - aspnet/Security#379

Old code:

public Startup(IHostingEnvironment env)
{
      // Setup configuration sources.
      Configuration = new Configuration()
         .AddJsonFile("config.json")
         .AddEnvironmentVariables();
}

This will throw the following exception now:

System.InvalidOperationException: Unable to resolve path 'config.json'; construct this IConfigurationSourceRoot with a non-null BasePath.

New code:

public Startup(IHostingEnvironment env, IApplicationEnvironment appEnv)
{
      // Setup configuration sources.
      Configuration = new Configuration(appEnv.ApplicationBasePath)
         .AddJsonFile("config.json")
         .AddEnvironmentVariables();
}

The Microsoft.AspNet.Security.* packages and namespaces have been renamed to Microsoft.AspNet.Authentication.*.

The fix is to update the package references in project.json and the namespaces in various using statements.

Changeset: aspnet/Security@775eb5e

ASP.NET authorization now supports code based policies. We provide implementations to support claims based authorization and the ability to express your own policies in code. An authorization policy must contain one or more requirements.

Policy configuration is done within ConfigureServices(...) within Startup.cs.

A simple policy to check for the presence of a claim would be configured as follows

services.ConfigureAuthorization(options =>
{
    options.AddPolicy("MustBeGroot", policy => policy.RequireClaim("IAmGroot"));
}

and would be applied as [Authorize(Policy="MustBeGroot")].

You can also specify a list of comma separated values as part of the claim requirement, for example

options.AddPolicy("MustBeGroot", policy => policy.RequireClaim("Permissions", "Read,Update"));

which would pass authorization if the Permissions claim had a value or either Read or Update.

A more complicated requirement would involve implementing IAuthorizationRequirement and an AuthorizationHandler. For example if your identity had a DateOfBirth claim and you wanted to implement a minimum age requirement it could look like

public class MinimumAgeRequirement : AuthorizationHandler<MinimumAgeRequirement>, IAuthorizationRequirement
{
    public MinimumAgeRequirement(int age)
    {
        MinimumAge = age;
    }

    protected int MinimumAge { get; set; }

    public override void Handle(AuthorizationContext context, MinimumAgeRequirement requirement)
    {
        if (!context.User.HasClaim(c => c.Type == ClaimTypes.DateOfBirth))
        {
            return;
        }

        var dateOfBirth = Convert.ToDateTime(context.User.FindFirst(c => c.Type == ClaimTypes.DateOfBirth).Value);

        int calculatedAge = DateTime.Today.Year - dateOfBirth.Year;
        if (dateOfBirth > DateTime.Today.AddYears(-calculatedAge))
        {
            calculatedAge--;
        }

        if (calculatedAge >= MinimumAge)
        {
            context.Succeed(requirement);
        }
    }
}

You could then configure it

options.AddPolicy("Over21", 
    policy => policy.Requirements.Add(new Authorization.MinimumAgeRequirement(21)));

and apply it via [Authorize(Policy="Over21")].

Finally you can use policy to limit the authentication schemes checked during authorization, for example

options.AddPolicy("WebApi", policy =>
{
     policy.ActiveAuthenticationSchemes.Add("Bearer");
     policy.RequireAuthenticatedUser();
});

would only allow requests which provide an identity to Bearer middleware to access the resource behind them.

In beta3, AppDomain.CurrentDomain.BaseDirectory pointed to the physical path of the hosted project. In beta4, it now points to your dnx runtime bin (e.g., C:\\Users\\dpeden\\.dnx\\runtimes\\dnx-clr-win-x86.1.0.0-beta4\\bin).

What is the proper way to get the physical path of the currently executing project in dnx451?

How do I get beta 5 for EF in VS 2015 RC??

The Microsoft.AspNet.FileProviders package has been removed and replaced with:
Microsoft.AspNet.FileProviders.Physical
Microsoft.AspNet.FileProviders.Embedded
Microsoft.AspNet.FileProviders.Interfaces

See aspnet/FileSystem#48

If you run into any errors saying that a type exists in 2 places, and one is XX.Interfaces and the other is XX.Abstractions, chances are you have old and new packages in the same project.

Previous versions used ClaimsIdentity as part of the middleware contract.

Any Authorization middleware which sets or expects a ClaimsIdentity must be updated to use a ClaimsPrincipal.

DNVM now supports installing non-native runtimes using the new -OS flag.
As well as showing the Operating system in dnvm list
dnvm list also now has the -detailed flag to show Location of dnx runtime

We also removed a feature on Unix systems with dnvm list:
Previously: dnvm list 1.0.0-* would show 1 entry using the "regex" provided
Now: dnvm list ignores invalid arguments

Related issue: aspnet/dnvm#332
Related PR: aspnet/dnvm#276

In Beta 6, the format of the project.lock.json file will be stabilized and the version will be set to 1. Attempting to run a project using Beta 6, where dnu restore was run with a Beta 5 or lower DNX, will fail with various unresolved dependency errors, as it will ignore the lock file because the version is incompatible. To solve this, just re-run dnu restore using the Beta 6 DNX.

What you might see: Errors resolving dependencies at run- or build-time

How to fix it: Re-run dnu restore

This was a design change that allows command line hosting to be run without a tty