We Keep Coding

Can I create a generic method in c# that accepts a type based on whether it contains a certain method or not?

I want to create a generic method that takes any class that implements a certain method, for example Print(), usually in such a case we need a common interface and then I would say something like : where T : ICustomInterface and the compiler would guarantee that type T contains any methods in that interface. However, in cases where I do not have access to the type, for example I can not modify the List class part of the System.Collections.Generic namespace to implement my interface, can you still achieve this functionality?

However, in cases where I do not have access to the type, for example I can not modify the List class part of the System.Collections.Generic namespace to implement my interface, can you still achieve this functionality?
Try this first:
public class customList<T> : List<T> where T : ICustomInterface{
}
According to SharpLab, it valid code. But you need proper compiler confirmation.
If it does not work, there is the MVVM way: "If you can not modify it, wrap it into something you can modify." Just put a List<T> inside of a custom class as private field and add all the List Functions you want, by simply relaying thhe cals it to the List<T> inside.
Edit:
I wanted to create a generic class that takes anything that implements an indexer, and then have a generic "Peek" method (look forward in a list, array, or anything that contains an indexer) based on the current state of this class etc
Unfortunately, "having a Indexer" is not something Generics can test. In .NET every class can be given a Indexer, as much as it can be given Functions, Fields and Properties.
Reflection can Identify Indexers. I only ever consider Reflection as a fallback, but it is one way.
Despite the checking limits of generics, you can define Indexers in a Interface, as much as you could Functions and Properties. At the end of the day, Indexers are propably mostly Syntax sugar for Function calls like properties are. While doing so would at a first glance exclude the Build-in List types, it is easy enough to sublcass them and have them implement the Interface.

Without being able to add an interface this is going to be pretty hard to accomplish is a type friendly manner. I don't know the usefulness of this, but it could be done:
public void Print(object myObj) {
var method = myObj.GetType().GetMethod("Print");
if (method != null) method.Invoke(this, null);
}

