Search results for 'app:weblogs' matching tag 'asp.net'

Enum types, FlagsAttribute & Zero value – Part 2

NunoGomes — Fri, 06 Jul 2012 05:00:00 GMT

In my previous post I wrote about why you should pay attention when using enum value Zero.

After reading that post you are probably thinking like Benjamin Roux: Why don’t you start the enum values at 0x1?

Well I could, but doing that I lose the ability to have Sync and Async mutually exclusive by design. Take a look at the following enum types:

[Flags]
public enum OperationMode1
{
    Async = 0x1,
    Sync = 0x2,
    Parent = 0x4
}

[Flags]
public enum OperationMode2
{
    Async = 0x0,
    Sync = 0x1,
    Parent = 0x2
}

To achieve mutually exclusion between Sync and Async values using OperationMode1 you would have to operate both values:

protected void CheckMainOperarionMode(OperationMode1 mode)
{
    switch (mode)
    {
        case (OperationMode1.Async | OperationMode1.Sync | OperationMode1.Parent):
        case (OperationMode1.Async | OperationMode1.Sync):
            throw new InvalidOperationException("Cannot be Sync and Async simultaneous");
            break;
        case (OperationMode1.Async | OperationMode1.Parent):
        case (OperationMode1.Async):
            break;
        case (OperationMode1.Sync | OperationMode1.Parent):
        case (OperationMode1.Sync):
            break;
        default:
            throw new InvalidOperationException("No default mode specified");
    }
}

but this is a by design constraint in OperationMode2. Why? Simply because 0x0 is the neutral element for the bitwise OR operation.

Knowing this singularity, replacing and simplifying the previous method, you get:

