Disassemble Linq query
-
Thats because it starts with <>. You gotta remove all of the <> at the beginning of any identifier..dotted or not: <>h__TransparentIdentifier1b.<>h__TransparentIdentifier1a.b.brand_id.Equals(brand_id) should be: h__TransparentIdentifier1b.h__TransparentIdentifier1a.b.brand_id.Equals(brand_id)
I'm sorry, I should have made it clear that I have removed all angle brackets from the code, but the error remains.
"You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"
-
I'm sorry, I should have made it clear that I have removed all angle brackets from the code, but the error remains.
"You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"
What does the error say?
Eslam Afifi
-
What does the error say?
Eslam Afifi
"cannot resolve symbol h__TransparentIdentifier1a"
"You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"
-
Hi All, I have been tasked with recovering some source code from compiled assemblies (all legit, the work was done in-house but the code has gone missing). I've been using reflector, and have disassembled the assemblies. My current issue is that there is a considerable number of linq queries going on, and reflector, excellent tool though it is, seems to have trouble with them. I'm getting output like this:
return (from <>h__TransparentIdentifier1b in from b in context.brands
join p in context.products on b.brand_id equals p.brand_ID \\into p
join pi in context.product_items on p.product_id equals pi.product_id
select new { <>h__TransparentIdentifier1a = <>h__TransparentIdentifier1a, pi = pi }
orderby <>h__TransparentIdentifier1b.pi.display_order
select <>h__TransparentIdentifier1b into <>h__TransparentIdentifier1b
join i in context.image_product_item_links on <>h__TransparentIdentifier1b.pi.product_item_id equals i.product_item_id into i
join ac in context.attribute_colors on <>h__TransparentIdentifier1b.pi.color_attribute_id equals ac.attribute_color_id into ac
where ((<>h__TransparentIdentifier1b.<>h__TransparentIdentifier1a.b.brand_id.Equals(brand_id) && (i.product_item_id == <>h__TransparentIdentifier1b.pi.product_item_id)) && <>h__TransparentIdentifier1b.<>h__TransparentIdentifier1a.p.is_live) && <>h__TransparentIdentifier1b.pi.is_live
select ac)Can anyone give me any hints as to how I would go about reconstituting the original query? Thanks in advance
"You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"
2 things: 1. You'll need to remove all the angle brackets in order for it to compile with a C# compiler. 2. Any compiler-generated classes referenced in this query will need to have their names fixed so that they'll compile in a C# compiler as well. The compiler usually generates classes when you capture local variables in an anonymous method, and also when you use a
yield returniterator. If you have these things, technically it *should* compile. I've seen bugs in Reflector, though, where it doesn't generate valid C# code.Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
2 things: 1. You'll need to remove all the angle brackets in order for it to compile with a C# compiler. 2. Any compiler-generated classes referenced in this query will need to have their names fixed so that they'll compile in a C# compiler as well. The compiler usually generates classes when you capture local variables in an anonymous method, and also when you use a
yield returniterator. If you have these things, technically it *should* compile. I've seen bugs in Reflector, though, where it doesn't generate valid C# code.Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
Judah Himango wrote:
I've seen bugs in Reflector, though, where it doesn't generate valid C# code.
They arn't bugs, it is generating the internal intermediate notation the C# compiler generates when it translates syntactic sugar into something it will compile internally. For example, the fault{} block of a try/catch/fault/finally, is only supported internally by the C# compiler, not in normal code use. The notation where types, functions, and identifiers start with <> is also an internal notation, and is technically valid, just not in normal use. You can see the same identifiers when you use ILDasm.
-
"cannot resolve symbol h__TransparentIdentifier1a"
"You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"
Is there any way you can post the full function from reflector? It seems that h__TransparentIdentifier1a is actually a variable or field or something, beyond the scope of the LINQ query, as is evident here:
select new { <>h__TransparentIdentifier1a = <>h__TransparentIdentifier1a, pi = pi }This creates a new anonymous type who's first property is a reference to some variable called <>h__TransparentIdentifier1a that is not within the scope of the LINQ query...so if it compiled at all, then that identifier must exist somewhere other than the LINQ query. -
"cannot resolve symbol h__TransparentIdentifier1a"
"You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"
Ok, saw it. The eror is because the second h__TransparentIdentifier1a in that line (line 4) is refereing to something defined outside that query. See the code in reflector again. You'll probably see it defined above that query or somewhere else in that class. That's all I can tell. [Edit]I had to step away from the computer for a while and I didn't know that someone already answered that.[/Edit]
Eslam Afifi
-
Ok, saw it. The eror is because the second h__TransparentIdentifier1a in that line (line 4) is refereing to something defined outside that query. See the code in reflector again. You'll probably see it defined above that query or somewhere else in that class. That's all I can tell. [Edit]I had to step away from the computer for a while and I didn't know that someone already answered that.[/Edit]
Eslam Afifi
Thanks to you both, I'll give this a try on Monday. Have a good weekend
"You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"
-
Judah Himango wrote:
I've seen bugs in Reflector, though, where it doesn't generate valid C# code.
They arn't bugs, it is generating the internal intermediate notation the C# compiler generates when it translates syntactic sugar into something it will compile internally. For example, the fault{} block of a try/catch/fault/finally, is only supported internally by the C# compiler, not in normal code use. The notation where types, functions, and identifiers start with <> is also an internal notation, and is technically valid, just not in normal use. You can see the same identifiers when you use ILDasm.
Is that right? You learn something new everyday. Thanks.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Is that right? You learn something new everyday. Thanks.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
Actually, I made a small mistake in my previous comment. What the C# compiler translates your code to isn't specific to itself...its specific to IL. For example, IL supports the fault block in a try/catch statement, but normal C# code does not. Reflector doesn't really have an option when it encounters a fault in IL...so it puts a fault {} block in the C# code it generates.