Labels

Wednesday, August 27, 2014

ASP.NET vNext

The next version of ASP.NET (“ASP.NET vNext”) has been redesigned from the ground up.

The goal is to create a lean and composable .NET stack for building modern cloud-based apps.

 

You don't have to use Visual Studio to develop ASP.NET vNext applications.

You can develop and run vNext on platforms that Visual Studio doesn't run on.

 

Few New Releases:

 

1.       .NET Compiler Platform ("Roslyn")

2.      .NET Next Generation JIT (“RyuJIT”).

  1. Visual Studio Online ("Monaco").

 

 

Introduction to ASP.NET vNext

 

Here are some of the new features in ASP.NET vNext.

ASP.NET vNext includes updated versions of MVC, Web API, Web Pages, SignalR and EF - ASP.NET vNext (MVC, Web API and Web Pages 6; EF 7; SignalR 3)

 

Intro:

 

  • ASP.NET vNext includes updated versions of MVC, Web API, Web Pages, SignalR and EF.

The key improvement with these frameworks is that MVC, Web API and Web Pages have been merged into a single programming model. For example, there’s now unified controller and routing concepts between all three. You can now have a single controller that returns both MVC views and formatted Web API responses, on the same HTTP verb.

 

  • ASP.NET vNext apps are cloud ready by design. Services such as session state and caching adjust their behavior depending on whether the app is running in the cloud or in a traditional hosting environment, while providing a consistent API.

 

  • We use dependency injection behind the scenes to provide your app with the correct implementation for these services.

Using this approach, it is really easy to move your app from on-premises to the cloud, since our code changes, not yours.

 

  • You will be able to make changes to your web applications and see the results after a browser refresh, with no separate build step needed. This significant productivity enhancement is based on improvements to load times in the underlying CLR, as well as use of the new .NET Compiler Platform ("Roslyn").

 

 

Rebuilt from the Ground Up

 

  • MVC, Web API, and Web Pages are merged into one framework, called MVC 6. The new framework uses a common set of abstractions for routing, action selection, filters, model binding, and so on.

I.e. There’s now unified controller and routing concepts between all three. You can now have a single controller that returns both MVC views and formatted Web API responses, on the same HTTP verb.

 

  • Dependency injection is built into the framework. Use your preferred IoC container to register dependencies.
  • vNext is host agnostic. You can host your app in IIS, or self-host in a custom process. (Web API 2 and SignalR 2 already support self-hosting; vNext brings this same capability to MVC.)
  • vNext is open source and cross platform.

 

Leaner, Faster

 

  • MVC 6 has no dependency on System.Web.dll. The result is a leaner framework, with faster startup time and lower memory consumption.
  • vNext apps can use a cloud-optimized runtime and subset of the .NET Framework. This subset of the framework is about 11 megabytes in size compared to 200 megabytes for the full framework, and is composed of a collection of NuGet packages.
  • Because the cloud-optimized framework is a collection of NuGet packages, your app can include only the packages you actually need. No unnecessary memory, disk space, loading time, etc.
  • Microsoft can deliver updates to the framework on a faster cadence, because each part can be updated independently.

 

True Side-by-Side Deployment

 

The reduced footprint of the cloud-optimized runtime makes it practical to deploy the framework with your app.

 

  • You can run apps side-by-side with different versions of the framework on the same server.
  • Your apps are insulated from framework changes on the server.
  • You can make framework updates for each app on its own schedule.
  • No errors when you deploy to production resulting from a mismatch between the framework patch level on the development machine and the production server.

 

New Development Experience

 

vNext uses the Roslyn compiler to compile code dynamically.

 

  • You can edit a code file, refresh the browser, and see the changes without rebuilding the project.
  • Besides streamlining the development process, dynamic code compilation enables development scenarios that were not possible before, such as editing code on the server using Visual Studio Online ("Monaco").
  • You can choose your own editors and tools.

 

 

ASP.NET vNext is being rewritten from the ground up, and while much of your code for vNext will look the same.

vNext is not backwards compatible with existing ASP.NET applications.

However, the current frameworks (Web Forms 5, MVC 5, Web API 2, Web Pages 3, SignalR 2, and Entity Framework 6) will continue to ship in Visual Studio, and will be fully supported in ASP.NET vNext.

 

