You have a solution looking for a problem, that is why you run into trouble.
A factory method is not an end in itself, it is a means to an end. So you need to start identifying the problem you want to solve first, which means you need a use case for constructing those objects, providing you with the necessary context. Like:
you have an external data source like a file stream or database with object descriptions
you want a factory to create
IShape objects from this data source (so having one and only one place in code to modify in case the list of shapes gets extended)
In the "file stream" context, for example, a
CreateShape factory method could probably get a string as a parameter, containing one object description (maybe some CSV string, a JSON string or an XML snippet), and the requirement would be to parse that string to create the right object:
IShape CreateShape(string shapeDescription)
return new Circle(radius);
return new Triangle(base, height);
Now the parameter list of this method does not look quite so awkward any more, I guess?
Other potential use cases:
You also need to take other, non-functional requirements into account:
do you want your factory to assist in decoupling from that external data source? For example, for unit testing? Then make it not just a method, make it a class with an interface, which can be mocked out.
do you want the factory itself to be a reusable component, following the Open/Closed principle, where the code does not have to be touched even when new shapes should be added? Then you need to build it in a more generic way, either using reflection, generics, the Prototype pattern, or the Strategy pattern.
And yes, for certain use cases you will probably need no factory method at all.
So in short: clarify your requirements first. If you don't know the context for using the factory method, you don't need it yet.