protected void CheckMainOperarionMode(OperationMode2 mode)
{
    switch (mode)
    {
        case (OperationMode2.Sync | OperationMode2.Parent):
        case (OperationMode2.Sync):
            break;
        case (OperationMode2.Parent):
        default:
            break;
    }

This means that:

if both Sync and Async values are specified Sync value always win (Zero is the neutral element for bitwise OR operation)
if no Sync value specified, the Async method is used.

Here is the final method implementation:

protected void CheckMainOperarionMode(OperationMode2 mode)
{
    if (mode & OperationMode2.Sync == OperationMode2.Sync)
    {
    } else { 
    }
}

All wrote above prove that Async value (0x0) is useless from the arithmetic perspective, but, without it we lose readability.

The following IF statements are logically equals but the first is definitely more readable:

if (OperationMode2.Async | OperationMode2.Parent)
{
}

if (OperationMode2.Parent)
{ 
}

Here’s another example where you can see the benefits of 0x0 value, the default value can be used explicitly.

    <my:Control runat="server" Mode="Async,Parent">

    <my:Control runat="server" Mode="Parent">

Enum types, FlagsAttribute & Zero value

NunoGomes — Thu, 05 Jul 2012 05:00:00 GMT

We all know about Enums types and use them every single day. What is not that often used is to decorate the Enum type with the FlagsAttribute.

When an Enum type has the FlagsAttribute we can assign multiple values to it and thus combine multiple information into a single enum.

The enum values should be a power of two so that a bit set is achieved.

Here is a typical Enum type:

public enum OperationMode
{
    /// <summary>
    /// No operation mode
    /// </summary>
    None = 0,
    /// <summary>
    /// Standard operation mode
    /// </summary>
    Standard = 1,
    /// <summary>
    /// Accept bubble requests mode
    /// </summary>
    Parent = 2
}

In such scenario no values combination are possible. In the following scenario a default operation mode exists and combination is used:

[Flags]
public enum OperationMode
{
    /// <summary>
    /// Asynchronous operation mode
    /// </summary>
    Async = 0,
    /// <summary>
    /// Synchronous operation mode
    /// </summary>
    Sync = 1,
    /// <summary>
    /// Accept bubble requests mode
    /// </summary>
    Parent = 2
}

Now, it’s possible to do statements like:

[DefaultValue(OperationMode.Async)]
[TypeConverter(typeof(EnumConverter))]
public OperationMode Mode { get; set; }

/// <summary>
/// Gets a value indicating whether this instance supports request from childrens.
/// </summary>
public bool IsParent
{
    get { return (this.Mode & OperationMode.Parent) == OperationMode.Parent; }
}

switch (this.Mode)
{
    case OperationMode.Sync | OperationMode.Parent:
        Console.WriteLine("Sync,Parent");
        break;
[…]

But there is something that you should never forget: Zero is the absorber element for the bitwise AND operation.

So, checking for OperationMode.Async (the Zero value) mode just like the OperationMode.Parent mode makes no sense since it will always be true:

(this.Mode & 0x0) == 0x0

Instead, inverse logic should be used: OperationMode.Async = !OperationMode.Sync

public bool IsAsync
{
    get { return (this.Mode & ContentManagerOperationMode.Sync) != ContentManagerOperationMode.Sync; }
}

public bool IsAsync
{
    get { return (int)this.Mode == 0; }
}

[Begin: Edit]

Some readers suggested to use the Enum.HasFlag method. Although it’s another valid approach it’s also widely accepted that this method has some performance issues related an internal box/unboxing.

Use it when performance is not a problem (I see this method mostly used by rookie developers).

[End: Edit]

Final Note:

Benefits

Allow multiple values combination

The above samples snippets were taken from an ASP.NET control and enabled the following markup usage:

<my:Control runat="server" Mode="Sync,Parent">

Drawback

Zero value is the absorber element for the bitwise AND operation

Be very carefully when evaluating the Zero value, either evaluate the enum value as an integer or use inverse logic.

OpenXML error “file is corrupt and cannot be opened.”

NunoGomes — Wed, 20 Jun 2012 05:00:00 GMT

From time to time I ear some people saying their new web application supports data export to Excel format.

So far so good … but they don’t tell the all story … in fact almost all the times what is happening is they are exporting data to a Comma-Separated file or simply exporting GridView rendered HTML to an xls file.

Ok … it works but it’s not something I would be proud of.

So … yesterday I decided to take a look at the Office Open XML File Formats Specification (Microsoft Office 2007+ format) based on well-known technologies: ZIP and XML.

I start by installing Open XML SDK 2.0 for Microsoft Office and playing with some samples.

Then I decided to try it on a more complex web application and the “file is corrupt and cannot be opened.” message start happening.

Google show us that many people suffer from the same and it seems there are many reasons that can trigger this message. Some are related to the process itself, others with encodings or even styling.

Well, none solved my problem and I had to dig … well not that much, I simply change the output file extension to zip and extract the zip content.

Then I did the same to the output file from my first sample, compare both zip contents with SourceGear DiffMerge and found that my problem was Culture related.

Yes, my complex application sets the Thread.CurrentThread.CurrentCulture to a non-English culture.

For sample purposes I was simply using the ToString method to convert numbers and dates to a string representation but forgot that XML is culture invariant and thus using a decimal separator other than “.” will result in a deserialization problem.

I solve the “file is corrupt and cannot be opened.” by using Convert.ToString(object, CultureInfo.InvariantCulture) method instead of the ToString method.

Hope this can help someone.

Error when running .NET Application that is consuming CRM 2011 Services

Anonymous — Mon, 30 Apr 2012 05:00:00 GMT

Hi All,

I was trying to run a .NET application that consumes CRM 2011 WCF Services and i was getting this exception:

Could not load file or assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

The cause of this issue is to due to missing dlls in your machine for Microsoft Identity framework that is required to have to run your application.

Install Microsoft Identity Framework in your computer that is compatible with your operating system.

For Windows 7 & Windows 2008 R2 you need to install Version 6.1

After you install this update re-run your application and will run with no exceptions!

Note: Make sure to stop your development web sever before rerun your application to reload all required assemblies.

**Download link:
http://www.microsoft.com/en-us/download/details.aspx?id=17331

Hope this helps!

Demos and slides from my HTML5 and REST presentation in Belgium last week

Maurice — Tue, 03 Apr 2012 05:00:00 GMT

HTML5 & rest services

View more PowerPoint from Maurice Beijer

You can download the ASP.NET WebAPI demo here and the SignalR demo here.

Enjoy!

TheProblemSolver
DotNetEvents

DotNed podcast: Jeff Prosise about the future with Silverlight, HTML5/JavaScript and Windows 8

Maurice — Fri, 23 Mar 2012 05:00:00 GMT

In this podcast Dennis Vroegop speaks with Jeff Prosise about the future of software development for the .NET developer.

Links:

Blog: http://www.wintellect.com/cs/blogs/jprosise/
TechDays presentation : http://www.techdays.nl/SprekerDetail.aspx?cid=2136

Thanks to out sponsor RedGate.

http://dotned.nl/PodCasts.aspx?id=27

Enjoy

TheProblemSolver
DotNetEvents

Client side support with the ASP.NET Web API

Maurice — Tue, 13 Mar 2012 05:00:00 GMT

With REST there is not a lot required on the client as far as sending requests goes. As long as you can send HTTP GET requests you are good to go and there are very few programming stacks that don’t allow for some form of doing that. Of course just doing an HTTP GET is going to give you some data back and you still have to understand that data but that is an application specific issue.

In order to make life even easier the ASP.NET Web API adds some client support in the form of the HttpClient class. But first lets see what happens if we just hit an ASP.NET Web API endpoint with a simple client.

I am using Entity Framework Code First here and the model and context look like this:

   1: public class Product

   2: {

   3:     public int ProductID { get; set; }

   4:     public string ProductName { get; set; }

   5:     public decimal UnitPrice { get; set; }

   6: }

7:

   8: public class NorthwindContext : DbContext

   9: {

  10:     public DbSet<Product> Products { get; set; }

  11: }

And the ASP.NET Web API controller looks like this:

   1: public class ProductsController : ApiController

   2: {

   3:     private NorthwindContext _db = new NorthwindContext();

4:

   5:     // GET /api/<controller>

   6:     public IEnumerable<Product> Get()

   7:     {

   8:         return _db.Products.ToList();

   9:     }

10:

  11:     // GET /api/<controller>/5

  12:     public Product Get(int id)

  13:     {

  14:         return _db.Products.Single(p => p.ProductID == id);

  15:     }

16:

  17:     protected override void Dispose(bool disposing)

  18:     {

  19:         if (disposing && _db != null)

  20:         {

  21:             _db.Dispose();

  22:             _db = null;

  23:         }

  24:         base.Dispose(disposing);

  25:     }

  26: }

Given that the Web API supports returning both XAML and JSON it would appear the following code would work just fine.

   1: static void Main(string[] args)

   2: {

   3:     var baseUrl = @"http://localhost.:6876/api/products";

   4:     var xml = XElement.Load(baseUrl);

5:

   6:     foreach (var product in xml.Descendants("Product"))

   7:     {

   8:         Console.WriteLine("Product '{0}' costs {1:C}", (string)product.Element("ProductName"), (decimal)product.Element("UnitPrice"));

   9:     }

  10: }

Unfortunately it doesn’t and we receive an XmlException with the message “Data at the root level is invalid”. The reason is that the XElement sends the request to the server without specifying an accept header. And where in the previous WCF Web API this would have worked because XML was the default type if nothing was specified this has changed. With the ASP.NET Web API the default is JSON. So this request returns a JSON data stream the XElement can’t handle. What we need to do is specify we want XML using the HTTP Accept header. There are different ways we can do this but here I am going to the the client side support in the form of the HttpClient.

Using the HttpClient

First we need to add a NuGet package named System.Net.HTTP that contains the required classes

With that in place we can start using the HttpClient instead. The code is a bit longer but that is mainly because we still need to set the HTTP Accept header to return XML instead of the default JSON

   1: static void Main(string[] args)

   2: {

   3:     var baseUrl = @"http://localhost.:6876/api/products";

   4:     var client = new HttpClient();

   5:     client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/xml"));

   6:     var stream = client.GetStreamAsync(baseUrl).Result;

   7:     var xml = XElement.Load(stream);

8:

   9:     foreach (var product in xml.Descendants("Product"))

  10:     {

  11:         Console.WriteLine("Product '{0}' costs {1:C}", (string)product.Element("ProductName"), (decimal)product.Element("UnitPrice"));

  12:     }

  13: }

And this works just fine

Loading a single product is just as easy

   1: var baseUrl = @"http://localhost.:6876/api/products";

   2: var client = new HttpClient();

   3: client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/xml"));

   4: var stream = client.GetStreamAsync(baseUrl + @"\42").Result;

   5: var product = XElement.Load(stream);

6:

   7: Console.WriteLine("Product '{0}' costs {1:C}", (string)product.Element("ProductName"), (decimal)product.Element("UnitPrice"));

Adding new data using the HttpClient

Adding a new product is almost just as easy. First we need to create a valid XML document containing a new product, then turn it into a steam and we can post it.

   1: var newProduct = new XElement("Product", new XElement("ProductName", "ASP.NET Web API"), new XElement("UnitPrice", 0));

   2: var stream = new MemoryStream();

   3: newProduct.Save(stream);

   4: stream.Position = 0;

5:

   6: var baseUrl = @"http://localhost.:6876/api/products";

   7: var client = new HttpClient();

   8: var content = new StreamContent(stream);

   9: content.Headers.ContentType = new MediaTypeHeaderValue("application/xml");

10:

  11: var response = client.PostAsync(baseUrl, content).Result;

  12: Console.WriteLine("StatusCode: {0}", response.StatusCode);

This code might seem a bit verbose but that is mainly because the client is real simple and uses POX and therefore a StreamContent. There are also richer ways of doing so with declared types and the ObjectContent<T>. The result is a predictable OK status with the new product being added to the database.

Of course this should really have been a 201 Created with the URL pointing to the location of the new resource but we still need to look at how to control the response message from the ApiController.

Enjoy!

TheProblemSolver
DotNetEvents

Updating data with the ASP.NET Web API

Maurice — Mon, 12 Mar 2012 05:00:00 GMT

In the previous blog post I demonstrated how to get started with the ASP.NET Web API and retrieve some products data from the Northwind database. Something that was really easy to do But quite often we want to update data just as much as we want to retrieve it.

A quick recap of REST and HTTP methods used.

The convention for REST service as defined by Roy Fielding is to use different HTTP methods to signify our intent with the HTTP request. The HTTP GET method, by far the most commonly used one on the internet, is used to retrieve data. This should be a completely save action and have no side effects whatsoever for the client to worry about. When we start changing data we start using other HTTP methods. The following table are the most commonly used HTTP methods and the database CRUD actions they to.

HTTP Method	CRUD Action
Get	Select
Post	Insert
Put	Update a complete entity
Patch	Update a partial entity
Delete	Delete an entity

Quite simple right? And even the Patch method isn’t used that often, in most cases just 4 methods are used.

Implementing update methods in the ASP.NET Web API

As I explained in my last post the ASP.NET Web API uses convention over configuration and by convention is to create an ApiController with functions where the name starts with the HTTP method to support. We can do things differently with attributes if we want to but for now lets just stick to the convention.

Adding new products to the database.

As we have just seen creating new data is done with a POST method so we need to implement a Post() function in our ProductsController. Doing so is quite easy:

   1: public class ProductsController : ApiController

   2: {

   3:     private NorthwindEntities _db = new NorthwindEntities();

4:

   5:     // GET /api/<controller>

   6:     public IEnumerable<Product> Get()

   7:     {

   8:         return _db.Products.ToList();

   9:     }

10:

  11:     // GET /api/<controller>/5

  12:     public Product Get(int id)

  13:     {

  14:         return _db.Products.Single(p => p.ProductID == id);

  15:     }

16:

  17:     // POST /api/<controller>

  18:     public void Post(Product product)

  19:     {

  20:         _db.AddToProducts(product);

  21:         _db.SaveChanges();

  22:     }

23:

  24:     protected override void Dispose(bool disposing)

  25:     {

  26:         if (disposing && _db != null)

  27:         {

  28:             _db.Dispose();

  29:             _db = null;

  30:         }

  31:         base.Dispose(disposing);

  32:     }

  33: }

Of course in reality a Post action would be somewhat more complicated. For starters we would need some error handling in case the data was invalid. Another issue is that, if everything goes well, we are just returning a 200 Ok status where we should be returning a 201 Created status with the location of the newly created resource. But for now this is good enough.

We still need a way to test this and the perfect tool to monitor and test HTTP related traffic if Fiddler. Using Fiddler we can POST a new product, in this case the ASP.NET Web API itself, to the server.

And as we can see when we check the database or use the GET method in the correct URL the new record is inserted.

There are two interesting things to note here.

All I had to do is have a function were the name starts with Post and it is automatically called when an HTTP POST is received.
The function parameter is of type Product and the ASP.NET Web API does the proper deserialization for us.

How easy can they make things?

And implementing PUT and DELETE would work in the same way.

The “complete” ApiController looks like this:

   1: public class ProductsController : ApiController

   2: {

   3:     private NorthwindEntities _db = new NorthwindEntities();

4:

   5:     // GET /api/<controller>

   6:     public IEnumerable<Product> Get()

   7:     {

   8:         return _db.Products.ToList();

   9:     }

10:

  11:     // GET /api/<controller>/5

  12:     public Product Get(int id)

  13:     {

  14:         return _db.Products.Single(p => p.ProductID == id);

  15:     }

16:

  17:     // POST /api/<controller>

  18:     public void Post(Product product)

  19:     {

  20:         if (ModelState.IsValid)

  21:         {

  22:             _db.AddToProducts(product);

  23:             _db.SaveChanges();

  24:         }

  25:     }

26:

  27:     // PUT /api/<controller>/5

  28:     public void Put(int id, Product product)

  29:     {

  30:         var orgProduct = _db.Products.Single(p => p.ProductID == id);

  31:         // Copy properties from product to orgProduct

  32:         _db.SaveChanges();

  33:     }

34:

  35:     // DELETE /api/<controller>/5

  36:     public void Delete(int id)

  37:     {

  38:         var product = _db.Products.Single(p => p.ProductID == id);

  39:         _db.Products.DeleteObject(product);

  40:         _db.SaveChanges();

  41:     }

42:

  43:     protected override void Dispose(bool disposing)

  44:     {

  45:         if (disposing && _db != null)

  46:         {

  47:             _db.Dispose();

  48:             _db = null;

  49:         }

  50:         base.Dispose(disposing);

  51:     }

  52: }

Enjoy!

TheProblemSolver
DotNetEvents

How to hide TFS web access tabs

Anonymous — Mon, 12 Mar 2012 05:00:00 GMT

Hi folks,

I was tasked to hide Source and Build tabs in TFS 2010 Web Access. I started to find out if TFS has any security groups that prevent users to view source or build tabs but with no luck!. TFS doesn't have security permissions to grant/hide tabs in TFS web application. To tackle this i wrote a javascript function which hides those tabs. After looking in the TFS web application in IIS i found that i can write this Javascript in "Content.master" Master page file for TFS web.

Just add this script in the header of Content.master file:

<script type="text/javascript">

window.onload = function() {

// Search for the top navigation menu.

var x= document.getElementById('ctl00_pghd_mainTabs');

// Search for rows in this table.

for(var i=0;i<x.rows.length;i++)

{

// only remove tabs in the first row.

if(i==0)

{

// Remove Source tab.

x.rows[i].cells[3].style.display='none';

// Remove Build tab.

x.rows[i].cells[4].style.display='none';

}

</script>

To download the updated content.master file:

Also, To prevent any web users not to view any of source or build pages, Go to IIS and do the following:
1) Open TFS web site in IIS.
2) Expand tfs and then UI folder.
3) Select Build folder.
4) Double click on Authentication and disable Windows and Anonymous access to this folder.
5) Do the same for Scc folder which has all source tab pages.

