aspnet / announcements Goto Github PK
View Code? Open in Web Editor NEWSubscribe to this repo to be notified about major changes in ASP.NET Core and Entity Framework Core
License: Other
Subscribe to this repo to be notified about major changes in ASP.NET Core and Entity Framework Core
License: Other
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.
This was a design change that allows command line hosting to be run without a tty
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
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 implementationMicrosoft.Framework.Caching.SqlConfig
- Has the 'global' command to set up the database table and indexesUsing this cache requires setting up the database and tables that this implementation understands. Follow the steps below for that:
dnu commands install Microsoft.Framework.Caching.SqlConfig
to install the command called sqlservercache
sqlservercache create <connectionstring-to-database> <schema-name> <table-name>
to set up the table and indexes.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:
Samples:
Feedback is welcome
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?
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.
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
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.
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
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
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
Hi Team,
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
Example: New command: dnu sources (lets assume this is part of the /aspnet/dnx
repo).
[Announcement] New command: dnu sources
. Body => Discuss the announcement here. Copy the issue URL for reference.New command: dnu sources
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.
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
.
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
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.
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"]
}
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.
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"
}
In addition to the new repository
property, the following conditions must be satisfied:
The embed repository information, simply build the package (dnu pack
),
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
project.json
: Microsoft.Framework.OptionsModel
.dnu restore
dnu sources get Microsoft.Framework.OptionsModel
*.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.dnu source
%userprofile%\.dnx\sources
. That folder is never cleaned up.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.
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)
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 #define
s 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
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.
We changed the assembly name and namespace of Microsoft.Framework.ConfigurationModel
to Microsoft.Framework.Configuration
.
Configuration
class name is changed to ConfigurationSection
.
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.
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 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:
// ...
and /* ... */
Other components, such as Microsoft.Framework.PackageManager
, still use Newtonsoft.Json
to parse JSON files.
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)
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.
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
How do I get beta 5 for EF in VS 2015 RC??
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();
}
Entity Framework 7 projects that use migrations may encounter breaking changes when upgrading from beta4 to beta5.
'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.
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
.
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
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");
});
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.
The new Microsoft.AspNet.Mvc.Abstractions
package has minimal dependencies. We may try to find a few ways to slim down this list further.
Currently Mvc.Abstractions
houses the core interfaces/contracts for:
ActionMethodSelectorAttribute
)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
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.
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
.
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
.
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.
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.
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);
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 ๐
Here's an updated listing of each package, as well as what Add<feature>(...)
methods are exposed by each.
Defines the core abstractions for MVC.
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.
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.
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()
).
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.
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
.
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.
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(...)
.
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.
Includes implementation of Razor code generation for MVC. Used as a dependency by Microsoft.AspNet.Mvc.Razor
and by tooling.
Includes implementations of TagHelpers for MVC. Used as a dependency by 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.
This is a compatibility package for porting WebAPI 2 applications. It doesn't mix and match with the AddMvcCore(...)
experience.
Infrastructure for BrowserLink. Ignore this.
The Microsoft.AspNet.Security.DataProtection.*
packages were renamed to Microsoft.AspNet.DataProtection.*
.
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
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
.
The Microsoft.AspNet.FileProviders package has been removed and replaced with:
Microsoft.AspNet.FileProviders.Physical
Microsoft.AspNet.FileProviders.Embedded
Microsoft.AspNet.FileProviders.Interfaces
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.
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.
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
"sources" will be removed in beta5
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\...
Will package versions be specified in global.json?
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.
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
for beta3 I set KRE_TRACE to have debug log, what's the equivalent for beta4 ?
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]
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.
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
}
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; }
}
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; }
}
[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.
[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.
@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).
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.