Searching text files for string patterns that are each defined in their own classes
It's very easy: you shouldn't. An interface is used to indicate that a subset of classes present common behaviour or should be considered similar in some way.
In your situation there simply is no reason to make this change because all you do is change a text value in a property, which could just as easily be done by taking an argument in your constructor and keeping a private backing fields which should then be used to populate the property's regex.
This will result in several code optimizations:

No heavy duplication of code in StringType1 and StringType2 (this should have been a red flag)

No reflection necessary to get the different types. Just keep a collection of the different regexes and return a collection of StringType objects, constructed with your regexes.


Additionally, this code will also be obsolete:
public IStringType getNewInstance(string msg)
{
    return (IStringType)(new stringType2(msg));
}

since you should just overwrite that variable with new Stringtype(thisVariable.StringPattern, message).
Ultimately, your code would look something like this:
public class StringType
{
    private IPatternProcessor _processor;
    private string _pattern;
    private string _message { get; set; }

    public StringType(string str, IPatternProcessor processor)
    {
        _message = str;
        _processor = processor;
    }

    public string StringPattern { 
        get { return pattern; } 
        set { pattern = value; } 
    }

    public void Process() {
        _processor.Process(_message);
    }
}    

public static class PatternFactory
{
    private static List&lt;String&gt; _patterns = new List&lt;String&gt;();

    static PatternFactory() {
         _patterns.Add(&quot;(?m)^TEST1.+[\r\n]&quot;;);
         _patterns.Add(&quot;(?m)^BLAH2.+[\r\n]&quot;;);
    }    

    public static List&lt;StringType&gt; GetTypeList()
    {
        return _patterns.Select(x =&gt; new StringType(x));
    }
}

public interface IPatternProcessor { 
    void Process(string input);
}

public class ProcessMethod1 : IPatternProcessor { }
public class ProcessMethod2 : IPatternProcessor { }

If you want to make it easy for your user, you can hardcode these different methods into properties:
public class PatternProcessor {
    public IPatternProcessor ProcessMethod1 { get { return new ProcessMethod1(); } private set; };
    public IPatternProcessor ProcessMethod2 { get { return new ProcessMethod2(); } private set; };
}

Now you can simply call this with
new StringType(input, PatternProcessor.ProcessMethod1).Process();

If you were really into it, you could just cache the IProcessMethod objects in a collection in your PatternProcessor class (provided each method is stateless), but that might be going a little too far out of the scope of this review.
Style notes

Classes are UpperCamelCase (StringType)
Private fields are less standardized but they are often written as _field
Methods and constructors are always capitalized (StringPattern, StringType), just like the class

Conclusion
This code does not benefit from interfaces at all and as such it is impossible to review it since interfaces are the main problem with the code.
Post-edit
So, with the additional requirement of pattern-specific behaviour the introduction of interfaces and separate types now makes a lot more sense. I see two architecture options off the bat:

Separate StringType classes for each situation (if you name them StringType1, StringType2 etc, I'll chase you with a bat)

Separate strategies (strategy pattern) for each type of processing with a sauce of factory pattern


I will go with the second option because it would require less rewriting. Someone else can write the less complex first option but the second option is more flexible in terms of allowing two different patterns to use the same processing option.
I will change the earlier block of code with some additions to keep everything in one place.