---- Reported by marek.safar@seznam.cz 2004-08-10 18:24:17 MST ----

Please fill in this template when reporting a bug, unless you know what you
are doing.
Description of Problem:

TypeBuilder.AddDeclarativeSecurity doesn't work as expected. When I call
this method no security data are generated/saves in contrast to
MethodBuilder.AddDeclarativeSecurity which works.

If you need more info let me know.



---- Additional Comments From sebastien@ximian.com 2004-09-16 11:30:02 MST ----

Marek,

This seems to work for me (using your MCS patch). I added a CWL in
TypeBuilder.AddDeclarativeSecurity and got this output. Source code
for decl_all.cs and the monodis (requires patch in #66035 - or use MS
ildasm) are attached.

# mcs decl_all.cs
TypeBuilder LinkDemandStruct - <PermissionSet
class="System.Security.PermissionSet"
               version="1">
   <IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
                version="1"
                Flags="ControlPrincipal"/>
</PermissionSet>
 
TypeBuilder Program - <PermissionSet class="System.Security.PermissionSet"
               version="1">
   <IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
                version="1"
                Flags="ControlAppDomain"/>
</PermissionSet>

Do you have a non working example ?

Oh, BTW the assembly permissions do not show up in the assembly
metadata (I'm looking into this now).




---- Additional Comments From sebastien@ximian.com 2004-09-16 11:30:44 MST ----

Created an attachment (id=166614)
decl_all.cs




---- Additional Comments From sebastien@ximian.com 2004-09-16 11:31:05 MST ----

Created an attachment (id=166615)
decl_all.il




---- Additional Comments From sebastien@ximian.com 2004-09-16 11:33:44 MST ----

Created an attachment (id=166616)
good_decl_all.il




---- Additional Comments From sebastien@ximian.com 2004-09-16 11:36:31 MST ----

Disregard decl_all.il (wrong command output).

Also note that security permission aren't encoded properly on properties.

        .custom instance void class
[mscorlib]System.Security.Permissions.SecurityPermissionAttribute::.ctor(valuetype
[mscorlib]System.Security.Permissions.SecurityAction) =  (
		01 00 05 00 00 00 01 00 54 02 0F 43 6F 6E 74 72   // ........T..Contr
		6F 6C 45 76 69 64 65 6E 63 65 01                ) // olEvidence.





---- Additional Comments From sebastien@ximian.com 2004-09-16 21:41:42 MST ----

Subtle problem here. While MCS/monodis output the expected
informations, MS ildasm doesn't. 

That explains why I got the "right" results using Mono while you had
problems using Windows.

I'll try to do more tests tomorrow - mixing MCS/CSC,
monodis/ildasm.With a little chance this is a very basic (bad
constant) encoding problem (as MS PEVerify doesn't flag any error on
the compiled assembly).



---- Additional Comments From sebastien@ximian.com 2004-09-16 21:44:59 MST ----

Oops forget to say that the assembly-level attributes have the same
problem.



---- Additional Comments From sebastien@ximian.com 2004-09-17 16:57:33 MST ----

The problem is more random than I thought. 

* All kind of permissions always work with Mono.

* On MS runtime they seems to work only in certain conditions - so it
is possible to have (or not) security attributes on
assembly/type/method but mixing them gets mixed results.



---- Additional Comments From sebastien@ximian.com 2004-09-17 17:41:42 MST ----

Hmmm... from a few more tests it looks like the ordering could be
important. Which would means assembly security attributes should be
first (which normally would be the case using AssemblyBuilder) except
that MCS has a "hack" to do this later (design issue). 

Anyway more tests another day.



---- Additional Comments From sebastien@ximian.com 2004-09-20 09:45:20 MST ----

100% sure: CSC (well MS S.R.E) always encode the token with acsending
numbers.
100% sure: MCS (well Mono S.R.E.) encode the token in the order they
are added (e.g. assemblies always get last with token 1).
98% sure: All results I have indicates that MS runtime stop looking
decl attributes when the next token < current token.

Partition II, section 21.11 doesn't list ordering as important
(warning or error) but maybe this is discuted elsewhere in a more
general section ?



---- Additional Comments From sebastien@ximian.com 2004-09-20 12:26:44 MST ----

Created an attachment
https://bugzilla.novell.com/show_bug.cgi?id=MONO62829.patch




---- Additional Comments From sebastien@ximian.com 2004-09-20 12:28:42 MST ----

Some tables were sorted - but not the declarative security one.

Adding the sort fixed the issue. Now the MS runtime "sees" all the
security attributes (using ildasm or permview). monodis also show that
the attributes are now sorted in ascending order (token).




---- Additional Comments From sebastien@ximian.com 2004-09-20 12:29:39 MST ----

Moving as the patch is in reflection.c (runtime).



---- Additional Comments From vargaz@freemail.hu 2004-09-20 12:52:55 MST ----

This is ok to check in but please add a comment about why this sorting
is neccessary.



---- Additional Comments From sebastien@ximian.com 2004-09-20 13:44:00 MST ----

Fixed in CVS.

Imported an attachment (id=166614)
Imported an attachment (id=166615)
Imported an attachment (id=166616)
Imported an attachment (id=166617)