I have this code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Text.RegularExpressions;

namespace RegexTest
{
    class Program
    {
        static void Main(string[] args)
        {
            string str = "The quick brown fox.";
            string pat = "fox";
            Regex rgx = new Regex(pat, RegexOptions.IgnoreCase);
            Match matches = rgx.Match(str);

            Console.ReadKey();
        }
    }
}

It compiles and runs without errors.
I have a breakpoint set at Console.ReadKey(), because I wanted to inspect the variable matches.
But I got the strange error message I put in the title of this thread.
The web wasn't clear about what it meant.

So any help is as always greatly appreciated.

Dani AI

Generated

This is a debugger/optimization artifact. As suggested (and confirmed), the local matches was optimized away by the compiler/JIT in the Release configuration, so the debugger reports “the name 'matches' does not exist in the current context.” The C# compiler and JIT can eliminate or move locals (store values in registers, inline calls, etc.) when optimizations are enabled, and those optimized-away locals simply don’t appear to the debugger.

Practical fixes include switching the build to Debug or turning off optimizations for the assembly: Project → Properties → Build → uncheck “Optimize code.” For more detailed debugging symbols in VS2010, open Build → Advanced and set “Debug Info” to Full (or at least pdb-only). Generating PDBs for a Release build helps stack traces but will not always restore optimized-away locals.

When it’s important to keep a value visible in the debugger, ensure the value is actually used in code (the compiler won’t remove it then), or force it to be kept alive. Examples:

Console.WriteLine(matches.Value); // makes the local “used”
GC.KeepAlive(matches);            // prevents the JIT from optimizing the reference away

If debugging an optimized Release build is required, consider disabling optimization for that build and/or copying the value to a field (fields are less likely to be optimized away). Also verify the breakpoint is set while execution is inside the variable’s scope — a breakpoint before declaration or after scope exit gives the same “does not exist” message. ’s observation that VS2013 behaved differently is expected: debugger behavior and defaults vary between VS versions and settings.

Recommended Answers

All 3 Replies

Works fine for me in VS2013 Ultimate running .Net 4.5 console application.

I can access the matches variable and it contains fox as expected... odd.

Make sure you're running it in Debug mode. In Release this could have been optimised away because you're not using the variable.

commented: Great! +15

Forgot to mention I used VS2010 Professional.
: Indeed, forgot I stood in Release mode setting in Debug solved it!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.