Restricting WebAPI / Site via URLRewrite

We create websites and microservices. Let's say we want it to be publicly accessible and hosted on the IIS server. Due to security concerns, we are forced to limit access to various APIs and websites to specific IP ranges exclusively. This will limit access to our website's API to a select group of users.

This requires the usage of the URL Rewrite module extension in the IIS Server.

Download this from the link below.

https://iis-umbraco.azurewebsites.net/downloads/microsoft/url-rewrite

Sample configuration for restricting the IP range

Two Threads printing ABCD sequence one in upper and another in lower

Suppose there is a ABCD.... sequence we want to print this sequence on Two threads. One thread printing in Upper case and another in Lower case without breaking the sequences or order.

Output should look like

A--thread1
a--thread2
B--thread1
b--thread2
C--thread1
c--thread2


Solution Code
 
using System;
using System.Threading;
class Program
{
    static void Main()
    {
        Thread T1 = new Thread(new ThreadStart(Th1));
        Thread T2 = new Thread(new ThreadStart(Th2));
        T1.Start();
        T2.Start();
    }
   
    static void Th1(){
        string str ="ABCDEF"   ;
        foreach(char c in str){
            Console.WriteLine(c.ToString().ToLower());
            Thread.Sleep(1000);
        }
    }
   
    static void Th2(){
        string str ="ABCDEF"   ;
        foreach(char c in str){
            Console.WriteLine(c);
            Thread.Sleep(1000);
        }
    }
}

Output
A
a
B
b
C
c

ICommand Usage

Below link will explain about the ICommand usage in wpf and also how to implement in MVVM.

Source:

https://www.codeproject.com/Articles/1052346/ICommand-Interface-in-WPF

Does using Tasks (TPL) library make an application multithreaded?

Source: http://stackoverflow.com/questions/23833255/does-using-tasks-tpl-library-make-an-application-multithreaded

Tasks can be used to represent operations taking place on multiple threads, but they don't have to. One can write complex TPL applications that only ever execute in a single thread. When you have a task that, for example, represents a network request for some data, that task is not going to create additional threads to accomplish that goal. Such a program is (hopefully) asynchronous, but not necessarily mutlithreaded.

Parallelism is doing more than one thing at the same time. This may or may not be the result of multiple threads.

Let's go with an analogy here.

---

Here is how Bob cooks dinner:

1. He fills a pot of water, and boils it.
2. He then puts pasta in the water.
3. He drains the pasta when its done.
4. He prepares the ingredients for his sauce.
5. He puts all of the ingredients for his sauce in a saucepan.
6. He cooks his sauce.
7. He puts his sauce on his pasta.
8. He eats dinner.

Bob has cooked entirely synchronously with no multithreading, asynchrony, or parallelism when cooking his dinner.

---

Here is how Jane cooks dinner:

1. She fills a pot of water and starts boiling it.
2. She prepares the ingredients for her sauce.
3. She puts the pasta in the boiling water.
4. She puts the ingredients in the saucepan.
5. She drains her pasta.
6. She puts the sauce on her pasta.
7. She eats her dinner.

Jane leveraged asynchronous cooking (without any multithreading) to achieve parallelism when cooking her dinner.

---

Here is how Servy cooks dinner:

1. He tells Bob to boil a pot of water, put in the pasta when ready, and serve the pasta.
2. He tells Jane to prepare the ingredients for the sauce, cook it, and then serve it over the pasta when done.
3. He waits for Bob and Jane to finish.
4. He eats his dinner.

Servy leveraged multiple threads (workers) who each individually did their work synchronously, but who worked asynchronously with respect to each other to achieve parallelism.

Of course, this becomes all the more interesting if we consider, for example, whether our stove has two burners or just one. If our stove has two burners then our two threads, Bob and Jane, are both able to do their work without getting in each others way, much. They might bump shoulders a bit, or each try to grab something from the same cabinet every now and then, so they'll each be slowed down a bit, but not much. If they each need to share a single stove burner though then they won't actually be able to get much done at all whenever the other person is doing work. In that case, the work won't actually get done any faster than just having one person doing the cooking entirely synchronously, like Bob does when he's on his own. In this case we are cooking with multiple threads, but our cooking isn't parallelized. Not all multithreaded work is actually parallel work. This is what happens when you are running multiple threads on a machine with one CPU. You don't actually get work done any faster than just using one thread, because each thread is just taking turns doing work. (That doesn't mean multithreaded programs are pointless on one cores CPUs, they're not, it's just that the reason for using them isn't to improve speed.)

