Well, after realizing I could pad things with extraneous whitespace (hex 20) I was able to paste together the IL for two different serialized strong name identity perms to create a dll that ildasm confirmed had to strong name identity permissions applied (demand, not linkdemand). But when I run my app it does not fail in the way that it should given that my setup is app->dll1->dll2, where app doesn't have a strong name at all, and dll1 is one of two dlls that have a public key that dll2 (tweaked) is demanding.
So I don't get the failure that I expect given that my top level assembly (the app) doesn't have a strong name (at all) that matches one of the two my dll2 is demanding. -Mike http://staff.develop.com/woodring http://www.develop.com/devresources ----- Original Message ----- From: "Mike Woodring" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 12, 2002 4:30 PM Subject: Re: [DOTNET] StrongNameIdentityPermissionAttribute with Security. Demand Confus ion > That was the first path I started down, but it turns out not to be that easy > to do. The IL for the attribute ends up looking like this (just the start) > > .permissionset linkcheck = (3C 00 50 ... // <.P.e.r.m. > > for a SecurityAction.LinkDemand (or .permissionset demand for a > SecurityAction.Demand). So I'd have had to work harder that I wanted :-) to > type in the hex representation of an additional serialized permission). > > That's what caused me to just point to an xml file that I built that had the > serialized permission set with two strong name identity permissions in them. > > Another idea to try just occurred to me. Will post back later... > > -Mike > http://staff.develop.com/woodring > http://www.develop.com/devresources > > > BTW did you try dumping your assembly from ILDasm, "fixing" > > the .permissionset value to contain two StrongNameIdentity values, and > > then ilasm it? If it's still there, does the calling code behave as > > expected? > > > > Regards, > > > > Jason > > > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.