With these 2 steps, we added security on the folder level in addition to hide Build and Source tabs.

Hope this helps!

Getting started with the ASP.NET Web API

Maurice — Fri, 09 Mar 2012 06:00:00 GMT

Some time ago I did a number of blog posts about the beta versions of the WCF Web API. As it turns out the WCF Web API team has moved into the ASP.NET team, a good thing as far as I am concerned, and as a result it is now called ASP.NET Web API. Now this is much more that just a name change. For starters there is very little of the WCF bits still involved, in fact when you use ASP.NET as a host none at all. As a result it takes on quite a few characteristics of ASP.NET MVC with convention over configuration. Quite a difference from WCF which is all about taking configuration to the max.

In this blog post I am going to show how to get started with the ASP.NET Web API.

What is the ASP.NET Web API all about?

The ASP.NET Web API is a framework build on top of the core ASP.NET engine for creating REST services. And REST services have become relatively popular as a result of the popularity of web and mobile applications where the traditional SOAP service are a bit to rigid and cumbersome to work with. Now this certainly doesn’t mean that SOAP services are going to disappear but we will see an increasing number of REST services as an addition.

On .NET there are a number of different options for REST services. There are some pretty good open source alternatives like OpenRasta. And the WCF team has made a number of attempts at providing a REST framework in the past which where usable but less successful. The WCF Web API was a big improvement as that was much more inline with HTTP, as a RESTful service should be, but the tie to WCF was a bit a problem as the whole WCF stack was architected and build with SOAP in mind.

