Here is short tutorial only about the difference DataSet, DataReader, DataAdapter and DataView in .net.

1. DataSet

Dataset is connection-less oriented, that means whenever we bind data from database it connects indirectly to the database and then disconnected. It has read/write access on data tables. It supports both forward and backward scanning of data.

DataSet is a container of one or more DataTable. More often than not, it will just contain one table, but if you do a query with multiple SELECT statements, the DataSet will contain a table for each.

You have to be careful about how much data you pull into a DataSet, because this is an in-memory representation. You can Fill a DataSet using the Fill() method of a DataAdapter.

You can download example code at the end of this tutorial!

2. DataReader

DataReader is connection-oriented, that means whenever we bind data from database it must require a connection and after that disconnected from the connection. It has read-only access, we can’t do any transaction on them. It supports forward-only scanning of data, in other words you can’t go backward.

DataReader fetches one row at a time so very less network cost as compare to DataSet(that fethces all the rows at a time). It is scalable to any number of records, at least in terms of memory pressure, since it only loads one record at a time. One typical way to get a DataReader is by using theExecuteReader() method of a DbCommand.

You can download example code at the end of this tutorial!

3. DataAdapter

DataAdapter is an ADO.NET Data Provider. DataAdapter can perform any SQL operations like Insert, Update, Delete, Select in the Data Source by using SqlCommand to transmit changes back to the database.

DataAdapter provides the communication between the Dataset/DataTable and the Datasource. We can use the DataAdapter in combination with the DataSet/DataTable objects. These two objects combine to enable both data access and data manipulation capabilities.

You can download example code at the end of this tutorial!

4. DataView

Generally, we use DataView to filter and sort DataTable rows. So we can say that DataView is like a virtual subset of a DataTable. This capability allows you to have two controls bound to the same DataTable, but showing different versions of the data.

For example, one control may be bound to a DataView showing all of the rows in the table, while a second may be configured to display only the rows that have been deleted from the DataTable. The DataTable also has a DefaultView property which returns the default DataView for the table.

In this article, I will share about how to improve your ASP.NET Web API performance

1. Use fastest JSON serializer

JSON serialization  can affect overall performance of ASP.NET Web API significantly. A year and a half I have switched from JSON.NET serializer on one of my project to ServiceStack.Text .

2. Use other formats if possible (protocol buffer, message pack)

If you can use other formats like Protocol Buffers or MessagePack in your project instead of JSON do it.

You will get huge performance benefits not only because Protocol Buffers serializer is faster, but because format is smaller than JSON which will result in smaller and faster responses.

3. Implement compression

Use GZIP or Deflate compression on your ASP.NET Web API.

Compression is an easy and effective way to reduce the size of packages and increase the speed.

4. Use Caching

If it makes sense, use output caching on your Web API methods. For example, if a lot of users accessing same response that will change maybe once a day.

5. Implement async on methods of Web API

Using asynchronous Web API services can increase the number of concurrent HTTP requests Web API can handle.

Implementation is simple. The operation is simply marked with the async keyword and the return type is changed to Task.

[HttpGet] 
public async Task OperationAsync() 
{  
    await Task.Delay(2000); 
}

6. Use classic ADO.NET if possible

Hand coded ADO.NET is still the fastest way to get data from database. If the performance of Web API is really important for you, don’t use ORMs.

Please just see this table performance below

The Dapper and the hand-written fetch code are very fast, as expected, all ORMs are slower than those three.

LLBLGen with resultset caching is very fast, but it fetches the resultset once and then re-materializes the objects from memory.

Hope above tutorial help you.

Hello, in this post, I will describe short tutorial about how to solve The specified string is not in the form required for an e-mail address. I found many people find this error on forums. Here is the error message:

As you can see above, that is the error message that you might find. So, what’s the problem?

OK, the problem in this case is not from the page itself, but it comes from your web.config file. This configuration file has a <system.net /> element that enables you to store information about the mail server and the from account. I will give you 2 examples below how it will crash your page:

<system.net>
  <mailSettings>
    <smtp from="you.yourprovider.com">
      <network host="smtp.yourprovider.com"/>
    </smtp>
  </mailSettings>
</system.net>

Please see the missing @ symbol in the mail address. And other error may come from incorrect encoded angled brackets, see this:

<system.net>
  <mailSettings>
    <smtp from="Your Name &lt;[email protected]">
      <network host="smtp.yourprovider.com"/>
    </smtp>
  </mailSettings>
</system.net>

This from attributes has an opening < character (encoded as &lt;) but lacks the closing > bracket. To avoid the error, make sure the e-mail address in the from attribute has a valid syntax and uses the right angled brackets (if you use both a name and an e-mail address) like this:

