Renaming typedefs using the unmanaged reflection API (is it possib
Messages   Related Types
This message was discovered on microsoft.public.dotnet.framework.clr.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.
Post a new message to this list...

Nadav (VIP)
Hi,

I am using the unmanaged reflection API ( e.g. IMetaDataImport,
IMetaDataEmit, … ) and I wonder…. I couldn’t find a way renaming a
Field/Method name… How could I do that? Concerning fields, I have tried to
delete the filed and re-create the field with a different name; however the
runtime doesn’t recognize the new field upon execution… How can I rename a
method/field name??? is it possible through the un-managed API or should I
rather access the metadata memory directly????

--
Nadav
http://www.ddevel.com
Reply to this message...
 
    
Ben Schwehn
[Original message clipped]

don't think it's possible in an easy way

[Original message clipped]

problematic since then you would also have to update all references to
the new token. (the 'deleted' field doesn't really get deleted but just
renamed and it keeps its token value, a new field will have a different
token value)

[Original message clipped]

also not trivial. It's trivial as long as the new name isn't longer,
however if it is you'll have to shift all following things in the
#strings section and update all references to those strings in the
assembly. if the section gets too big you might even have to update the
header to use 4bytes indices instead of 2bytes ones.

The most reliable way i've found is to create a new assembly from
scratch. which is also very painful if you get to more complicated
assemblies.

--
Ben
http://bschwehn.de
Reply to this message...
 
    
Nadav (VIP)
Hi Ben,

Thanks for your responce, Wouldn't Assembly re-writing require manipulation
to all of the exisiting IL code? A new method created in a new assembly will
have a new token ID ( different form the one associated with the method in
the original assembly ), I assume this token is being reffered to by the IL
code ( concerning the function is called internally by some other
implementation ), taking that in mind, reconstructing an assembly would
require all of the IL code to be passed through, 'old' token ids would have
to be replaces by the new tokens, is my assumption is true? isn't it an
overkill?

Nadav
http://www.ddevel.com

"Ben Schwehn" wrote:

[Original message clipped]

Reply to this message...
 
    
Ben Schwehn
[Original message clipped]

if you call the metadata emit functions in the right order they will get
asssigned the same token. I've successfully reasssembled big modules
like system.data.dll... as long as there isn't any native code it works
rather well.

[Original message clipped]

not as long as there isn't an easier way :) perhaps there is one though...?

You could always do a ildasm/dasm roundtrip if you don't need to do it
programatically.

--
Ben
http://bschwehn.de
Reply to this message...
 
 




Ad
MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT
 
 Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com