Summary:

 

The table below outlines the ASP.NET vNext scenarios we’ve built and where they are available.

 

ASP.NET vNext Feature

On .NET vNext

On .NET vNext (Cloud Optimized)

Cloud Ready

*

*

Modular Design

*

*

Dependency Injection

*

*

Consistent Tracing / Debugging

*

*

Faster Development (browser refresh)

*

*

Open Source

*

*

Full Side by Side (runtime and framework
deployed with application)

 

*

Faster startup, Lower memory / Higher throughput (best of class)

 

*

Uses a smaller set of framework libraries

 

*

Enabled on Mono, on Mac and Linux

 

*

 

ASP.NET vNext will be open source and will be contributed to the .NET Foundation. This shouldn’t come as a big surprise since the ASP.NET Web stack is already open source. All of ASP.NET vNext will be delivered via NuGet, will be open source and will take contributions. Read ASP.NET vNext: the future of .NET on the Server to learn more.

Our announcement at TechEd is the first stop for .NET vNext and ASP.NET vNext. We’ll share much more in the months to come before we release the final versions. We’re looking forward to shipping pre-release versions in order to get your feedback.

 

 

Code View:

 

project.json

 

The project.json file contains a list of dependencies for the project and a list of build output configurations.

It can also include a list of commands.

The project.json file also specifies build output framework configuration options.

 

{

    "dependencies": {

        "Microsoft.AspNet.Server.IIS" : "1.0.0-alpha3",

                                "Microsoft.AspNet.Mvc": "6.0.0-alpha3",

                                "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-alpha3",

        "Microsoft.AspNet.Identity.Authentication": "3.0.0-alpha3",

        "Microsoft.AspNet.Security.Cookies": "1.0.0-alpha3",

        "Microsoft.AspNet.Server.IIS": "1.0.0-alpha3",

        "Microsoft.AspNet.Server.WebListener": "1.0.0-alpha3",

        "Microsoft.AspNet.StaticFiles": "1.0.0-alpha3",

        "Microsoft.Framework.ConfigurationModel.Json": "1.0.0-alpha3",

        "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0-alpha2",

        "Classlibrary1": ""

    }

 

   "frameworks": {

        "net45": { },

        "k10": { }

    }

}

 

 

Commands

 

The project.json file can also contain commands that facilitate running the application from the command line.

For example:

 

{

    "commands": {       

        "web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5000"

    }

}

 

Startup.cs

 

By default, the vNext hosting environment expects to find a startup class named Startup.

This class must contain a Configure method that takes an IBuilder parameter, and you configure the HTTP pipeline inside this Configure method. The empty project creates the class with nothing in the Configure method.

 

using System;

using Microsoft.AspNet.Builder;

using Microsoft.Framework.DependencyInjection;

 

namespace HelloWorld

{

    public class Startup

    {

        public void Configure(IBuilder app)

        {

           app.UseServices(services =>

            {

                services.AddMvc();

            });

 

            app.UseMvc();

        }

    }

}

 

Here - AddMvc method adds the MVC framework services to the dependency injection system.

The UseMvc method configures MVC default settings such as routes.

 

Config.json - vNext configuration

 

The template creates a config.json file to store application settings such as database connection strings:

 

{

    "Data": {

        "DefaultConnection": {

            "ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=aspnetvnext-HelloWorld2-f0652fd2-febf-488d-955b-b4c590e536f1;Trusted_Connection=True;MultipleActiveResultSets=true"

        }

    }

}

 

 

References:

 

http://www.asp.net/vnext/overview/aspnet-vnext/getting-started-with-aspnet-vnext-and-visual-studio

http://blogs.msdn.com/b/dotnet/archive/2014/05/12/the-next-generation-of-net-asp-net-vnext.aspx

http://blogs.msdn.com/b/webdev/archive/2014/08/12/develop-asp-net-vnext-applications-on-a-mac.aspx

 

 

 

Hope this helps.

 

Regards,

Arun Manglick

Monday, August 25, 2014

C# Version

C# Version

 Feature List

NA

 

NA

 

NA

 

1.0

Managed Code