The ASP.NET Web API should provide a far more flexible framework for building RESTful services.

The ASP.NET Web API bits ship as part of ASP.NET MVC4 beta right now but that doesn’t mean you are tied to using an MVC application. Personally I like MVC but if you prefer ASP.NET WebForms that will work fine, in fact you can use any ASP.NET as a host. For that matter if you don’t want an ASP.NET host it is perfectly fine to self host the ASP.NET Web API in whatever host application you want. Console, Windows Service you name it and it should just work. But I am going to leave self hosting for another post as I suspect most people will host their Web API as part of an ASP.NET web site. So in this demo I am going to use ASP.NET MVC 4.

Creating a ASP.NET MVC 4 new application

When you create a new MVC 4 application you get the option of creating a Web API project. There is nothing wrong with that but in this case I am not going to do that and I am just going to create a standard Internet Application and add a Web API to that.

I have a copy of the Northwind database on my machine and I am going to create a Web API service to return the products data from that database. So first I need to create a Entity Framework model with the table definition.

Next we need a controller to return the product data. Instead of a normal MVC controller we should be using an ApiController here. An ApiController is a special type of controller all geared towards creating a REST service. The convention is to store these in an API folder. The same convention as with regular MVC applies so we have to create a controller named ProductsController.

The resulting code is quite simple but it shows us how to get started with an ASP.NET Web API controller.

   1: public class ProductsController : ApiController

   2: {

   3:     // GET /api/<controller>

   4:     public IEnumerable<string> Get()

   5:     {

   6:         return new string[] { "value1", "value2" };

   7:     }

8:

   9:     // GET /api/<controller>/5

  10:     public string Get(int id)

  11:     {

  12:         return "value";

  13:     }

14:

  15:     // POST /api/<controller>

  16:     public void Post(string value)

  17:     {

  18:     }

19:

  20:     // PUT /api/<controller>/5

  21:     public void Put(int id, string value)

  22:     {

  23:     }

24:

  25:     // DELETE /api/<controller>/5

  26:     public void Delete(int id)

  27:     {

  28:     }

  29: }

