Best way to do this generic abstract class in c#?

I'm trying to be as generic and abstract as possible, otherwise my code is going to get real messy.

this is a misconception. being generic/abstract can actually complicate an otherwise simple problem. The key to clean code is encapsulation. much different that inheritance or generics.

In this case I think composition would be a better choice, rather than inheritance. with a set of adaptors you could have a common object that each entity could be adpated to. for example:

interface ICommon { ... }

class AskAdaptor: ICommon
{
    private readonly Ask ask;
    publick AskAdaptor(Ask ask)
    {
        this.ask = ask;
    }
}

class AskAdaptor: ICommon
{
    private readonly Blog blog;
    publick AskAdaptor(Blog blog)
    {
        this.blog = blog;
    }
}

class AskAdaptor: ICommon
{
    private readonly Resource resource;
    publick AskAdaptor(Resource resource)
    {
        this.resource = resource;
    }
}

class CommonAggregate
{
    public void Add(ICommon common)
    {
         ....
    }
}

I'm not sure I understand what you are trying to achieve but perhaps it's something like this

public static class AbstractAggregateFactory
{
    public static AbstractAggregate<T> GetAggregateClient<T>()
    {
        if(T is AskItem) return new AskTankTruckAggregate();
        if(T is BlogItem) return new TankTruckBlogAggregate();
        if(T is ResourceItem) return new ResourcesAggregate();
    }
}

public abstract class AbstractAggregate<T>
{
    public abstract List<T> GetAggregate(Guid[] resourcetypes);

    public abstract T GetSingle(string friendlyname);
}

public class AskTankTruckAggregate : AbstractAggregate<AskItem>
{
    //not implemented yet
}

public class TankTruckBlogAggregate : AbstractAggregate<BlogItem>
{
    //not implemented yet
}

public class ResourcesAggregate : AbstractAggregate<ResourceItem>
{
    //not implemented yet
}

How about this:

public static class AggregateHelper
{
    public enum AggregateTypes { TankTruckBlog, AskTankTruck, Resources }
}

public class AskItem { }
public class BlogItem { }
public class ResourceItem { }

public static class AbstractAggregateFactory
{
    public static AbstractAggregate<T> GetAggregateClient<T>
       (AggregateHelper.AggregateTypes type)
    {
        switch (type)
        {
            case AggregateHelper.AggregateTypes.AskTankTruck:
                return new AskTankTruckAggregate<T>();
            case AggregateHelper.AggregateTypes.TankTruckBlog:
                return new TankTruckBlogAggregate<T>();
            case AggregateHelper.AggregateTypes.Resources:
                return new ResourcesAggregate<T>();
            default:
                throw new ArgumentException();
        }
    }
}

public abstract class AbstractAggregate<T>
{
    public abstract List<T> GetAggregate(Guid[] resourcetypes);
    public abstract T GetSingle(string friendlyname);
}

public class AskTankTruckAggregate<T> : AbstractAggregate<T>
{
    public override List<T> GetAggregate(Guid[] resourcetypes)
    {
        throw new NotImplementedException();
    }

    public override T GetSingle(string friendlyname)
    {
        Console.WriteLine(friendlyname);
        Type whats_t = typeof(T);
        return default(T);
    }
}

public class TankTruckBlogAggregate<T> : AbstractAggregate<T>
{
    //not implemented yet
}

public class ResourcesAggregate<T> : AbstractAggregate<T>
{
    //not implemented yet
}

Example:

AbstractAggregate<BlogItem> foo3 = 
   AbstractAggregateFactory.GetAggregateClient<BlogItem>(AggregateHelper.AggregateTypes.AskTankTruck);
foo3.GetSingle("test");

The problem the compiler complains about is that you have a method which is 'open' (T) - and you're returning closed generic (with <AskItem> etc.), concrete type really.
i.e. you have to return a <T> - and you can do that with the method - no matter if the factory is not generic, the method still can be.

As for what's the best way to do it, that's more of a design question, and a bit longer story. I'm not entirely sure what you're trying to achieve (maybe some background story, how many types you might have etc.)

First, your items shouldn't (generally speaking, as a best practice or some 'feels good' factor) inherit from ListItem. Use some other base class of yours, and if you need a collection, use a generic one like List<T>, or create your own IList implementation, etc.

Second, you don't need to make everything generic. Your base aggregator is generic but custom classes are not, usually. For example:

abstract class ItemBase  { }
class AskItem : ItemBase { }
class BlogItem : ItemBase { }
class ProvderA : ProviderBase<AskItem>
{
    public override AskItem Get()
    {
        throw new NotImplementedException();
    }
}
class ProvderB : ProviderBase<BlogItem>
{
    public override BlogItem Get()
    {
        throw new NotImplementedException();
    }
}
abstract class ProviderBase<T> where T : ItemBase
{
    public abstract T Get();
}

class Program
{
    static void Main(string[] args)
    {
        ProviderBase<AskItem> provider = GetProvider<AskItem>();
        var item = provider.Get();
    }
    static ProviderBase<T> GetProvider<T>() where T : ItemBase
    {
        if (typeof(T) == typeof(AskItem))
            return (ProviderBase<T>)(object)new ProvderA();
        if (typeof(T) == typeof(BlogItem))
            return (ProviderBase<T>)(object)new ProvderB();
        return null;
    }
}

...that's one implementation.

Basically, making everything 'generic' is not always the best way. You have to have enough reasons or 'types' unknown to be possibly used. As with generic you also pay a certain price. Crossing generics to non-generics world is often tricky, and involves reflection if your types can't be inferred by the usage etc.

In my opinion, it's a mistake making each provider generic (<T>), as it only accepts one type (each concrete), while base is generic. So like the above. Usually generic is also constrained per interface where/where you can.

But then you have a problem, as casting back to generic context from effectively a non-generic class is not straight (also have in mind there are caveats with value types as you often have to treat that differently), and vice versa as well.

Hence you need something like cast (object) first.

I'd rather use sort of an IOC approach here - e.g. look at the autofac (I'm not associated but I like how it works, nice framework). In that case you'd do something like this:

container.Register<ProviderBase<AskItem>>(c=> new ProvderA());
container.Register<ProviderBase<BlogItem>>(c => new ProvderB());

// and query later...

ProviderBase<AskItem> provider = container.Resolve<ProviderBase<AskItem>>();

Hope this helps some.