1.0

 

2.0

§ Partial Classes
§ Static Classes
§ Generic Classes
§ Anonymous methods
§ Iterators
§ Nullable Types

3.0

§ Automatic Properties
§ Object Initializers
§ Collection Initializers
§ Extension Methods
§ Lambda Expressions -  p => expressions
§ Query Syntax
§ Anonymous Types
§ Var Keyword

4.0

• Named and Optional Arguments
• Dynamic Binding
• CoVariance & ContraVariance
• COM specific interop features
• Indexed Properties

5.0

1. Async Feature
2. Caller Information

 

 

Thanks & Regards,

Arun Manglick,

Project Manager - Forecasting
Mobile
: 9158041782| 9850901262| Desk Phone: +912040265348 | http://www.synechron.com

SYNECHRON -
- 4,000+ professionals globally.
- USA | Canada | UK | The Netherlands | UAE | India | Singapore | Hong Kong | Japan

 

EF Versions Mapping

Product name

Supported .NET
Versions

VS Version

Details

EF (or EF 3.5)

3.5

2008 SP1

Basic O/RM support using the Database First workflow.

EF 4.0

4.0

2010

New features in this release included:
• POCO Support,
• Lazy loading,
• Testability improvements,
• Customizable code generation and the
• Model first workflow

EF 4.1

4.0

2010

• Published on NuGet.
• Simplified DbContext API and the
• Code First Workflow.

EF 4.3

4.0

2010

• New Code First Migrations feature: Allowing a database created by Code First to be incrementally changed as your Code First model evolves.

EF 5

4.0, 4.5

2010,
2012

Ttargeting .NET 4.5 Features:
--------------------------------------
• Enum support,
• Table-Valued Functions,
• Spatial Data Types and
• Various Performance Improvements.
• Entity Framework Designer in Visual Studio 2012 also introduces
   o Support for multiple-diagrams per model,
   o Coloring of shapes on the design surface and
   o Batch import of stored procedures.

EF 6

4.0, 4.5

2010,
2012,
2013

Tooling
To add support for the EF6 runtime and to enable shipping out-of-band between releases of Visual Studio.
The tooling itself does not include any new features, but most of the new runtime features can be used with models created in the EF Designer.

Runtime
.
The following features work for models created with Code First or the EF Designer:

• Async Query and Save
• Connection Resiliency
• Code-Based Configuration.
• Dependency Resolution.
• Interception/SQL logging.
• Testability improvements.
• DbContext can now be created with a DbConnection that is already opened.
• Improved Transaction Support.
• Enums, Spatial and Better Performance on .NET 4.0 -.
• Improved performance of Enumerable.Contains in LINQ queries.
• Improved warm up time (view generation)
• Pluggable Pluralization & Singularization Service.
• Custom implementations of Equals or GetHashCode.
• DbSet.AddRange/RemoveRange
• DbChangeTracker.HasChanges.
• SqlCeFunctions.

The following features apply to Code First only:
• Custom Code First Conventions.
• Code First Mapping to Insert/Update/Delete Stored Procedures
• Idempotent migrations scripts.
• Configurable Migrations History Table.
• Multiple Contexts per Database
• DbModelBuilder.HasDefaultSchema
• DbModelBuilder.Configurations.AddFromAssembly method
• Custom Migrations Operations.
• Default transaction isolation level is changed to READ_COMMITTED_SNAPSHOT .
• Entity and complex types can now be nestedinside classes.

 

 

Thanks & Regards,

Arun Manglick,

Project Manager - Forecasting
Mobile
: 9158041782| 9850901262| Desk Phone: +912040265348 | http://www.synechron.com

SYNECHRON -
- 4,000+ professionals globally.
- USA | Canada | UK | The Netherlands | UAE | India | Singapore | Hong Kong | Japan

 

.Net Versions Mapping

Product name

Release date

Codename

Internal
Version

Supported .NET
Framework Versions

C# Version

ASP.NET Version

Visual Studio

1-Apr-95

N/A

4

N/A

NA

NA

Visual Studio 97

1-Feb-97

Boston

5

N/A

NA

NA

Visual Studio 6.0

1-Jun-98

Aspen

6

N/A

NA

NA