In fact if we run the application as is and navigate to the URL for this controller, in my case http://localhost:3438/api/products but your port number is going to be different, we can see it already returns some data.

So why does this URL work? Well out of the box an ASP.NET MVC4 project has 2 routes configured. One for the normal controller and the other for Web API controllers. You can find the relevant code in the global.asax.

   1: public static void RegisterRoutes(RouteCollection routes)

   2: {

   3:     routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

4:

   5:     routes.MapHttpRoute(

   6:         name: "DefaultApi",

   7:         routeTemplate: "api/{controller}/{id}",

   8:         defaults: new { id = RouteParameter.Optional }

   9:     );

10:

  11:     routes.MapRoute(

  12:         name: "Default",

  13:         url: "{controller}/{action}/{id}",

  14:         defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }

  15:     );

  16: }

Of course you are free to change the path but for now I am going to leave it as is as the default convention of putting Web API request in an API URL makes sense to me.

There are a couple of things to note in the code for the ProductsController. First of all there are no attributes used. WCF was all about attributes, MVC is all about conventions. So the the convention is if the function name starts with Get it will respond to an HTTP GET method, if it starts with Post it responds to an HTTP POST method and so on. You can change this with attributed but it sounds perfectly fine and good enough for me. What matters is the start of the function name. So changing it to GetProducts() will work just fine but using LoadProducts() will result in the following error:

