Tuesday 17 July 2012

ASP.NET MVC 4 Release Notes

Installation Notes

ASP.NET MVC 4 Release Candidate for Visual Studio 2010 can be installed from the ASP.NET MVC 4 home page using the Web Platform Installer.

We recommend uninstalling any previously installed previews of ASP.NET MVC 4 prior to installing ASP.NET MVC 4 Release Candidate. You can upgrade the ASP.NET MVC 4 Developer Preview and Beta to ASP.NET MVC 4 Release Candidate without uninstalling.

This release is not compatible with the .NET Framework 4.5 Developer Preview or Beta. You must separately upgrade the .NET 4.5 Developer Preview and the .NET 4.5 Beta to .NET 4.5 Release Candidate when installing the ASP.NET MVC 4 Release Candidate. The .NET Framework 4.5 RC can be downloaded at http://go.microsoft.com/fwlink/?LinkId=251397

ASP.NET MVC 4 can be installed and run side-by-side with ASP.NET MVC 3.

Documentation

Documentation for ASP.NET MVC is available on the MSDN website at the following URL:

http://go.microsoft.com/fwlink/?LinkID=243043

Tutorials and other information about ASP.NET MVC are available on the MVC 4 page of the ASP.NET website (http://www.asp.net/mvc/mvc4).

Support

This is a preview release and is not officially supported. If you have questions about working with this release, post them to the ASP.NET MVC forum (http://forums.asp.net/1146.aspx), where members of the ASP.NET community are frequently able to provide informal support.

Software Requirements

The ASP.NET MVC 4 components for Visual Studio require PowerShell 2.0 and either Visual Studio 2010 with Service Pack 1 or Visual Web Developer Express 2010 with Service Pack 1.

New Features in ASP.NET MVC 4 Release Candidate

This section describes features that have been introduced in the ASP.NET MVC 4 Release Candidate release.

ASP.NET Web API

ASP.NET MVC 4 includes ASP.NET Web API, a new framework for creating HTTP services that can reach a broad range of clients including browsers and mobile devices. ASP.NET Web API is also an ideal platform for building RESTful services.

ASP.NET Web API includes support for the following features:

  • Modern HTTP programming model: Directly access and manipulate HTTP requests and responses in your Web APIs using a new, strongly typed HTTP object model. The same programming model and HTTP pipeline is symmetrically available on the client through the new HttpClient type.
  • Full support for routes: ASP.NET Web API supports the full set of route capabilities of ASP.NET Routing, including route parameters and constraints. Additionally, use simple conventions to map actions to HTTP methods.
  • Content negotiation: The client and server can work together to determine the right format for data being returned from a web API. ASP.NET Web API provides default support for XML, JSON, and Form URL-encoded formats and you can extend this support by adding your own formatters, or even replace the default content negotiation strategy.
  • Model binding and validation: Model binders provide an easy way to extract data from various parts of an HTTP request and convert those message parts into .NET objects which can be used by the Web API actions. Validation is also performed on action parameters based on data annotations.
  • Filters: ASP.NET Web API supports filters including well-known filters such as the [Authorize] attribute. You can author and plug in your own filters for actions, authorization and exception handling.
  • Query composition: Use the [Queryable] filter attribute on an action that returns IQueryable to enable support for querying your web API via the OData query conventions.
  • Improved testability: Rather than setting HTTP details in static context objects, web API actions work with instances of HttpRequestMessage and HttpResponseMessage. Create a unit test project along with your Web API project to get started quickly writing unit tests for your Web API functionality.
  • Code-based configuration: ASP.NET Web API configuration is accomplished solely through code, leaving your config files clean. Use the provide service locator pattern to configure extensibility points.
  • Improved support for Inversion of Control (IoC) containers: ASP.NET Web API provides great support for IoC containers through an improved dependency resolver abstraction
  • Self-host: Web APIs can be hosted in your own process in addition to IIS while still using the full power of routes and other features of Web API.
  • Create custom help and test pages: You now can easily build custom help and test pages for your web APIs by using the new IApiExplorer service to get a complete runtime description of your web APIs.
  • Monitoring and diagnostics: ASP.NET Web API now provides light weight tracing infrastructure that makes it easy to integrate with existing logging solutions such as System.Diagnostics, ETW and third party logging frameworks. You can enable tracing by providing an ITraceWriter implementation and adding it to your web API configuration.
  • Link generation: Use the ASP.NET Web API UrlHelper to generate links to related resources in the same application.
  • Web API project template: Select the new Web API project form the New MVC 4 Project wizard to quickly get up and running with ASP.NET Web API.
  • Scaffolding: Use the Add Controller dialog to quickly scaffold a web API controller based on an Entity Framework based model type.

For more details on ASP.NET Web API please visit http://www.asp.net/web-api.

Enhancements to Default Project Templates

The template that is used to create new ASP.NET MVC 4 projects has been updated to create a more modern-looking website:

In addition to cosmetic improvements, there’s improved functionality in the new template. The template employs a technique called adaptive rendering to look good in both desktop browsers and mobile browsers without any customization.

To see adaptive rendering in action, you can use a mobile emulator or just try resizing the desktop browser window to be smaller. When the browser window gets small enough, the layout of the page will change.

Mobile Project Template

If you’re starting a new project and want to create a site specifically for mobile and tablet browsers, you can use the new Mobile Application project template. This is based on jQuery Mobile, an open-source library for building touch-optimized UI:

This template contains the same application structure as the Internet Application template (and the controller code is virtually identical), but it's styled using jQuery Mobile to look good and behave well on touch-based mobile devices. To learn more about how to structure and style mobile UI, see the jQuery Mobile project website.

If you already have a desktop-oriented site that you want to add mobile-optimized views to, or if you want to create a single site that serves differently styled views to desktop and mobile browsers, you can use the new Display Modes feature. (See the next section.)

Display Modes

The new Display Modes feature lets an application select views depending on the browser that's making the request. For example, if a desktop browser requests the Home page, the application might use the Views\Home\Index.cshtml template. If a mobile browser requests the Home page, the application might return the Views\Home\Index.mobile.cshtml template.

Layouts and partials can also be overridden for particular browser types. For example:

  • If your Views\Shared folder contains both the _Layout.cshtml and _Layout.mobile.cshtml templates, by default the application will use _Layout.mobile.cshtml during requests from mobile browsers and _Layout.cshtml during other requests.
  • If a folder contains both _MyPartial.cshtml and _MyPartial.mobile.cshtml, the instruction @Html.Partial("_MyPartial") will render _MyPartial.mobile.cshtml during requests from mobile browsers, and _MyPartial.cshtml during other requests.

If you want to create more specific views, layouts, or partial views for other devices, you can register a new DefaultDisplayMode instance to specify which name to search for when a request satisfies particular conditions. For example, you could add the following code to the Application_Start method in the Global.asax file to register the string "iPhone" as a display mode that applies when the Apple iPhone browser makes a request:

DisplayModeProvider.Instance.Modes.Insert(0, new
DefaultDisplayMode("iPhone")
{
    ContextCondition = (context => context.GetOverriddenUserAgent().IndexOf
        ("iPhone", StringComparison.OrdinalIgnoreCase) >= 0)
});

After this code runs, when an Apple iPhone browser makes a request, your application will use the Views\Shared\_Layout.iPhone.cshtml layout (if it exists).

jQuery Mobile, the View Switcher, and Browser Overriding


jQuery Mobile is an open source library for building touch-optimized web UI. If you want to use jQuery Mobile with an ASP.NET MVC 4 application, you can download and install a NuGet package that helps you get started. To install it from the Visual Studio Package Manager Console, type the following command:

Install-Package jQuery.Mobile.MVC -Pre

This installs jQuery Mobile and some helper files, including the following:

  • Views/Shared/_Layout.Mobile.cshtml, which is a jQuery Mobile-based layout.
  • A view-switcher component, which consists of the Views/Shared/_ViewSwitcher.cshtml partial view and the ViewSwitcherController.cs controller.

    After you install the package, run your application using a mobile browser (or equivalent, like the Firefox User Agent Switcher add-on). You'll see that your pages look quite different, because jQuery Mobile handles layout and styling. To take advantage of this, you can do the following:


  • Create mobile-specific view overrides as described under Display Modes earlier (for example, create Views\Home\Index.mobile.cshtml to override Views\Home\Index.cshtml for mobile browsers).
  • Read the jQuery Mobile documentation to learn more about how to add touch-optimized UI elements in mobile views.

    A convention for mobile-optimized web pages is to add a link whose text is something like Desktop view or Full site mode that lets users switch to a desktop version of the page. The jQuery.Mobile.MVC package includes a sample view-switcher component for this purpose. It's used in the default Views\Shared\_Layout.Mobile.cshtml view, and it looks like this when the page is rendered:


    If visitors click the link, they’re switched to the desktop version of the same page.

    Because your desktop layout will not include a view switcher by default, visitors won't have a way to get to mobile mode. To enable this, add the following reference to _ViewSwitcher to your desktop layout, just inside the <body> element:

    <body>
        @Html.Partial("_ViewSwitcher")
        ...

    The view switcher uses a new feature called Browser Overriding. This feature lets your application treat requests as if they were coming from a different browser (user agent) than the one they're actually from. The following table lists the methods that Browser Overriding provides.

    HttpContext.SetOverriddenBrowser(userAgentString)

    Overrides the request's actual user agent value using the specified user agent.

    HttpContext.GetOverriddenUserAgent()

    Returns the request's user agent override value, or the actual user agent string if no override has been specified.

    HttpContext.GetOverriddenBrowser()

    Returns an HttpBrowserCapabilitiesBase instance that corresponds to the user agent currently set for the request (actual or overridden). You can use this value to get properties such as IsMobileDevice.

    HttpContext.ClearOverriddenBrowser()

    Removes any overridden user agent for the current request.

    Browser Overriding is a core feature of ASP.NET MVC 4 and is available even if you don't install the jQuery.Mobile.MVC package. However, it affects only view, layout, and partial-view selection — it does not affect any other ASP.NET feature that depends on the Request.Browser object.

    By default, the user-agent override is stored using a cookie. If you want to store the override elsewhere (for example, in a database), you can replace the default provider (BrowserOverrideStores.Current). Documentation for this provider will be available to accompany a later release of ASP.NET MVC.

    Task Support for Asynchronous Controllers


    You can now write asynchronous action methods as single methods that return an object of type Task or Task<ActionResult>.

    For example, if you're using Visual C# 5 (or using the Async CTP), you can create an asynchronous action method that looks like the following:

    public async Task<ActionResult> Index(string city) {
        var newsService = new NewsService();
        var sportsService = new SportsService();
       
        return View("Common",
            new PortalViewModel {
            NewsHeadlines = await newsService.GetHeadlinesAsync(),
            SportsScores = await sportsService.GetScoresAsync()
        });
    }

    In the previous action method, the calls to newsService.GetHeadlinesAsync and sportsService.GetScoresAsync are called asynchronously and do not block a thread from the thread pool.

    Asynchronous action methods that return Task instances can also support timeouts. To make your action method cancellable, add a parameter of type CancellationToken to the action method signature. The following example shows an asynchronous action method that has a timeout of 2500 milliseconds and that displays a TimedOut view to the client if a timeout occurs.

    [AsyncTimeout(2500)]
    [HandleError(ExceptionType = typeof(TaskCanceledException), View = "TimedOut")]
    public async Task<ActionResult> Index(string city,
        CancellationToken cancellationToken) {
        var newsService = new NewsService();
        var sportsService = new SportsService();
      
        return View("Common",
            new PortalViewModel {
            NewsHeadlines = await newsService.GetHeadlinesAsync(cancellationToken),
            SportsScores = await sportsService.GetScoresAsync(cancellationToken)
        });
    }

    Azure SDK


    ASP.NET MVC 4 Release Candidate supports the 1.6 release of the Windows Azure SDK.

    Database Migrations


    ASP.NET MVC 4 projects now include Entity Framework 5.0 RC. One of the great features in Entity Framework 5.0 is support for database migrations. This feature enables you to easily evolve your database schema using a code-focused migration while preserving the data in the database.

    Empty Project Template


    The MVC Empty project template is now truly empty so that you can start from a completely clean slate. The earlier version of the Empty project template has been renamed to Basic.

    Add Controller to any project folder


    You can now right click and select Add Controller from any folder in your MVC project. This gives you more flexibility to organize your controllers however you want, including keeping your MVC and Web API controllers in separate folders.

    Bundling and Minification


    The bundling and minification framework enables you to reduce the number of HTTP requests that a Web page needs to make by combining individual files into a single, bundled file for scripts and CSS. It can then reduce the overall size of those requests by minifying the contents of the bundle. Minifying can include activities like eliminating whitespace to shortening variable names to even collapsing CSS selectors based on their semantics. Bundles are declared and configured in code and are easily referenced in views via helper methods which can generate either a single link to the bundle or, when debugging, multiple links to the individual contents of the bundle.

    Upgrading an ASP.NET MVC 3 Project to ASP.NET MVC 4


    ASP.NET MVC 4 can be installed side by side with ASP.NET MVC 3 on the same computer, which gives you flexibility in choosing when to upgrade an ASP.NET MVC 3 application to ASP.NET MVC 4.

    The simplest way to upgrade is to create a new ASP.NET MVC 4 project and copy all the views, controllers, code, and content files from the existing MVC 3 project to the new project and then to update the assembly references in the new project to match the old project. If you have made changes to the Web.config file in the MVC 3 project, you must also merge those changes into the Web.config file in the MVC 4 project.

    To manually upgrade an existing ASP.NET MVC 3 application to version 4, do the following:


    1. In all Web.config files in the project (there is one in the root of the project, one in the Views folder, and one in the Views folder for each area in your project), replace every instance of the following text (note: System.Web.WebPages, Version=1.0.0.0 is not found in projects created with Visual Studio 2012):
      System.Web.Mvc, Version=3.0.0.0
      System.Web.WebPages, Version=1.0.0.0
      System.Web.Helpers, Version=1.0.0.0
      System.Web.WebPages.Razor, Version=1.0.0.0

      with the following corresponding text:

      System.Web.Mvc, Version=4.0.0.0
      System.Web.WebPages, Version=2.0.0.0
      System.Web.Helpers, Version=2.0.0.0,
      System.Web.WebPages.Razor, Version=2.0.0.0,

    2. In the root Web.config file, update the webPages:Version element to "2.0.0.0" and add a new PreserveLoginUrl key that has the value "true":
      <appSettings>
        <add key="webpages:Version" value="2.0.0.0" />
        <add key="PreserveLoginUrl" value="true" />
      </appSettings>

    3. In Solution Explorer, right-click on the References and select Manage NuGet Packages. Search for Microsoft.AspNet.Mvc and install the Microsoft ASP.NET MVC 4 (RC) package. Click OK.
    4. In Solution Explorer, right-click the project name and then select Unload Project. Then right-click the name again and select Edit ProjectName.csproj.
    5. Locate the ProjectTypeGuids element and replace {E53F8FEA-EAE0-44A6-8774-FFD645390401} with {E3E379DF-F4C6-4180-9B81-6769533ABE47}.
    6. Save the changes, close the project (.csproj) file you were editing, right-click the project, and then select Reload Project.
    7. If the project references any third-party libraries that are compiled using previous versions of ASP.NET MVC, open the root Web.config file and add the following three bindingRedirect elements under the configuration section:
      <configuration>
        <!--... elements deleted for clarity ...-->
       
        <runtime>
          <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
              <assemblyIdentity name="System.Web.Helpers"
                   publicKeyToken="31bf3856ad364e35" />
              <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
            </dependentAssembly>
            <dependentAssembly>
              <assemblyIdentity name="System.Web.Mvc"
                   publicKeyToken="31bf3856ad364e35" />
              <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="4.0.0.0"/>
            </dependentAssembly>
            <dependentAssembly>
              <assemblyIdentity name="System.Web.WebPages"
                   publicKeyToken="31bf3856ad364e35" />
              <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
            </dependentAssembly>
          </assemblyBinding>
        </runtime>
      </configuration>

    Changes from ASP.NET MVC 4 Beta


    The release notes for ASP.NET MVC 4 Beta can be found here: http://go.microsoft.com/fwlink/?LinkID=238227

    The major changes from ASP.NET MVC 4 Beta in this release are summarized below:


    • Removed ASP.NET Single Page Application: ASP.NET Single Page Application (SPA) shipped with ASP.NET MVC 4 Beta as an early preview of the experience for building applications that include significant client-side interactions using JavaScript. SPA won’t ship with the final MVC 4 release, but will continue to evolve outside of the MVC 4 release. Check out the ASP.NET SPA home page for details.
    • ASP.NET Web API now uses Json.NET for JSON formatting: The default JSON formatter in ASP.NET Web API now uses Json.NET for JSON serialization. Json.NET provides the flexibility and performance required for a modern web framework.
    • Formatter improvements: The methods on MediaTypeFormatter are now public to enable unit testing of custom formatters. A single formatter can now support multiple text encodings. Use BufferedMediaTypeFormatter to implement simple synchronous formatting support. FormatterContext has been removed. To get access to the request from a formatter on the server implement GetPerRequestFormatterInstance.
    • Removed System.Json.dll: Because of the overlap with functionality already in Json.NET the System.Json.dll assembly has been removed.
    • XmlMediaTypeFormatter uses DataContractSerializer by default: The XmlMediaTypeFormatter now uses the DataContractSerializer by default. This means that by default ASP.NET Web API will use the Data Contract programming model for formatting types. You can configure the XmlMediaTypeFormatter to use the XmlSerializer by setting UseXmlSerializer to true.
    • Removed Ajax grid controller template: The Ajax grid controller template was removed to simplify and cleanup the list of available controller templates
    • Formatters now always handle the body content: ASP.NET Web API formatters are now used consistently for handling both the request and response content. We have removed IRequestContentReadPolicy. The FormUrlEncodedMediaTypeFormatter class has been updated to use MVC-style model binding, so you can still use model binding infrastructure for handling form data in the request body.
    • HTTP content negotiation decoupled from ObjectContent: Previously in ASP.NET Web API all HTTP content negotiation logic was encapsulated in ObjectContent, which made it difficult to predict when HTTP content negotiation would occur. We have decoupled HTTP content negotiation from ObjectContent and encapsulated it as an IContentNegotiator implementation. ObjectContent now takes a single formatter. You can run HTTP content negotiation whenever you want using the DefaultContentNegotiator implementation to select an appropriate formatter. IFormatterSelector has been removed
    • Removed HttpRequestMessage<T> and HttpResponseMessage<T>: Previously there were two ways to specify a request or response with an ObjectContent instance: you could provide an ObjectContent instance directly, or you could use HttpRequestMessage<T> or HttpResponseMessage<T>. Having two ways of doing the same thing complicated request and response handling, so HttpRequestMessage<T> and HttpResponseMessage<T> have been removed. To create content negotiated responses that contain an ObjectContent use the CreateResponse<T> extension methods on the request message. To send a request that contains an ObjectContent use the PostAsync<T> extension methods on HttpClient. Or, use the PostAsJsonAsync<T> and PostAsXmlAsync<T> extension methods to specify a request that will be specifically formatted with as JSON or XML respectively.
    • Simplified action parameter binding: You can now predictably determine whether an action parameter will be bound to the request body. This ensures that the request stream is not unnecessarily consumed. Parameters with simple types by default come from the URL. Parameters with complex types by default come from the body. There can be only one body parameter. You can explicitly specify if a parameter comes from the URL or from the body using the [FromUri] and [FromBody] attributes.
    • Query composition is now implemented as a reusable filter: Previously support for query composition was hard coded into the runtime. Query composition is now implemented as a reusable filter that can be applied as an attribute ([Queryable]) to any action that returns an IQueryable instance. This attribute is now required to enable query composition.
    • Cookies: The HttpRequestMessage and HttpResponseMessage classes expose the HTTP Cookie and Set-Cookie headers as raw strings and not structured classes. This made it cumbersome and error prone to work with cookies in ASP.NET Web API. To fix this we introduced two new CookieHeaderValue and CookieState that follow RFC 6265 HTTP State Management Mechanism. You can use the AddCookies extension method to add a Set-Cookie header to a response message. Use the GetCookies extension method to get all of the CookieHeaderValues from a request.
    • HttpMessageInvoker: The HttpMessageInvoker provides a light weight mechanism to invoke an HttpMessageHandler without the overhead of using HttpClient. Use HttpMessageInvoker for unit testing message handlers and also for invoking message handlers on the server.
    • Response buffering improvements: When web-hosting a web API the response content length is now set intelligently so that responses are not always chunked. Buffering also enables reasonable error messages to be returned when exceptions occur in formatters.
    • Independently control IHttpController selection and activation: Implement the IHttpControllerSelector to control IHttpController selection. Implement IHttpControllerActivator to control IHttpController activation. The IHttpControllerFactory abstraction has been removed.
    • Clearer integration with IoC containers that support scopes: The dependency resolver for ASP.NET Web API now supports creating dependency scopes that can be independently disposed. A dependency scope is created for each request and is used for controller activation. Configuring dependency resolution (i.e. HttpConfiguration.DependencyResolver) is optional and is now configured separately from the default services used by ASP.NET Web API (HttpConfiguration.Services). However, the service locator consults the dependency resolver first for required services and then falls back to explicitly configured services.
    • Improved link generation: The ASP.NET Web API UrlHelper how has convenience methods for generating links based on the configured routes and the request URI.
    • Register resource for disposal at the end of the request life-time: Use the RegisterForDispose extension method on the request to register an IDisposable instance that should be disposed when the request is disposed.
    • Monitoring and diagnostics: You can enable tracing by providing an ITraceWriter implementation and configuring it as a service using the dependency resolver. The ILogger interface has been removed.
    • Create custom help and test pages: You now can easily build custom help and test pages for your web APIs by using the new IApiExplorer service to get a complete runtime description of your web APIs.
    • Entity Framework based scaffolding for web APIs: Use the Add Controller dialog to quickly scaffold a web API controller based on an Entity Framework based model type.
    • Create unit test projects for Web API projects: You can now easily create a unit test project for a Web API project using the New ASP.NET MVC 4 Project dialog box.
    • Unauthorized requests handled by ASP.NET Web API return 401 Unauthroized: Unauthorized requests handled by ASP.NET Web API now return a standard 401 Unauthorized response instead of redirecting the user agent to a login form so that the response can be handled by an Ajax client.
    • Configuration logic for MVC applications moved under the App_Start directory: The configuration logic For MVC applications has been moved from Global.asax.cs to a set of static classes in the App_Start directory. Routes are registered in RouteConfig.cs. Global MVC filters are registered in FilterConfig.cs. Bundling and minification configuration now lives in BundleConfig.cs.
    • Support different debug and release modes for bundling and minification: Use the Styles.Render and Scripts.Render helpers from within a Razor view so that resources will not be bundled while developing and debugging, but will be bundled and minified when the application is deployed into production.
    • Explicit configuration of default bundles: All of the default bundles are now explicitly configured in BundleConfig.cs to provide greater visibility into what bundles are available and to enable more flexibility in modifying the configuration. Separate bundles are configured for different components (jQuery, jQuery UI, etc.) to enable finer grained control over which bundles are included on a page.
    • Simplified bundle configuration: Strongly typed bundle classes (ex. StyleBundler, ScriptsBundle) automatically wire up the appropriate default bundle transform class (i.e. minifier). Use method chaining to avoid the three-step process of creating, configuring and adding to a bundle. Streamline configuration code by including multiple values for bundle files and bundle transforms via a params array.
    • Entity Framework 5.0 RC: ASP.NET MVC 4 projects now include Entity Framework 5.0 RC.
    • Empty Project Template: The MVC Empty project template is now truly empty so that you can start from a completely clean slate. The earlier version of the Empty project template has been renamed to Basic.
    • Add Controller to any project folder: You can now right click and select Add Controller from any folder in your MVC project. This gives you more flexibility to organize your controllers however you want, including keeping your MVC and Web API controllers in separate folders.
    • Invoke and test HttpMessageHandlers using the new HttpMessageInvoker: HttpMessageInvokerprovides a simple and light-weight way to invoke and test any HttpMessageHandler including HttpServer instances. The public SubmitRequestAsync method on HttpServer has been removed and HttpMessageInvoker should be used instead.

    Known Issues and Breaking Changes



    • Breaking changes in the Razor View Engine. As part of a rewrite of the Razor parser, the following types were removed from System.Web.Mvc.Razor:

      • ModelSpan
      • MvcVBRazorCodeGenerator
      • MvcCSharpRazorCodeGenerator
      • MvcVBRazorCodeParser
      The following methods were also removed:

      • MvcCSharpRazorCodeParser.ParseInheritsStatement(System.Web.Razor.Parser.CodeBlockInfo)
      • MvcWebPageRazorHost.DecorateCodeGenerator(System.Web.Razor.Generator.RazorCodeGenerator)
      • MvcVBRazorCodeParser.ParseInheritsStatement(System.Web.Razor.Parser.CodeBlockInfo)

    • When WebMatrix.WebData.dll is included in in the /bin directory of an ASP.NET MVC 4 apps, it takes over the URL for forms authentication. Adding the WebMatrix.WebData.dll assembly to your application (for example, by selecting "ASP.NET Web Pages with Razor Syntax" when using the Add Deployable Dependencies dialog) will override the authentication login redirect to /account/logon rather than /account/login as expected by the default ASP.NET MVC Account Controller. To prevent this behavior and use the URL specified already in the authentication section of web.config, you can add an appSetting called PreserveLoginUrl and set it to true:
      <appSettings>
          <add key="PreserveLoginUrl" value="true"/>
      </appSettings>

    • The NuGet package manager fails to install when attempting to install ASP.NET MVC 4 for side by side installations of Visual Studio 2010 and Visual Web Developer 2010. To run Visual Studio 2010 and Visual Web Developer 2010 side by side with ASP.NET MVC 4 you must install ASP.NET MVC 4 after both versions of Visual Studio have already been installed.
    • Uninstalling ASP.NET MVC 4 fails if prerequisites have already been uninstalled. To cleanly uninstall ASP.NET MVC 4 you must uninstall ASP.NET MVC 4 prior to uninstalling Visual Studio.
    • Installing ASP.NET MVC 4 Release Candidate breaks ASP.NET MVC 3 RTM applications. ASP.NET MVC 3 applications that were created with the RTM release (not with the ASP.NET MVC 3 Tools Update release) require the following changes in order to work side-by-side with ASP.NET MVC 4 Release Candidate. Building the project without making these updates results in compilation errors.

      Required updates


      1. In the root Web.config file, add a new <appSettings> entry with the key webPages:Version and the value 1.0.0.0.
        <appSettings>
            <add key="webpages:Version" value="1.0.0.0"/>
            <add key="ClientValidationEnabled" value="true"/>
            <add key="UnobtrusiveJavaScriptEnabled" value="true"/>
        </appSettings>

      2. In Solution Explorer, right-click the project name and then select Unload Project. Then right-click the name again and select Edit ProjectName.csproj.
      3. Locate the following assembly references:
        <Reference Include="System.Web.WebPages"/> 
        <Reference Include="System.Web.Helpers" />

        Replace them with the following:

        <Reference Include="System.Web.WebPages, Version=1.0.0.0,
        Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL "/>
        <Reference Include="System.Web.Helpers, Version=1.0.0.0,
        Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

      4. Save the changes, close the project (.csproj) file you were editing, and then right-click the project and select Reload.

    • Changing an ASP.NET MVC 4 project to target 4.0 from 4.5 does not update the EntityFramework assembly reference: If you change an ASP.NET MVC 4 project to target 4.0 after targetting 4.5 the reference to the EntityFramwork assembly will still point to the 4.5 version. To fix this issue reinstall the EntityFramework NuGet package.
    • 403 Forbidden when running an ASP.NET MVC 4 application on Azure after changing to target 4.0 from 4.5: If you change an ASP.NET MVC 4 project to target 4.0 after targetting 4.5 and then deploy to Azure you may see a 403 Forbidden error at runtime. To workaround this issue add the following to your web.config: <modules runAllManagedModulesForAllRequests="true" />
    • Visual Studio crashes when editing a .cshtml file after renaming the file. Visual Studio may crash if you rename a .cshtml file while the file is open in the editor. To work around this issue, close and reopen the .cshtml file after renaming it.
  • No comments:

    Post a Comment

    Note: only a member of this blog may post a comment.