Visual Studio .NET (2002)

13-Feb-02

Rainier

7

1

1.0

1.0

Visual Studio .NET 2003

24-Apr-03

Everett

7.1

1.1

1.0

1.1

Visual Studio 2005

7-Nov-05

Whidbey

8

2.0, 3.0

2.0

2.0

Visual Studio 2008

19-Nov-07

Orcas

9

2.0, 3.0, 3.5

3.0

3.0, 3.5

Visual Studio 2010

12-Apr-10

Dev10/Rosario

10

2.0, 3.0, 3.5, 4.0

4.0

4.0

Visual Studio 2012

12-Sep-12

Dev11

11

2.0, 3.0, 3.5, 4.0, 4.5

5.0

4.5

Visual Studio 2013

17-Oct-13

Dev12

12

2.0, 3.0, 3.5, 4.0, 4.5, 4.5.1

5.0

4.5.1

 

 

Hope this helps.

 

Regards,

Arun

 

Wednesday, August 6, 2014

What, Why REST?

Hi,

 

·         Why REST?

·         What is REST?

·         WCF and REST

 

Why REST?

 

Two reasons – One is soft and the other is hard( likely imposed).

 

1.       First, REST offers some significant features and benefits over RPC technologies in many cases.

2.    Second, Microsoft is moving many of its own implementations away from RPC technologies (such as SOAP) and goings toward REST. This means that even if you are not convinced or motivated to use REST to build your own systems, you'll need to know how to interact with other MS Frameworks & Technologies as they have already moved to REST,

 

What is REST?

 

REST is an architectural style - Used to build software in which clients (User Agents) can make requests of services (Endpoints).

REST means that each unique URL is a representation of some object (Resource).

 

URL

Verbs

Resource/Object

Other Verbs

"/ "

GET

Retun All Years Subscriptions

 

“/{year}"

GET

A particular year's issues

PUT

"/{year}/{issue}"

GET

A particular issue

PUT

"/{year}/{issue}/{article}"

GET

An article

PUT,POST,DELETE

 

E.g. http://localhost/Issues.svc/  and http://localhost/Issues.svc/2007

 

 

 

To add an article to December 2008, the client would POST an article resource to http://localhost/Issues.svc/2008/December and a new article would be added to that issue.

 

To suuport this -  WCF ServiceContract Definition would look like below.

 

 

[ServiceContract]

public interface IMSDNMagazineService

{

    [OperationContract]

    [WebGet(UriTemplate="/")]

    IssuesCollection GetAllIssues();

 

    [OperationContract]

    [WebGet(UriTemplate = "/{year}")]

    IssuesData GetIssuesByYear(string year);

 

    [OperationContract]

    [WebGet(UriTemplate = "/{year}/{issue}")]

    Articles GetIssue(string year, string issue);

 

    [OperationContract]

    [WebGet(UriTemplate = "/{year}/{issue}/{article}")]

    Article GetArticle(string year, string issue, string article);

 

    [OperationContract]

    [WebInvoke(UriTemplate = "/{year}/{issue}",Method="POST")]

    Article AddArticle(string year, string issue, Article article);

}

 

 

WCF & REST

 

WCF is more geared toward RPC (using SOAP). Till Framework 3.0 WCF had the ability to expose and consume REST services as part of the .NET. However what it lacked was a programming model needed to make using REST with WCF easy.

 

This is been mitigated in Framework 3.5 - Both a Programming Model and those pieces of Infrastructure were added to existing System.ServiceModel.Web assembly.

 

The Programming Model additons were –

 

o    WebGetAttribute and WebInvokeAttribute, and

o    URI Template Mechanism - Enables to declare the URI and Verb to which each method. (As show above).

 

The Infrastructure additons were –

 

o    Behavior Infrastructure

o    Binding (WebHttpBinding) and

o    Behavior (WebHttp­Behavior) - Provide the correct networking stack for using REST

 

o    Hosting Infrastructure additons were –

o    Custom Service­Host (WebServiceHost) and

o    ServiceHostFactory (WebServiceHostFactory)

 

WebGetAttribute and WebInvokeAttribute

 

WCF builds connected systems, is by routing messages to methods, defined in your service class.

 