The parameters dictionary contains a null entry for parameter 'id' of non-nullable type 'System.Int32' for method 'System.String Get(Int32)' in 'WebAPIDemo.Api.Controllers.ProductsController'. An optional parameter must be a reference type, a nullable type, or be declared as an optional parameter.

Not quite a clear an error message as I would have liked But then it is only a beta so there is hope.

Returning some actual product data from our Web API service

Doing that is actually quite easy. All we need to do is redefine the Get() function to return an IEnumerable<Product>, instantiate a NorthwindEntities context and return the Products collection.

   1: public class ProductsController : ApiController

   2: {

   3:     private NorthwindEntities _db = new NorthwindEntities();

4:

   5:     // GET /api/<controller>

   6:     public IEnumerable<Product> Get()

   7:     {

   8:         return _db.Products.ToList();

   9:     }

10:

  11:     protected override void Dispose(bool disposing)

  12:     {

  13:         if (disposing && _db != null)

  14:         {

  15:             _db.Dispose();

  16:             _db = null;

  17:         }

  18:         base.Dispose(disposing);

  19:     }

  20: }

Refreshing the page in the browser now returns the products data as expected:

Returning the a single product is just as easy. Just implement the Get(int id) function to return the correct Product as follows.

   1: // GET /api/<controller>/5

   2: public Product Get(int id)

   3: {

   4:     return _db.Products.Single(p => p.ProductID == id);

   5: }

Not surprisingly just the single product is returned when we add a product id to the URL.

That is enough for a first post. Next time I am going to take a look at what it takes to add new or update existing product data using the ASP.NET Web API.

Enjoy!

TheProblemSolver
DotNetEvents