Friday, June 23, 2017

.NET Core or .NET Framework, What is right for your application?

.NET Framework and .NET Core are two choices for building .NET server-side applications. Both share a lot of the same .NET platform components and you can share code across the two. However, there are fundamental differences between the two and based on what you want to accomplish, your requirement your choice will depend. 
You should use .NET Core for your server application when:
  • You have cross-platform needs.
  • You are targeting microservices.
  • You are using Docker containers.
  • You need high performance and scalable systems.
  • You need side by side of .NET versions by application.
You should use .NET Framework for your server application when:
  • Your application currently uses .NET Framework (recommendation is to extend instead of migrating)
  • You need to use third-party .NET libraries or NuGet packages not available for .NET Core.
  • You need to use .NET technologies that are not available for .NET Core.
  • You need to use a platform that doesn’t support .NET Core.

Thursday, April 20, 2017

Best way to understand Bubble sort and Insertion Sort Algorithm

Bubble Sort 

Below image will describe how bubble sort code work when code execute in loop, below pictures are self explanatory for algorithm steps. 
C# Code
public int[] BubbleSort(int[] val)
{
           bool flag = true;
           int temp;

           for (int i =0;(i<=val.Count()-1) && flag; i++)
           {
               flag = false;
               for (int j = 0; j < val.Count()-1; j++)
               {
                   if (val[j + 1] < val[j])
                   {
                       temp = val[j + 1];
                       val[j + 1] = val[j];
                       val[j] = temp;
                       flag = true;
                   }
               }
           }
           return val;
}

Insertion Sort

Faster than bubble sort
C# Code
public int[] InsertionSort(int[] val)
{
           for (int i = 0; i <= val.Count(); i++)
           {
               int temp = val[i];
               int j = i - 1;

               while (j >= 0 && val[j] < temp)
               {
                   val[j + 1] = val[j];
                   j--;
               }
               val[j + 1] = temp;
        }
           return val;
}

.NET Core Error: /Core and /WepApp.deps.json could not be found

When I tried to run my first .NET Core web application, I found wired issues and it took me longer time to figure out, what is actual issues was, error message was not helping at all to find out the solution

.NET Core Error: <<Project Dir Path>>/Core and <<Project Dir Path>>/WepApp.deps.json could not be found

To find out the solution, I started couple of times from scratch and finally I tried with different directory and file name to save my .NET Core project.

Issues:
Previous Project Path was:  C:\Ritesh\NET Core\Core WebAPP

Solution:
Later Project Path (works): C:\Ritesh\NETCore\CoreWebApp  (NO SPACE in dir name and file name)

It's works for me, I don't know this is the really solution or Microsoft need to release some patch to fix this.

Friday, March 10, 2017

Parameters needs to be considered before choosing REST or SOAP

There are many parameter needs to be considered before choosing REST or SOAP like

Performance & Scalability
  • REST has better Performance and Scalability features. Read operation in REST can be cached whereas SOAP based read cannot be cached.
  • REST service is good when we have limited bandwidth and have requirement to accomplish by simple CRUD based operation.
Security
  • Provide more choice for implementing security beyond the standard SSL support by implementing WS-Security standard
Transaction Support
  • SOAP can support distributed two-phase commit transactions by implementing WS-Atomic standards.
  • REST does not support transaction
Extended Client Support
  • REST allow better support for browser and mobile clients due to its support for JSON.
Extended Data Format Support
  • REST allows many data format like JSON, XML, Text, SOAP only support XML which require more bandwidth to pass data through wire
Multiple Protocol Support
  • SOAP service can use any transport protocol such as HTTP, HTTPS, TCP, SMTP, and MSMQ. REST only support standard HTTP and it is much easier to implement, simple methods to call GET, PUT, POST and DELETE.
Error Handling
  • REST support standard HTTP error handling but SOAP provide more robust error handling including user define error handling.
Summary

                   REST
                     SOAP
Expose the data
Expose the logic
Support multiple Data format, JSON, XML, HTML, Text etc.
Support only XML
Support only Http, Https protocol
Support multiple protocol; Http, Https, TCP, UDP SMTP, Messaging etc.
Support for Transaction Management but not ACID compliance or two-phase commit transaction.
Better support for transaction management Support, ACID and two-phase commit transaction by implementing WS-Atomic Standard
Need less band width
Need more band width because of XML
Suited for stateless CRUD operations
Suited for Stateful operation, Easy to configure session support
Less support for Security
Supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.
SOAP WS has Better support for Security Both SSL security and WS-security
Better Support for browsers and mobile client, Because of Lightweight
Limited browser support
Read operation can be cached
Read Operation cannot be cached
Support for better performance and scalability
Performance is less as compare to REST
Support only HTTP error Handling
Support robust error handling including user define error handling
Only support Synchronous message
Can support Synchronous and Asynchronous both messages

Thursday, February 02, 2017

WCF Security, When/How to Use, Advantages and Disadvantages

Transport Security
Message Security
When using transport security, the user credentials and claims are passed by using the transport layer. In other words, user credentials are transport-dependent, which allows fewer authentication options compared to message security. Each transport protocol (TCP, IPC, MSMQ, or HTTP) has its own mechanism for passing credentials and handling message protection. The most common approach for this is to use Secure Sockets Layer (SSL) for encrypting and signing the contents of the packets sent over Secure HTTP (HTTPS).
When using message security, the user credentials and claims are encapsulated in every message using the WS-Security specification to secure messages. This option gives the most flexibility from an authentication perspective. You can use any type of security credentials you want, largely independent of transport, as long as both the client and service agree.
Use
  • You are sending a message directly from your application to a WCF service and the message will not be routed through intermediate systems.
  • Both the service and the client are located in an intranet.
Use
  • You are sending a message to a WCF service, and the message is likely to be forwarded to other WCF services or may be routed through intermediate systems.
  • Your WCF clients are accessing the WCF service over the Internet and messages may be routed through intermediate systems.
Advantage
  • It provides interoperability, meaning that communicating parties do not need to understand WS-Security specifications.
  • It may result in better performance.
  • Hardware accelerators can be used to further improve the performance.
Advantage
  • It provides end-to-end security. Because message security directly encrypts and signs the message, having intermediaries does not break the security.
  • It allows partial or selective message encryption and signing, thus improving overall application performance.
  • Message security is transport-independent and therefore can be used with any transport protocol.
  • It supports a wide set of credentials and claims, including the issue token that enables federated security.
Dis Advantage
  • Security is applied on a point-to-point basis, with no provision for multiple hops or routing through intermediate application nodes.
  • It supports a limited set of credentials and claims compared to message security.
  • It is transport-dependent upon the underlying platform, transport mechanism, and security service provider, such as NTLM or Kerberos.
Dis Advantage
  • This option may reduce performance compared to transport security because each individual message is encrypted and signed.
  • It does not support interoperability with older ASMX clients, as it requires both the client and service to support WS-Security specifications.
<netTcpBinding>
<binding name="netTcpTransportBinding">
   <security mode="Transport">
              <Transport clientCredentialType="Windows" />
   </security>
</binding>
</netTcpBinding>
<wsHttpBinding>
<binding name="wsHttpMessageBinding">
  <security mode="Message">
              <Message clientCredentialType="UserName" />
  </security>
 </binding>
</wsHttpBinding>