Hey David,
I'm thinking about something.
Custom Attributes including types are encoded in the metadata in a brain
dead manner: using strings.
To optimize memory, Cecil will try to round trip custom attributes as a
byte array without decoding how the custom attribute is encoded.
So if you have a
Hi again,
After a little testing it seems that this logic write the desired info at
assembly metadata :
(replacing the one related with custom attributes of previous code-snipped)
ExportedType exportedType = new ExportedType(
typeFo
Hi again,
I have found info about to TypeForwardedToAttribute at module.ExportedTypes
As I have commented previously, after strong-name deletion of the friend
assembly System.Web.Webpages.dll and re-mapping reference from
System.Web.Mvc.dll, TypeForwardedToAttributes at metadata becomes
Mayor source of PEVerify errors seems owing to TypeForwardedTo attribute.
After strong.name deletion all externs forwarded to "System.Web.WebPages"
are transformed into forwards to "System" (that is what ILdasm show us)
From
.class extern forwarder System.Web.Mvc.TagBuilder
{
.assembly ex
Hi Jb,
So far this is the error we are getting:
Unable to load type 'System.Web.WebPages.PreApplicationStartCode' of
assembly 'System, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'.
Info PEVerify over System.Web.Mvc.dll also goes in the same direction, it´s
seems issue c
Removing strong name is usually hard as you have to clean references of the
transitive closure of all assemblies that your program uses.
What error are you getting? That will usually tell you where to start
looking.
Jb
On Fri, Jan 19, 2018 at 7:43 AM, Molowe wrote:
> Hi
>
> I have built an Inj
