My first ever calculator C#
Over all, if this is your first time coding, you've really done a stellar job. I'm having a hard time believing this was a first attempt without replicating someone else's code, just because of how cleanly you've approached it. Very well done.
The below suggestions are more further improvements than they are corrections on what you were doing. Some of the things I suggest may not make full sense now, but are good habits to breed early on, because when you start working on more complex applications, you'll significantly benefit from not having to learn every mistake the hard way.

Avoid repetition
How often do you see this code:
Console.ForegroundColor = /* some color */;
Console.WriteLine(/* some message */);

The answer is a lot. So to save yourself some repeated code, abstract it into a method:
public void WriteMessage(string message, ConsoleColor color = ConsoleColor.White)
{
    Console.ForegroundColor = color;
    Console.WriteLine(message);
}

It seems like a little thing, but it effectively halves amount of lines (revolving around printing logic) in your main method, since you can now just do:
WriteMessage(&quot;error&quot;, ConsoleColor.Red);

Note that I also made the color an optional parameter, so it can be omitted when no special color is needed:
WriteMessage(&quot;a message without special color&quot;);

Syntax improvements
This is just a little thing, but notice how every condition ends with drawing a line:
if (op == &quot;+&quot;)
{
    Console.WriteLine(num1 + num2);
    Console.WriteLine(&quot;--------------------------------&quot;);
}
else if (op == &quot;-&quot;)
{
    Console.WriteLine(num1 - num2);
    Console.WriteLine(&quot;--------------------------------&quot;);
}
// and so on...

If all of them end on the same instruction, it's easier to just put that instruction behind the if/else:
if (op == &quot;+&quot;)
{
    Console.WriteLine(num1 + num2);
}
else if (op == &quot;-&quot;)
{
    Console.WriteLine(num1 - num2);
}
// and so on...        

Console.WriteLine(&quot;--------------------------------&quot;);     

But you can go further. The same applies to printing the result. So you can also move that outside of the chain:
double result = 0;

if (op == &quot;+&quot;)
{
    result = num1 + num2;
}
else if (op == &quot;-&quot;)
{
    result = num1 - num2;
}
// and so on...        

Console.WriteLine(result);   
Console.WriteLine(&quot;--------------------------------&quot;);   

Syntax improvements
You should avoid if else chains where you keep checking if the same variable matches a given value. That's precisely what a switch was made for:
switch(op)
{
    case &quot;+&quot;:
        Console.WriteLine(num1 + num2);
        break;
    case &quot;-&quot;:
        Console.WriteLine(num1 - num2);
        break;
    case &quot;*&quot;:
        Console.WriteLine(num1 * num2);
        break;
    // and so on...
}    

Break it up
The code you wrote is relatively neat for a beginner program. Good indentation, reasonable whitespace separation between lines.
But the next step is breaking your method down into smaller steps. If I were to sum up what this code does, I'd list it as follows:

Takes in a number (twice)
Takes in a mathematical operation
Writes messages to the console, sometimes in color.
Performs the selected operation on the selected numbers

You could add a lot more bullet points here if you wanted, e.g whether you consider drawing a horizontal separator as a different task from writing a message to the console. I'm sticking with these four as it's a basic example.
These four bullet points are a great (but not complete) guideline to how you need to break down your application. Anything you consider a separate task, is generally going to want to be in a method on its own. So in this case you'd be looking at methods like:

double GetNumber()
char GetOperation() - I'd consider using a custom enum here instead of a character, but let's keep it simple for now.
void WriteMessage(string message, ConsoleColor color = ConsoleColor.White) - see previous point section
Separate operator methods:

double Add(double a, double b)
double Subtract(double a, double b)
double Multiply(double a, double b)
double Divide(double a, double b)
double Power(double a, double b) - This mirrors Math.Pow and you could technically skip your own method and use Math.Pow directly. However, due to abstraction considerations, it's good practice to still define your own method. This is maybe beyond your current skill level, but the idea behind it is that if you suppose that you change your calculation logic in the future, it's easier to rewrite the content of your Power method once, than it is to go hunt for all references to Math.Pow and substitute them all individually.



There's definitely still room for improvement, but you're still a beginner and this is a good first step. Try to write the code in your Main method in a way that it relies on these methods I just listed, instead of having the Main menu do all the heavy lifting by itself.
Think of it this way: when you stop being a cook and instead become a chef (= better code), then you're no longer doing the small jobs yourself, e.g. peeling the potatoes and washing the dishes. Tasks get delegated. Chefs (the Main method) rely on the small things being done by others (the submethods).
Refactoring
I noticed this:
Console.WriteLine(&quot;{0}&quot;, value1);

It's needlessly complex. Just do:
Console.WriteLine(value1);

I suspect that this is a refactoring remnant. It used to do more than just print value1, but over time you changed the code, and never steered away from using the String.Format approach.
That's completely normal, but this is precisely why developers should always revisit code when it's &quot;finished&quot;, to see if there are some remnants of past attempts that can be cleaned up or refactored into something better.
A better user experience
It helps to sometimes think like a user instead of like a developer. When adding 1 and 2 together, how do we write things?

+ 1 2
1 + 2
1 2 +

I hope you'll agree that the second bullet point is vastly preferred. Note that the first bullet point also exists (it's called Polish notation), but unless you have reason to believe that your users predominantly use Polish notation, the second bullet point is how users think.
But when you ask for user input, you are asking for + 1 2:
Console.Write(&quot;Enter operator: &quot;);
string op = (Console.ReadLine());
       
Console.Write(&quot;Enter First Number: &quot;);
double num1 = Convert.ToDouble(Console.ReadLine());
      
Console.Write(&quot;Enter Second Number: &quot;);
double num2 = Convert.ToDouble(Console.ReadLine()); 

That doesn't match with how users think. It's a very simple improvement to just change the order of your code. It doesn't change how your code works, but it does improve the user experience.
An even better user experience
This is not as simple, but as a next challenge, you could see if you could move away from users having to input separate values and having to press enter inbetween.
See if you can figure out how to let users input the whole formula, e.g. &quot;1+2&quot; and take it from there. Or, alternatively, read every key the user presses and dynamically figure out what they mean.
If you think about a real-world calculator, it works without needing to press enter inbetween its data input. So try and make yours similar. It's a great user experience improvement, and a good exercise for someone who's new to coding.