In Non-REST WCF:

 

o    By default, WCF does the routing (also known as Dispatching) based on the concept of action.

o    This system of routing is tightly coupled to SOAP since the SOAP specification's Action header is used by default.

o    The value of Action is based on (method name + the namespace of your service) Or via a custom value (set via the OperationContractAttribute.Action property).

o    For this dispatching to work, an action needs to be present in every message that WCF receives on your behalf.

o    Each unique action is mapped to a particular Action method.

 

In RESTful WCF:

 

o    In this case, the default dispatcher is replaced by one that routes based not on Action, but instead based on the (URI  + HTTP verb being used) in the  request.

o    This routing (done by a class called WebHttpDispatchOperationSelector) enables you to easily implement a RESTful endpoint.

o    This dispatcher is configured on each endpoint by a behavior named WebHttpBehavior, which must be added to each endpoint. (TBD)

o    The key to making this work is for the WebHttpDispatch­OperationSelector to know How To Map Different Uris And Verbs To Your Methods.

o    For this, the WebGetAttribute and WebInvokeAttribute must be added to the methods on your WCF ServiceContract type.

 

WebGetAttribute tells the dispatcher that the method should respond to HTTP GET requests.

WebInvokeAttribute is mapped to HTTP POST by defaul.

Also the WebInvokeAttribute.Method property can be set to support any of the other HTTP verbs (PUT and DELETE being the two most common).

 

UriTemplate and UriTemplateTable

 

In Non-RESt, By default, the URI is determined by the name of the method (added onto the base URI of the endpoint).

In RESTful, what you want to expose as URIs are nouns.

For this reason, WCF + REST,  requires customization of URIs for each method  - This is achvieved by using templates.

Such Templates are set via the UriTemplate property on WebGetAttribute or WebInvokeAttribute.

 

UriTemplate - Enables customization of the URI for each Method And Verb combination, by using a special template syntax (as shown above).

 

WebHttpBinding and WebHttpBehavior

 

WebHttpBinding – Used for a RESTful endpoint. Unlike others this is fairly simple.

It contains only two components: the HTTP transport and the Text Message Encoder (set to not expect or use SOAP, just plain XML).

 

WebHttpBehavior - Is the object that causes the “URI + HTTP Verb” dispatcher to be used.

 

Note: Below Code for self-hosting a WCF RESTful endpoint.

 

·         WebHttpBinding and the WebHttpBehavior are almost always used together

·         You have to specify the WebHttpBinding when adding the endpoint to the ServiceHost.

·         Also you have to explicitly add the WebHttpBehavior to the endpoint to make the URI-plus-verb dispatching system work.

 

 

ServiceHost sh =  new ServiceHost(typeof(MSDNMagazineServiceType));

string baseUri = "http://localhost/MagazineService";

ServiceEndpoint se =   sh.AddServiceEndpoint(typeof(IMSDNMagazineService), new WebHttpBinding(), baseUri);

se.Behaviors.Add(new WebHttpBehavior());

sh.Open();

 

 

 

<configuration>

  <system.serviceModel>

    <services>

      <service name="MSDNMagazine.MSDNMagazineServiceType">

        <endpoint

          address="http://localhost/MagazineService"

          binding="webHttpBinding"

          contract="MSDNMagazine.IMSDNMagazineService"

          behaviorConfiguration="webby"/>

      </service>

    </services>

    <behaviors>

      <endpointBehaviors>

        <behavior name="webby">

          <webHttp/>

        </behavior>

      </endpointBehaviors>

    </behaviors>

  </system.serviceModel>

</configuration>

 

Note: Use either code or config.

 

 

 

WebServiceHost and WebServiceHostFactory

 

WCF is complex, in terms of configuration. To alleviate this concern with RESTful endpoints,, Microsoft added two new types to the .NET Framework 3.5

 

·         WebServiceHost and

·         WebServiceHostFactory

 

WebServiceHost:

 

·         Is a ServiceHost-derived type, which simplifies self-hosting scenarios of RESTful endpoints.

·         The code to self-host with WebServiceHost looks like this

 

 

string baseUri = "http://localhost/MagazineService";