---

We can even consider how these cooks would do their work using the Task Parallel Library, to see what uses of the TPL correspond to each of these types of cooks:

So first we have bob, just writing normal non-TPL code and doing everything synchronously:

public class Bob : ICook  {      public IMeal Cook()      {          Pasta pasta = PastaCookingOperations.MakePasta();          Sauce sauce = PastaCookingOperations.MakeSauce();          return PastaCookingOperations.Combine(pasta, sauce);      }  }

Then we have Jane, who starts two different asynchronous operations, then waits for both of them after starting each of them to compute her result.

public class Jane : ICook  {      public IMeal Cook()      {          Task<Pasta> pastaTask = PastaCookingOperations.MakePastaAsync();          Task<Sauce> sauceTask = PastaCookingOperations.MakeSauceAsync();          return PastaCookingOperations.Combine(pastaTask.Result, sauceTask.Result);      }  }

As a reminder here, Jane is using the TPL, and she's doing much of her work in parallel, but she's only using a single thread to do her work.

Then we have Servy, who uses Task.Run to create a task that represents doing work in another thread. He starts two different workers, has them each both synchronously do some work, and then waits for both workers to finish.

public class Servy : ICook  {      public IMeal Cook()      {          var bobsWork = Task.Run(() => PastaCookingOperations.MakePasta());          var janesWork = Task.Run(() => PastaCookingOperations.MakeSauce());          return PastaCookingOperations.Combine(bobsWork.Result, janesWork.Result);      }  }

Abstract Class VS Interface in C#

An interface is more supple from the client's perspective:
any class can implement as many interfaces as it wants to. Unfortunately, an interface is more rigid from the developer's perspective: it can't be easily changed and it does not support any kind of reusability.

An abstract class is supple from the developer's perspective:
it supports reusability, it supports encapsulation, it can be extended easily without breaking existing clients.
With all that said, we can conclude the interesting rule of thumb: use abstract classes for building internal APIs and use interfaces for providing external points of extension.

ICommand WPF

<Grid >
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="*"/>
    </Grid.ColumnDefinitions>
    <Button Command="{Binding ClickCommand}" Width="100" Height="100" Content="wefwfwef"/>
</Grid>

public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
        DataContext = new ViewModelBase();
    }
}

public class ViewModelBase
{
    public ViewModelBase()
    {
        _canExecute = true;
    }
    private ICommand _clickCommand;
    public ICommand ClickCommand
    {
        get
        {
            return _clickCommand ?? (_clickCommand = new CommandHandler(() => MyAction(), _canExecute));
        }
    }
    private bool _canExecute;
    public void MyAction()
    {

    }
}
public class CommandHandler : ICommand
{
    private Action _action;
    private bool _canExecute;
    public CommandHandler(Action action, bool canExecute)
    {
        _action = action;
        _canExecute = canExecute;
    }

    public bool CanExecute(object parameter)
    {
        return _canExecute;
    }

    public event EventHandler CanExecuteChanged;

    public void Execute(object parameter)
    {
        _action();
    }
}

Triggers in WPF

There are three types of Triggers available.

• Event Trigger

Event Trigger used perform action when RoutedEvent of FrameworkElement raise.Event Trigger generally used to perform some animation on control (like : colorAnimation, doubleAnumation using KeyFrame etc.)  Let's first understand Storyboard and Animation.

Storyboard Storyboard is used to provide animation to the properties of the UIElement. Storyboard has TargetName andTargetProperty  attached properties for apply animation to the Control (TargetName) and Control Property (TargetProperty).

• Property Trigger 

Property Trigger Executes Collections of Setters, when UIElements property value changes. To create a trigger on any controls, you have to set trigger in style of the control.

MultiTrigger MultiTrigger is used to set action on Multiple Property change. It will execute when all condition are satisfy within MulitTrigger.Condition.

 

• Data Trigger        

 As the name suggest, DataTrigger applies property value to perform action on Data that Binding to the UIElement. DataTrigger allows to set property value when Binding Data matches specified condition.

MultiDataTrigger MultiDataTrigger is same as DataTrigger in addition property value applied on multiple condition is matches.

 

Ref this link for more details

http://www.codeproject.com/Tips/522041/Triggers-in-WPF