Re: SecurityElement serialization/deserialization/version

From: Developer (lf_at_nospam.nospam)
Date: 08/06/04

  • Next message: Developer: "Re: SecurityElement serialization/deserialization/version" 
    Date: Thu, 5 Aug 2004 20:04:51 -0400

    This is what I hoped CLR will do. I only need to worry about permissions
    that come with CLR, no custom ones.

    In my mind this is similar to how CLR works when it loads an assemby that
    was built against 1.1, but only 2.0 is available on the client. CLR will
    auto redirect the bindings to 2.0

    Thank you for explaining this.

    ""Shawn Farkas"" <shawnfa@online.microsoft.com> wrote in message
    news:8p%23JFYzeEHA.1576@cpmsftngxa06.phx.gbl...
    > Good question,
    >
    > The answer has to do with something called unification. The main portion
    of the CLR is located in mscorwks.dll. mscorwks is very tightly
    > bound to the mscorlib.dll that is built with, due to many "special"
    classes like System.Object, System.String, etc. Since you can only have one
    CLR
    > in your process, you can also only have one mscorlib. What the CLR does
    when it sees an attempt to load a class from a version of mscorlib that
    > differs only by version, it will load that class from the version of
    mscorlib that it was built with. In your example, version 1.0.5000
    corresponds to
    > version 1.1 of the CLR. If you try to load this in version 2.0 of the CLR
    (where the version number will look like 2.0.3600), the CLR will see that
    > request, and go get you the v2.0 class.
    >
    > If you're more interested in seeing this fail, try it with a custom
    permission that you write and install into the GAC. If you change the
    version
    > there, the CLR won't unify your assemblies, and you'll get an exception.
    >
    > -Shawn
    > http://blogs.msdn.com/shawnfa
    >
    > --
    >
    > This posting is provided "AS IS" with no warranties, and confers no
    rights.
    > Note: For the benefit of the community-at-large, all responses to this
    message are best directed to the newsgroup/thread from which they
    > originated.
    > --------------------
    > >Reply-To: "Developer" <lf@nospam.nospam>
    > >From: "Developer" <lf@nospam.nospam>
    > >Subject: SecurityElement serialization/deserialization/version
    > >Date: Wed, 4 Aug 2004 07:46:30 -0400
    > >Lines: 20
    > >X-Priority: 3
    > >X-MSMail-Priority: Normal
    > >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
    > >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
    > >Message-ID: <eVkDziheEHA.3840@TK2MSFTNGP10.phx.gbl>
    > >Newsgroups: microsoft.public.dotnet.security
    > >NNTP-Posting-Host: h-67-101-130-235.nycmny83.dynamic.covad.net
    67.101.130.235
    > >Path:
    cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10
    .phx.gbl
    > >Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.security:7037
    > >X-Tomcat-NG: microsoft.public.dotnet.security
    > >
    > >Hi,
    > >
    > >If one serializes the SecurityElement using:
    > >http://blogs.msdn.com/shawnfa/archive/2004/02/24/79598.aspx
    > >or in any other way, most of the elements will have version, such as:
    > >
    > ><SecurityClass Name="UIPermission"
    > >Description="System.Security.Permissions.UIPermission, mscorlib,
    > >Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
    > >
    > >The fact that it has version, will it prevent this serialized form from
    > >working with some later versions?
    > >I tried specifying invalid version, and it doesn't break anything. I can
    > >deserialize and apply the policy without exceptions.
    > >
    > >Thanks in advance for any help on this
    > >
    > >
    > >
    > >
    > >
    >
    >

  • Next message: Developer: "Re: SecurityElement serialization/deserialization/version"

    Relevant Pages

    • RE: Spreadsheet defaults to Read Only for ONE user...
      ... Thanks CLR - I've re-logged the complete issue with our IT (our MIS basically ... The user in question just tried logging in to someone else's pc (who can use ... Now, we thought this was a permissions thing for the folder, which was ...
      (microsoft.public.excel.misc)
    • RE: SecurityElement serialization/deserialization/version
      ... Since you can only have one CLR ... you can also only have one mscorlib. ... it will load that class from the version of mscorlib that it was built with. ... >Subject: SecurityElement serialization/deserialization/version ...
      (microsoft.public.dotnet.security)
    • Re: ODBC Connection with SQL Managed Provider
      ... more slower than running from local computer. ... Because the CLR is checking ... for permissions for security reasons. ...
      (microsoft.public.dotnet.framework.adonet)
    • Re: Caspol
      ... Code can't give itself more permissions than it deserves (as prescribed by ... the CLR and policy). ... Christian ...
      (microsoft.public.dotnet.general)
    • Quantcast