Today’s ASP.NET MVC 3 RC2 release works with both the
shipping version of Visual Studio 2010 / Visual Web Developer 2010 Express, as
well as the newly released VS 2010 SP1 Beta.
This means that you do not need to install VS 2010 SP1 (or
the SP1 beta) in order to use ASP.NET MVC 3. It works just fine with the
shipping Visual Studio 2010. I’ll do a blog post next week, though, about
some of the nice additional feature goodies that come with VS 2010 SP1 (including
IIS Express and SQL CE support within VS) which make the dev experience for
both ASP.NET Web Forms and ASP.NET MVC even better.
Bugs and Perf Fixes
Today’s ASP.NET MVC 3 RC2 build contains many bug fixes and
performance optimizations. Our latest performance tests indicate that
ASP.NET MVC 3 is now faster than ASP.NET MVC 2, and that existing ASP.NET MVC
applications will experience a slight performance increase when updated to run
using ASP.NET MVC 3.
Final Tweaks and Fit-N-Finish
In addition to bug fixes and performance optimizations,
today’s RC2 build contains a number of last-minute feature tweaks and
“fit-n-finish” changes for the new ASP.NET MVC 3 features. The feedback
and suggestions we’ve received during the public previews has been invaluable
in guiding these final tweaks, and we really appreciate people’s support in
sending this feedback our way.
Below is a short-list of some of the feature changes/tweaks
made between last month’s ASP.NET MVC 3 RC release and today’s ASP.NET MVC 3
jQuery updates and addition of jQuery UI
The default ASP.NET MVC 3 project templates have been
updated to include jQuery 1.4.4 and jQuery Validation 1.7.
We are also excited to announce today that we are including
jQuery UI within our default ASP.NET project templates going forward.
jQuery UI provides a powerful set of additional UI widgets and
capabilities. It will be added by default to your project’s \scripts
folder when you create new ASP.NET MVC 3 projects.
Improved View Scaffolding
The T4 templates used for scaffolding views with the
Add-View dialog now generates views that use Html.EditorFor instead of helpers
such as Html.TextBoxFor. This change enables you to optionally annotate models
with metadata (using data annotation attributes) to better customize the output
of your UI at runtime.
The Add View scaffolding also supports improved detection
and usage of primary key information on models (including support for naming
conventions like ID, ProductID, etc). For example: the Add View dialog
box uses this information to ensure that the primary key value is not scaffold
as an editable form field, and that links between views are auto-generated
correctly with primary key information.
The default Edit and Create templates also now include references
to the jQuery scripts needed for client validation. Scaffold form views
now support client-side validation by default (no extra steps required).
Client-side validation with ASP.NET MVC 3 is also done using an unobtrusive
[ControllerSessionState] –> [SessionState]
ASP.NET MVC 3 adds support for session-less
controllers. With the initial RC you used a [ControllerSessionState]
attribute to specify this. We shortened this in RC2 to just be [SessionState]:
Note that in addition to turning off session state, you can
also set it to be read-only (which is useful for webfarm scenarios where you
are reading but not updating session state on a particular request).
[SkipRequestValidation] –> [AllowHtml]
ASP.NET MVC includes built-in support to protect against
HTML and Cross-Site Script Injection Attacks, and will throw an error by
default if someone tries to post HTML content as input. Developers need
to explicitly indicate that this is allowed (and that they’ve hopefully built
their app to securely support it) in order to enable it.
With ASP.NET MVC 3, we are also now supporting a new
attribute that you can apply to properties of models/viewmodels to indicate
that HTML input is enabled, which enables much more granular protection in a
DRY way. In last month’s RC release this attribute was named
[SkipRequestValidation]. With RC2 we renamed it to [AllowHtml] to make it
Setting the above [AllowHtml] attribute on a model/viewmodel
will cause ASP.NET MVC 3 to turn off HTML injection protection when model
binding just that property.
Html.Raw() helper method
The new Razor view engine introduced with ASP.NET MVC 3
automatically HTML encodes output by default. This helps provide an
additional level of protection against HTML and Script injection attacks.
With RC2 we are adding a Html.Raw() helper method that you
can use to explicitly indicate that you do not want to HTML encode your output,
and instead want to render the content “as-is”:
ViewModel/View –> ViewBag
ASP.NET MVC has (since V1) supported a ViewData dictionary
within Controllers and Views that enables developers to pass information from a
Controller to a View in a late-bound way. This approach can be used
instead of, or in combination with, a strongly-typed model class. The
below code demonstrates a common use case – where a strongly typed Product
model is passed to the view in addition to two late-bound variables via the
With ASP.NET MVC 3 we are introducing a new API that takes
advantage of the dynamic type support within .NET 4 to set/retrieve these
values. It allows you to use standard “dot” notation to specify any
number of additional variables to be passed, and does not require that you
create a strongly-typed class to do so.
With earlier previews of ASP.NET MVC 3 we exposed this API
using a dynamic property called “ViewModel” on the Controller base class, and
with a dynamic property called “View” within view templates. A lot of
people found the fact that there were two different names confusing, and
several also said that using the name ViewModel was confusing in this context –
since often you create strongly-typed ViewModel classes in ASP.NET MVC, and
they do not use this API.
With RC2 we are exposing a dynamic property that has the
same name – ViewBag – within both Controllers and Views. It is a dynamic
collection that allows you to pass additional bits of data from your controller
to your view template to help generate a response. Below is an example of
how we could use it to pass a time-stamp message as well as a list of all
categories to our view template:
Below is an example of how our view template (which is
strongly-typed to expect a Product class as its model) can use the two extra
bits of information we passed in our ViewBag to generate the response. In
particular, notice how we are using the list of categories passed in the dynamic
ViewBag collection to generate a dropdownlist of friendly category names to
help set the CategoryID property of our Product object.
The above Controller/View combination will
then generate an HTML response like below.