Can’t do what you’re asking exactly. But you could write a wrapper class that allows you to set a delegate for the required method, and use the wrapper in the type constraint.
class Printable
{
protected readonly Action _action;
public Printable(Action printAction)
{
_action = printAction;
}
public void Print()
{
_action();
}
}
void CallPrint<T>(T obj) where T : Printable
{
obj.Print();
}
var wrapper = new Printable( ()=> foo.Print() );
CallPrint(wrapper)(
You could do a similar thing for classes that have indexers, although you would use a Func instead of an Action.

Better Solution to find all classes which inherit from a baseclass (and interface) and return a list not List<System.Type> but List<Interface>

Maybe my brain is not working properly and i cant see the forest because of the trees ...
Currently I have a class called CheckManager which searches the current assembly for a certain type called UserControlBaseCheck which is declared in a separate library. (this works fine)
I do have a variable AllChecks of type SortedDictionary<IBaseCheck, UserControlBaseCheck> (and a custom IComparer class which know's how to sort IBaseCheck).
This variable AllChecks is used to populate a Stack. The stack is then worked through by a User, once it is depleted, it get's filled again with new instances of all classes inside the AllChecks variable. And the whole game starts again.
Currently i solved it this way:
//declaration of my container with all checks
private static SortedDictionary<IBaseCheck, UserControlBaseCheck> AllChecks =
new SortedDictionary<IBaseCheck, UserControlBaseCheck>(new Comparer());
// this is how i call the method to find all classes which inherit from the type
FindDerivedTypes(Assembly.GetExecutingAssembly(), typeof(UserControlBaseCheck));
//this is the definition... it seems to me bit odd that I have to use the Activator
//and create an instance and cast it to the interface just to do
//what i want to do...
//is there any other / easier / better way of doing so?
public static IList<IBaseCheck> FindDerivedTypes(Assembly assembly,Type baseType)
{
//FYI: until the '.Select' I get a list of type List<System.Type>
List<IBaseCheck> o = assembly.GetTypes()
.Where(t => t != baseType && baseType.IsAssignableFrom(t))
.Select(type => Activator.CreateInstance(type) as IBaseCheck)
.ToList();
return o;
}
i find it odd that I have to create first an instance of the type just to use/convert it to an interface. Why can't i just do: .Select(x=> x as IBaseCheck) I mean i have already a list with object of type List<System.Type> and it seems to me bit overkill what i am doing just to get my list of type IBaseCheck (List<IBaseCheck>)

Why can't I just do: .Select(x=> x as IBaseCheck)
Because x is an instance of the System.Type type, not your UserControlBaseCheck type.
It's important to understand that, when you use reflection, you are getting the metadata for the types. I.e. you are getting data that describes your types, not the types themselves. The System.Type type is one such kind of data. It is a runtime object that describes the types you declare. It is not those actual types, and it's definitely not an instance of those types.
Consider the trivial code example:
namespace ExampleNamespace
{
class A { }
}
There are many different ways of getting the System.Type that represents that type:
Type type1 = Assembly.GetType("ExampleNamespace.A"),
type2 = typeof(A),
type3 = (new A()).GetType();
But note that in the above, all three variables wind up with the same instance of System.Type. I.e. the instance that describes that type A.
Note also in the last assignment, to the variable type3, a new instance of A is being created. I.e. you can ask an instance for the information about its own type. But what's returned is not, of course, that instance. It's something completely different: the instance of System.Type describing the type of that instance of A.
So back to your example…
You're using reflection to search for instances of specific System.Type objects. These instances give you enough information to figure out which ones implement some base class (or even an interface, if you wanted). But since you want an actual instance of that class, you need to explicitly ask for one.
Just as you can't do this:
A a = typeof(A);
You also can't do this:
IBaseCheck baseCheck = typeof(UserControlBaseCheck);
Instead, you need to do this:
IBaseCheck baseCheck = new UserControlBaseCheck();
And the way that's done via reflection (well, one way anyway) is to call the Activator.CreateInstance() method.

Is it possible to make an anonymous class inherit another class?

This is a long shot, but I have a funny coding situation where I want the ability to create anonymous classes on the fly, yet be able to pass them as a parameter to a method that is expecting an interface or subclass. In other words, I'd like to be able to do something like this:
public class MyBase { ... }
public void Foo(MyBase something)
{
...
}
...
var q = db.SomeTable.Select(t =>
new : MyBase // yeah, I know I can't do this...
{
t.Field1,
t.Field2,
});
foreach (var item in q)
Foo(item);
Is there any way to do this other than using a named class?

No. Anonymous types always implicitly derive from object, and never implement any interfaces.
From section 7.6.10.6 of the C# 5 specificiation:
An anonymous object initializer declares an anonymous type and returns an instance of that type. An anonymous type is a nameless class type that inherits directly from object.
So if you want a different base class or you want to implement an interface, you need a named type.

No. From the documentation:
Anonymous types are class types that derive directly from object, and that cannot be cast to any type except object.
To solve your problem, just replace the anonymous type with normal class...

Cannot extend an anonymous but you could declare your method to accept a dynamic parameter if you really need this to work.

Short answer: no
Long answer:
You could use a C# proxy class. There are several tools that can proxy classes. For example Moqs. https://github.com/moq/moq4

Creating objects of different Types using a unified Signature

Imagine the following two classes:
class A
{
public A()
{
}
}
class B : A
{
public B()
{
}
}
Is it possible for me to define A, or alternatively an interface, in a way that forces class B to have a parameterless constructor? Or, more generalized, a constructor (or static method) that is able to create an instance of type B with a given signature?
I do not want to restrict class B to only be constructible using that signature, but I want to be sure that class B can be constructed with this signature (be it parameterless, or specifying certain parameters).
To be clear: I am not searching for a solution that would require me to use Reflection or any other method to figure that out at runtime (I don't have a problem with it, but it would make the code less readable, and generally seems like a bad idea in this case).
Is there a way to accomplish this?
I wrote a blog post that goes more in-depth about what I am trying to achieve here

There is no interface or base type that you can apply to the type to ensure it has a parameterless constructor. The only context in which you can make such a contraint is generic constraints:
public static void Foo<T>()
where T : new() {}
In such a case the only types that can be used with Foo must have a parameterless constructor.

You can define factory for instantiating objects of type A (and derived types):
interface IFactory<T> where T : A
{
T Create(int i);
T Create(string s);
// and so on...
}
and require factory implementation, when you want to create an object.
This will make sure calling code in compile time, that it tries to create an object with the given set of parameters.
Of course, there's nothing preventing from NotImplementedException from concrete IFactory<T> implementation at run-time.

This is a followup, since I did a little bit of research and at least managed to come up with an answer that is somewhat satisfying.
So after digging around a while and trying to figure out how the built-in serialization/deserialization in C# works, I found out that C# has a method called GetUninitializedObject(). This method seems like a hack, since it just avoids calling the constructor of the object in the first place, but it at least gives me a way to accomplish what I originally wanted: Being able to deserialize an object of an arbitrary type. Using this, I am able to use methods on the uninitialized created objects (and forcing their implementation via an interface).
I find this to be fitting my needs, although it does not do what I originally wanted to, it allows me to implement a pattern that works for my purposes.
Best Regards

instantiation and interface

I'm used to instantiate object as following:
type obj-name = new type();
and now I'm using
IList<string> str_element = new List<string>();
I was expecting to see something
IList<string> actors = new IList<string>();
can somebody give me some ideas why for interface instantiation is different here?
Thanks,
Amit

An interface is just that — an interface, or a specification of what methods should exist.
An interface does not contain any actual code.
Interfaces can only be used as types that hold concrete classes.
It doesn't make sense to create an instance of an interface, since there is nothing to instantiate.

The reason you can't do = new IList<string>() is because IList<T> is an interface and you can't initialize interfaces as there is no body of code to call. I would reccomend doing
List<string> actors = new List<string>()
instead.

Interfaces define a contract, or set of functionality, that implementing classes must provide (at a minimum). By defining a variable of type IList<T>, you are really saying, "I don't care what the actual implementation is, it just needs to provide that functionality." This means you are divorcing the 'interface' and the 'implementation' in your calling code, which is a good thing.
The real power of interfaces is where you have pluggable code. If you were defining a library, rather than returning a List<T> instance, you could return an IList<T> instance (which AFAIK, is what the LINQ functionality does). This allows you to change the internal implementation of the object returned (it might be a linked list, or a B-Tree, or whatever), and calling code doesn't need to change.
Alot of the mocking libraries out there (e.g. NMock, Moq, etc) take advantage of interfaces and can generate implementing classes for testing purposes.

You can use LINQ: for example
This will give you something of a more Concrete Type.
using System.Linq;
IList<Foo> list = new List<Foo>();
IEnumerable<Foo> sortedEnum = list.OrderBy(f=>f.Bar);
IList<Foo> sortedList = sortedEnum.ToList()