Cecil - Getting the defined attributes properties

23 views
Skip to first unread message

Jorge Branco

unread,
Aug 7, 2009, 1:17:09 PM8/7/09
to mono-cecil
Hello. I am using Cecil to try to read my attributes properties:

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false,
Inherited = false)]
public sealed class TraceMethodAttribute : Attribute {
public TraceMethodAttribute() {
MethodStart = true;
MethodReturn = true;
MethodMessages = true;
}

public bool MethodStart { get; set; }
public bool MethodReturn { get; set; }
public bool MethodMessages { get; set; }
}

[TraceMethod(MethodMessages = false)]
static void Main(string[] args) {
}

...

if (attribute.Constructor.DeclaringType.FullName == typeof
(TraceMethodAttribute).FullName) {
if ((bool)attribute.Fields["MethodMessages"] == true) {
EditMethodStart(assembly, method);
}

This is, I'd like this last block of code to check whenever the
attribute applied to Main, for example, has MethodMessages set to true
or false. From what I've seen, it seems like both
attributes.Fields.Count and attributes.Properties.Count is set to 0.
Why is it?

Thanks

Jorge Freitas Branco

unread,
Aug 9, 2009, 7:07:16 AM8/9/09
to mono-cecil
Hello again. From what I've seen here http://evain.net/conf/Cecil-MonoMeeting07.pdf, there seems to really exist a bug in cecil with attributes, as the following code does not work:

// asm is an AssemblyDefinition ...
foreach (CustomAttribute attribute in asm.CustomAttributes) {
Console.WriteLine (
attribute.Constructor.DeclaringType.Name);
foreach (object p in attribute.ConstructorParameters) {
Console.WriteLine (“param: {0}”, p);
}
}
// AssemblyTitleAttribute
// param: Mono.Cecil
// AssemblyDescriptionAttribute
// param: Library for reading and writing CIL images
// ...

attribute.ConstructorParameters.Count seems to be always = 0.

Any help or comment?

Jb Evain

unread,
Aug 9, 2009, 7:09:27 AM8/9/09
to mono-...@googlegroups.com
Hey,

What version of Cecil are you using?
--
Jb Evain <j...@nurv.fr>

Jorge Freitas Branco

unread,
Aug 9, 2009, 7:11:29 AM8/9/09
to mono-...@googlegroups.com
0.6.9.0

Jb Evain

unread,
Aug 9, 2009, 7:18:43 AM8/9/09
to mono-...@googlegroups.com
On 8/9/09, Jorge Freitas Branco <rush.of.d...@gmail.com> wrote:
> attribute.ConstructorParameters.Count seems to be always =
> 0.
>
> Any help or comment?

It depends on whether the attribute can be resolved or not.
What does attribute.Resolved says, and what happens if you call
attribute.Resolve () ?

--
Jb Evain <j...@nurv.fr>

Jorge Freitas Branco

unread,
Aug 9, 2009, 7:21:01 AM8/9/09
to mono-...@googlegroups.com
Attribute.Resolve returns true, but ConstructorParameters.Count seems to be always = 0.

I feel maybe I dont understand well the working of ConstructorParameters. Its length should be the same as the number of properties of the attribute?

Thanks

Jorge Freitas Branco

unread,
Aug 9, 2009, 7:23:18 AM8/9/09
to mono-...@googlegroups.com
Ah! I guess it will return anything different than what are the default properties, right? I see that if I try it with different arguments on the attribute, after doing Resolve(), it'll show up > 1 on Properties.Count.

Jorge Freitas Branco

unread,
Aug 9, 2009, 7:25:26 AM8/9/09
to mono-...@googlegroups.com
Also, what is the expected behaviour of the SaveAssembly() method if we don't actually change anything after loading the assembly? I've checked the checksums of my .exe, both after and before calling SaveAssembly() without having actually changed a thing and they're different. Is this expectable? It seems to be messing up with Visual Studio IDE Debugger, as it points out the wrong exception lines, etc. Maybe I am missnig something? Like in this attributes thing?

Jb Evain

unread,
Aug 9, 2009, 7:26:31 AM8/9/09
to mono-...@googlegroups.com
ConstructorsParameters is a misnamed property which contains the
actual arguments passed to the constructor.

Properties and Fields are dictionaries containing the values passed
to, well, attribute properties and fields, indexed by their name.

So for a class:

FooAttribute : Attribute {

public string Bar;
public string Baz { get; set; }

public FooAttribute (string gazonk) {}
}

And its use:

[Foo ("Gazonk", Bar = "bar", Baz = "baz")]

ConstructorParameters will contain Gazonk.
Fields will contain "Bar" => "bar", and Properties will contain "Baz" => "baz".

That's something that is working, not well for some corner cases, but
sufficiently enough for most cases.

On 8/9/09, Jorge Freitas Branco <rush.of.d...@gmail.com> wrote:
> Attribute.Resolve returns true, but ConstructorParameters.Count seems to be
> always = 0.
>
> I feel maybe I dont understand well the working of ConstructorParameters.
> Its length should be the same as the number of properties of the attribute?
>
> Thanks
>
>
> On Sun, Aug 9, 2009 at 12:18 PM, Jb Evain <j...@nurv.fr> wrote:
> >
> >
> > On 8/9/09, Jorge Freitas Branco
> <rush.of.d...@gmail.com> wrote:
> > > attribute.ConstructorParameters.Count seems to be
> always =
> > > 0.
> > >
> > > Any help or comment?
> >
> > It depends on whether the attribute can be resolved or not.
> > What does attribute.Resolved says, and what happens if you call
> > attribute.Resolve () ?
> >
> > --
> >
> >
> >
> > Jb Evain <j...@nurv.fr>
> >
> >
> >
>
>
> >
>


--
Jb Evain <j...@nurv.fr>

Jb Evain

unread,
Aug 9, 2009, 7:28:29 AM8/9/09
to mono-...@googlegroups.com
On 8/9/09, Jorge Freitas Branco <rush.of.d...@gmail.com> wrote:
> Also, what is the expected behaviour of the SaveAssembly() method if we
> don't actually change anything after loading the assembly? I've checked the
> checksums of my .exe, both after and before calling SaveAssembly() without
> having actually changed a thing and they're different. Is this expectable?
> It seems to be messing up with Visual Studio IDE Debugger, as it points out
> the wrong exception lines, etc. Maybe I am missnig something? Like in this
> attributes thing?

Yes it is expected. Cecil has no way to know if you actually modified
the assembly or not, so it will serialize it again. With possible
changes.

You can ask Cecil to read/write the debug symbols so the debugger
doesn't get confused. Search the group, it's been covered multiple
times.

--
Jb Evain <j...@nurv.fr>

Jorge Freitas Branco

unread,
Aug 9, 2009, 7:29:02 AM8/9/09
to mono-...@googlegroups.com
I'll do that. Attributes now seem to be working. Thanks!

Jorge Freitas Branco

unread,
Aug 9, 2009, 7:47:42 AM8/9/09
to mono-...@googlegroups.com
Ok, everything seems to be fine now with the lines! Thanks again!

JohnC

unread,
Aug 10, 2009, 11:46:52 PM8/10/09
to mono-cecil
>>
That's something that is working, not well for some corner cases, but
sufficiently enough for most cases.
>>

Can you tell an example of a case that fails. I want to reproduce it
and if possible fix it - if indeed its fixable.



On Aug 9, 4:47 pm, Jorge Freitas Branco
<rush.of.delivera...@gmail.com> wrote:
> Ok, everything seems to be fine now with the lines! Thanks again!
>
> On Sun, Aug 9, 2009 at 12:29 PM, Jorge Freitas Branco <
>
> rush.of.delivera...@gmail.com> wrote:
> > I'll do that. Attributes now seem to be working. Thanks!
>
> > On Sun, Aug 9, 2009 at 12:28 PM, Jb Evain <j...@nurv.fr> wrote:
>

Jorge Freitas Branco

unread,
Aug 11, 2009, 12:11:15 AM8/11/09
to mono-...@googlegroups.com
Was that to me? I don't remember having wrote that.

JohnC

unread,
Aug 11, 2009, 12:30:57 AM8/11/09
to mono-cecil
Sorry, no, that was for Jb.


On Aug 11, 9:11 am, Jorge Freitas Branco
<rush.of.delivera...@gmail.com> wrote:
> Was that to me? I don't remember having wrote that.
>
Reply all
Reply to author
Forward
0 new messages