WebServiceHost sh =   new WebServiceHost(typeof(MSDNMagazineServiceType), new Uri(baseUri));

sh.Open();

 

 

WebServiceHostFactory:

In the managed hosting scenario with WCF, inside IIS, WCF normally requires an .svc file that points to the service type, plus entries in the web.config file to inform WCF about the endpoint (the binding and behaviors among other configuration). To simplify the managed hosting scenario, Microsoft added WebServiceHostFactory.

 

·         Uses an open WCF extensibility point (using a custom ServiceHostFactory type) in the managed hosting scenario.

·         This enables a configuration-free experience for many RESTful services. The .svc file looks like this

 

 

<%@ ServiceHost

                        Factory="System.ServiceModel.Activation.WebServiceHostFactory"  

                        Service="MSDNMagazine.MSDNMagazineServiceType" %>

 

 

 

·         WebServiceHostFactory creates an instance of the WebServiceHost, and since the WebServiceHost will auto-configure the endpoint using WebHttpBinding and WebHttpBehavior. This no need for any configuration for this endpoint in the web.config at all.

 

 

Why Should You Care about REST?

 

Whether you have used proprietary either of the below two, these are the implementations of the client-server style we've had on the Microsoft platform.

·         RPC systems such as DCOM or .NET Remoting, or

·         Interoperable RPC technologies such as SOAP using ASMX(Web Service) or WCF,

 

So why learn or use REST?

 

·         The two main reason are as mentioned above.

 

The following is a list of other advantages (but don't consider this list exhaustive):

 

 

 

Caching

When RESTful endpoints are asked for data using HTTP, the HTTP verb used is GET.

Resources returned in response to a GET request can be cached in many different ways.

 

Conditional GET, which is a way that a client can check with the service if his version of the data is still the current version, is an optional implementation detail a RESTful endpoint can implement that can further improve speed and scalability.

 

Scale-Out

REST encourages each resource to contain all of the states necessary to process a particular request.

RESTful services are much easier to scale out when they fulfill this constraint and can be stateless.

 

Interoperability

Many people advertize SOAP as being the most interoperable way to implement client-server programs.

But some languages and environments still don't have SOAP toolkits.

And some that do have toolkits are based on older standards that can't always communicate with toolkits that implement newer standards.

 

REST only requires an HTTP library to be available for most operations, and it is Certainly More Interoperable Than Any RPC Technology (including SOAP).

 

Simplicity

Here, the simplicity of using REST relates to URIs representing resources and the uniform interface.

 

Using the uniform interface simplifies development by freeing me from having to build an interface, contract, or API for each service I need to build. The interface (how clients will interact with my service) is set by the constraints of the architecture.

 

Lightweight

REST is Lightweight than SOAP because it does not requires lot of xml markup like SOAP.

 

 

This is not an exhaustive list nor should you take it as conclusive evidence that REST is the one and only true technology to use always.

You should be aware of the advantages so you can leverage them when appropriate

 

REST Vs SOAP - Which is the best approach?

 

Software Architects have been involving a never-ending debate about whether SOAP-based or REST-style web services are the right approach.

Yahoo's web services are using REST and Google using SOAP for their web services. Some organizations have web services for both REST and SOAP.

 

REST is Lightweight than SOAP because it does not requires lot of xml markup like SOAP.

I believe that SOAP will be the primary choice for Intranet & Enterprise Level Applications because SOAP and the WS-* specifications addresses many challenges of enterprise level applications such as Reliability, Distributed Transactions, and other WS-* services.

On the other hand, Internet applications will gear towards to REST because of REST’s explicitly Web-based approach and its simplicity.

 

 

RESTful services for WCF 3.5

 

WCF 3.5 provides explicit support for RESTful communication using a new binding named WebHttpBinding.

By adding the WebGet Attribute, we can define a service as REST based service that can be accessible using HTTP GET operation.


The below code shows how to expose a RESTful service

SOAP Based – WCF 3.0

REST Based – WCF 3.5

 

[ServiceContract]
interface IStock
{
[OperationContract]
int GetStock(string StockId);
}

[ServiceContract]
interface IStock
{
[OperationContract]
[WebGet]
int GetStock(string StockId);
}

 

Regards,

Arun Manglick