Hi Jb - seems I'm running into the same issue with Cecil 0.9.4. The
DeclaringType on a TypeReference for a nested class is set to null
whenever generics are involved. Here's a test case:

public class OuterGeneric<O>
{
    public class InnerGeneric<I>
    {
    }

    public class InnerNonGeneric
    {
    }
}

public class OuterNonGeneric
{
    public class InnerGeneric<I>
    {
    }

    public class InnerNonGeneric
    {
    }
}

class TestClass
{
    public OuterGeneric<int>.InnerGeneric<int> Method1()
    {
        return null;
    }

    public OuterGeneric<int>.InnerNonGeneric Method2()
    {
        return null;
    }

    public OuterNonGeneric.InnerGeneric<int> Method3()
    {
        return null;
    }

    public OuterNonGeneric.InnerNonGeneric Method4()
    {
        return null;
    }
}

In the example above, only Method4 has a value in its return type's
DeclaringType. The other three are set to null. Bug?

Thanks!!
Roman


On Sep 15, 11:13 pm, Jb Evain <[email protected]> wrote:
> Hey,
>
> On Thu, Sep 16, 2010 at 2:26 AM, Alois Kraus <[email protected]> 
> wrote:
> > I just wanted to check if this a bug with Cecil 0.6 which has been
> > fixed with 0.9 or if this is by design. When I have a TypeReference to
> > a nested class it has the IsNested property set to false although in
> > its TypeDefinition it is set to true. Why is this?
>
> I don't know man, I don't know.
>
> It could very well be a bug!
>
> If you have a TypeRereference which represents a nested type, 
> itsDeclaringTypeproperty should point to, well, its declaring type you
> know. Thing is that, IsNested is implemented as:
>
> public bool IsNested {
>     get { return this.DeclaringType!=null; }
>
> }
>
> So if IsNested returns false, there must be something weird!
>
> In other words, I need a test-case.
>
> > How can I find out to which exact TypeDefinition is referred to
> > without actually resolving the TypeReference into a TypeDefinition?
>
> I'll have to admit that I'm not exactly sure what you're asking here.
>
> > I ask without because I do not want to load the dependant assemblies
> > for memory/perf reasons into memory.
>
> Sure thing!
>
> --
> Jb Evain  <[email protected]>

-- 
--
mono-cecil

Reply via email to