<system.net>
  <mailSettings>
    <smtp from="Your Name &lt;[email protected]&gt;">
      <network host="smtp.yourprovider.com"/>
    </smtp>
  </mailSettings>
</system.net>

If you are curious why your code crashed, then you can use Reflector and take a look in the class’s constructor code:

public MailMessage()
{
  this.body = string.Empty;
  this.message = new Message();
  if (Logging.On)
  {
    Logging.Associate(Logging.Web, this, this.message);
  }
  string from = SmtpClient.MailConfiguration.Smtp.From;
  if ((from != null) && (from.Length > 0))
  {
    this.message.From = new MailAddress(from);
  }
}

Here you can see that the code uses the (internal and static) MailConfiguration property of the SmtpClient class that in turn provides access to the From name and address. This name and address value is then passed into the constructor of the MailAddress class which performs the actual validation using its private ParseValue method.

Choosing Best ASP.NET Hosting with HostForLIFE.eu

We know that it is quite hard to find good asp.net hosting in Europe. Why you need to choose us to be your hosting partner?

HostForLIFE.eu is awarded Top No#1 SPOTLIGHT Recommended Hosting Partner by Microsoft (see www.microsoft.com/web/hosting/HostingProvider/Details/953). Our service is ranked the highest top #1 spot in several European countries, such as: Germany, Italy, Netherlands, France, Belgium, United Kingdom, Sweden, Finland, Switzerland and other European countries.

With more and more people and companies developing websites by Microsoft .NET technology, ASP.NET 4.5 shared web hosting comes to be the major solution provided by many web hosting companies. Most of people choose an ASP.NET 4.5 web host considering about .NET framework version, ASP.NET MVC support, SQL Server database, disk space or bandwidth but they usually ignore the most important feature “IIS security level”. That determines whether the ASP.NET 4.5 websites can run successfully on the shared web host. In result to, if you developing an ASP.NET 4.5 website that works well in the local development environment and attempt to run it in the ASP.NET 4.5 shared web host, you may get the following exception,

System.Security.SecurityException: That assembly does not allow partially trusted caller

This is caused by the security level of the ASP.NET 4.5 shared web host that your application is forced to run with the limited permission, by locking down the access to server file system, preventing the background threads, or interacting with COM interfaces, etc.

ASP.NET 4.5 Web Hosting Trust Levels

This security level is known as the Trust Level of IIS for ASP.NET 4.5 websites. 

It can be configured with the following setting:

• Full Trust: website can do everything that the account of the application pool can do on the web server. This is the most flexible configuration for running websites on the shared web hosts. You won’t have any problems unless your website accesses the system information.
• High Trust: websites are limited to call unmanaged code, e.g. Win32 APIs, COM interop.
• Medium Trust: websites are limited to access the file system except the website application directory, system registry, Code DOM, and more (we will talk it later), compared to High Trust.
• Low Trust & Minimal Trust: these two options restrict the websites seriously. Even they don’t allow websites to call the service out of process, such as database, network, etc. But we never saw an ASP.NET 4.5 shared web host configured with either one of these two options.

Full Trust and Medium Trust are two widely used levels in ASP.NET 4.5 shared web hosting. The full trust provides best flexibility but it has potential security issues to the shared server, especially when the web hosting provider doesn't have rich experience on setting up Windows permission and IIS. Compared to Full Trust, you have to review the website carefully before you go with a web host only supports Medium Trust Level. You can refer to the following checkpoints for the review,

• The website shall not call unmanaged APIs.
• The website shall not access to file system, system registry, event logs and anything else related to the system.
• The website shall not generate code for execution dynamically using Code DOM.
• The website shall not use XslTransform to transform something from XML using XSLT.
• The website has to be signed with a Strong Name.

Check with the web page from Microsoft about which namespaces and classes are not supported in Medium Trust environment. 

And here is quick way to confirm the compatibility of websites to Medium Trust Level, in the local environment,

1. Add partially trusted callers attribute into AssemblyInfo.cs file of the website project, as following code snippet,

[assembly: AllowPartiallyTrustedCallers]

2. Add the following line into the web.config,

<trust level="Medium" />

Suggestion

It's a tradeoff between these two trust level. But if you confirm that the website can run successfully with Medium Trust in your local environment, we suggest you choose an ASP.NET 4.5 web host with Medium Trust only. It shall be more secure and reliable anyway. If you host the website based on 3rd party framework such as DotNetNuke, or using 3rd party component, we recommend you going with Full Trust web host.