Re: [mono-cecil] AssemblyNameReference.Parse () and odd paths

118 views
Skip to first unread message

Jonathan Pryor

unread,
Mar 30, 2013, 12:34:14 AM3/30/13
to mono-...@googlegroups.com
On Mar 29, 2013, at 10:14 PM, Alex Rønne Petersen <al...@alexrp.com> wrote:
> The issue is, of course, that the interpretation of the name is ambiguous.

The real issue is one of semantics.

Here's the scenario: You have a path to an assembly ("/Conference/Advanced, Day 1, First Half/Demo Name/bin/Debug/Assembly.dll").

Question: How should you get an AssemblyNameReference from the assembly?

The (broken?) assumption in some parts of our code was that AssemblyNameReference.Parse(path) would Do The Right Thing (for some variation of "right"), but this does not in fact work ("path has commas in it causes things to go kablooie").

I suspect that the "proper" solution is:

AssemblyDefinition def = AssemblyDefinition.ReadAssembly (path);
AssemblyNameReference name = def.Name;

This has the unfortunate requirement that the file needs to be read to determine what the name is, which makes it hard to have a cache of AssemblyNameReferences to avoid opening and reading assemblies... Meaning there's no point in having a cache of AssemblyNameReference > AssemblyDefinition; instead you'd want Path > AssemblyDefinition. And if two different paths have the same AssemblyNameReference (e.g. double reference)...that'll need to be validated/prevented.

- Jon

Alex Rønne Petersen

unread,
Mar 30, 2013, 8:59:03 AM3/30/13
to mono-...@googlegroups.com
Hi,

On Sat, Mar 30, 2013 at 5:34 AM, Jonathan Pryor <jonp...@vt.edu> wrote:
> On Mar 29, 2013, at 10:14 PM, Alex Rønne Petersen <al...@alexrp.com> wrote:
>> The issue is, of course, that the interpretation of the name is ambiguous.
>
> The real issue is one of semantics.
>
> Here's the scenario: You have a path to an assembly ("/Conference/Advanced, Day 1, First Half/Demo Name/bin/Debug/Assembly.dll").
>
> Question: How should you get an AssemblyNameReference from the assembly?
>
> The (broken?) assumption in some parts of our code was that AssemblyNameReference.Parse(path) would Do The Right Thing (for some variation of "right"), but this does not in fact work ("path has commas in it causes things to go kablooie").

Even if we assume that we cannot throw a path at ANR.Parse (), an
assembly name like "Foo, Bar" can still screw things up. So other than
saying "just don't feed paths to it", other rules about what an
assembly name can contain apply.

So the question is: How strict is it supposed to be?

>
> I suspect that the "proper" solution is:
>
> AssemblyDefinition def = AssemblyDefinition.ReadAssembly (path);
> AssemblyNameReference name = def.Name;
>
> This has the unfortunate requirement that the file needs to be read to determine what the name is, which makes it hard to have a cache of AssemblyNameReferences to avoid opening and reading assemblies... Meaning there's no point in having a cache of AssemblyNameReference > AssemblyDefinition; instead you'd want Path > AssemblyDefinition. And if two different paths have the same AssemblyNameReference (e.g. double reference)...that'll need to be validated/prevented.
>
> - Jon
>
> --
> --
> --
> mono-cecil
> ---
> You received this message because you are subscribed to the Google Groups "mono-cecil" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mono-cecil+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Regards,
Alex

Jb Evain

unread,
Mar 30, 2013, 10:50:51 AM3/30/13
to mono-...@googlegroups.com
On Sat, Mar 30, 2013 at 1:59 PM, Alex Rønne Petersen <al...@alexrp.com> wrote:
> Even if we assume that we cannot throw a path at ANR.Parse (), an
> assembly name like "Foo, Bar" can still screw things up. So other than
> saying "just don't feed paths to it", other rules about what an
> assembly name can contain apply.
>
> So the question is: How strict is it supposed to be?

Admittedly, ANR.Parse is a tad naive in its current form.

What's the ecma335 saying in this case?
Also, how does SR.AssemblyName behaves?

Alex Rønne Petersen

unread,
Mar 30, 2013, 12:51:07 PM3/30/13
to mono-...@googlegroups.com
Hi,
It doesn't seem to say much other than the .assembly grammar:

.assembly DottedName ‘{’ AsmDecl* ‘}’

> Also, how does SR.AssemblyName behaves?

csharp> using System.Reflection;
csharp> new AssemblyName ("foo");
foo
csharp> new AssemblyName ("foo, bar");
System.IO.FileLoadException: The assembly name is invalid.
at System.Reflection.AssemblyName..ctor (System.String assemblyName)
[0x00000] in <filename unknown>:0
at Class12.Host (System.Object& $retval) [0x00000] in <filename unknown>:0
at Mono.CSharp.Evaluator.Evaluate (System.String input,
System.Object& result, System.Boolean& result_set) [0x00000] in
<filename unknown>:0
at Mono.CSharpShell.Evaluate (System.String input) [0x00000] in
<filename unknown>:0

I suppose Cecil's behavior is acceptable given the above. It does make
me wonder how any tool or CLI implementation is supposed to behave if
it gets fed a non-DottedName assembly name somehow...
Reply all
Reply to author
Forward
0 new messages