| Groups | Blog | Home |
dotnet security : Failed to Load WSE 2.0 Add-in into VS.NET (CAS-problem)
to right-click a project and use the dialog from "WSE Settings...". =20 However - once I change the PermissionSet (CAS) for the CodeGroup called = "My_Computer_Zone" from 'FullThrust' -> 'Everything' (effectively to = enable CAS!), I am no longer able to run the WSE 2.0 Add-in. The error = is: "The Add-in Microsoft WSE 2.0 Settings Tool" failed to load or threw = an Exception (Error 8013150a)".=20 Does anybody have an idea of what is going on? The "Everything" = CodeGroup is effectively the same as FullThrust (or mayby not?).
Actually, the Everything permission set is quite different from the
FullTrust set. There are three key differences in practice: 1. Everything excludes SecurityPermission\SkipVerification. 2. Everything includes only permissions that ship with the .NET Framework, so new permissions deployed with other assemblies are not granted with the Everything set. 3. It is possible for a demand for full trust to be made (e.g.: implicit LinkDemand for FullTrust when calling into a strongly named assembly that is not marked with AllowPartiallyTrustedCallersAttribute). Such demands will not be passed by assemblies that are granted only the Everything set. I suspect that #3 is the culprit here since the add-in assembly references WseSettings2.dll, which is a strongly named assembly that is not marked with AllowPartiallyTrustedCallersAttribute. To work around this problem, you might want to consider granting full trust to assemblies signed with the WSE setting strong name key (similar to the My_Computer_Zone\Microsoft_Strong_Name group). [quoted text, click to view] "Claus Konrad" <som@meal.it> wrote in message Having done a standard installation of WSE 2.0 (SP3), I'm perfectly able to news:%235NZ9JNgFHA.1204@TK2MSFTNGP12.phx.gbl... right-click a project and use the dialog from "WSE Settings...". However - once I change the PermissionSet (CAS) for the CodeGroup called "My_Computer_Zone" from 'FullThrust' -> 'Everything' (effectively to enable CAS!), I am no longer able to run the WSE 2.0 Add-in. The error is: "The Add-in Microsoft WSE 2.0 Settings Tool" failed to load or threw an Exception (Error 8013150a)". Does anybody have an idea of what is going on? The "Everything" CodeGroup is effectively the same as FullThrust (or mayby not?). /Claus
[quoted text, click to view]
"Claus Konrad" <som@meal.it> wrote in message news:OYdqZOZgFHA.1444@TK2MSFTNGP10.phx.gbl... > Hi Nicole > > Thanks for the informative input! > What I did not specify is that I naturally DID attempt with granting > Full_Thrust to the assemblies (see below for a cut-paste from this > Codegroup) > > **************** > Description: > WSE 2.0 related assemblies. > > Assembly evidence must match this membership condition to belong to the > code group: Url - file://C:/Program Files/Microsoft WSE/v2.0/*. Code groups based on file paths can be tricky. You need to be using the exact path that will be used at runtime, and finding that exact path can require considerable troubleshooting. In this case, I would recommend using a strong name membership condition instead of a URL membership condition when defining the code group. [quoted text, click to view] > You are correct about the AllowPartiallyThrustedCallers - but the caller > here is a Microsoft Assembly (VS.NET), Actually, the problem assembly here is probably WseSettingsVS2.dll, which is not signed with the same Microsoft strong naming key that is used for signing the .NET Framework assemblies (which is granted full trust via the My_Computer_Zone\Microsoft_Strong_Name group). [quoted text, click to view] > and assemblies exibiting strongnameidentity of <Microsoft snkey> does > receive Fullthrust, so VS.NET is therefore not partially thrusted. WseSettingsVS2.dll (the add-in assembly) is not signed with the same key, so it isn't granted full trust under the My_Computer_Zone\Microsoft_Strong_Name group. I would recommend creating a similar group (e.g.: My_Computer_Zone\MicrosoftWseSettings_Strong_Name) that uses the key from the WseSettingsVS2.dll assembly. Just so you know, I've tested this approach, and it does work. [quoted text, click to view] > Has it to do with the fact that VS.NET (the caller) is a COM application? Probably not since granting full trust to the add-in assembly resolves the problem. [quoted text, click to view] > > Thanks > /Claus > > > > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:%23QiKKmVgFHA.1048@tk2msftngp13.phx.gbl... >> Actually, the Everything permission set is quite different from the >> FullTrust set. There are three key differences in practice: >> >> 1. Everything excludes SecurityPermission\SkipVerification. >> >> 2. Everything includes only permissions that ship with the .NET >> Framework, so new permissions deployed with other assemblies are not >> granted with the Everything set. >> >> 3. It is possible for a demand for full trust to be made (e.g.: implicit >> LinkDemand for FullTrust when calling into a strongly named assembly that >> is not marked with AllowPartiallyTrustedCallersAttribute). Such demands >> will not be passed by assemblies that are granted only the Everything >> set. >> >> I suspect that #3 is the culprit here since the add-in assembly >> references WseSettings2.dll, which is a strongly named assembly that is >> not marked with AllowPartiallyTrustedCallersAttribute. To work around >> this problem, you might want to consider granting full trust to >> assemblies signed with the WSE setting strong name key (similar to the >> My_Computer_Zone\Microsoft_Strong_Name group). >> >> >> >> "Claus Konrad" <som@meal.it> wrote in message >> news:%235NZ9JNgFHA.1204@TK2MSFTNGP12.phx.gbl... >> Having done a standard installation of WSE 2.0 (SP3), I'm perfectly able >> to right-click a project and use the dialog from "WSE Settings...". >> However - once I change the PermissionSet (CAS) for the CodeGroup called >> "My_Computer_Zone" from 'FullThrust' -> 'Everything' (effectively to >> enable CAS!), I am no longer able to run the WSE 2.0 Add-in. The error >> is: "The Add-in Microsoft WSE 2.0 Settings Tool" failed to load or threw >> an Exception (Error 8013150a)". >> >> Does anybody have an idea of what is going on? The "Everything" CodeGroup >> is effectively the same as FullThrust (or mayby not?). >> >> /Claus >> > >
Hi Nicole
Thanks for the informative input! What I did not specify is that I naturally DID attempt with granting Full_Thrust to the assemblies (see below for a cut-paste from this Codegroup) **************** Description: WSE 2.0 related assemblies. Assembly evidence must match this membership condition to belong to the code group: Url - file://C:/Program Files/Microsoft WSE/v2.0/*. Assemblies matching the membership condition are granted this permission set at the current policy level: FullTrust. Permission Set Description: Allows full access to all resources ********************* You are correct about the AllowPartiallyThrustedCallers - but the caller here is a Microsoft Assembly (VS.NET), and assemblies exibiting strongnameidentity of <Microsoft snkey> does receive Fullthrust, so VS.NET is therefore not partially thrusted. Has it to do with the fact that VS.NET (the caller) is a COM application? Thanks /Claus [quoted text, click to view] "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message news:%23QiKKmVgFHA.1048@tk2msftngp13.phx.gbl... > Actually, the Everything permission set is quite different from the > FullTrust set. There are three key differences in practice: > > 1. Everything excludes SecurityPermission\SkipVerification. > > 2. Everything includes only permissions that ship with the .NET > Framework, so new permissions deployed with other assemblies are not > granted with the Everything set. > > 3. It is possible for a demand for full trust to be made (e.g.: implicit > LinkDemand for FullTrust when calling into a strongly named assembly that > is not marked with AllowPartiallyTrustedCallersAttribute). Such demands > will not be passed by assemblies that are granted only the Everything set. > > I suspect that #3 is the culprit here since the add-in assembly references > WseSettings2.dll, which is a strongly named assembly that is not marked > with AllowPartiallyTrustedCallersAttribute. To work around this problem, > you might want to consider granting full trust to assemblies signed with > the WSE setting strong name key (similar to the > My_Computer_Zone\Microsoft_Strong_Name group). > > > > "Claus Konrad" <som@meal.it> wrote in message > news:%235NZ9JNgFHA.1204@TK2MSFTNGP12.phx.gbl... > Having done a standard installation of WSE 2.0 (SP3), I'm perfectly able > to right-click a project and use the dialog from "WSE Settings...". > However - once I change the PermissionSet (CAS) for the CodeGroup called > "My_Computer_Zone" from 'FullThrust' -> 'Everything' (effectively to > enable CAS!), I am no longer able to run the WSE 2.0 Add-in. The error is: > "The Add-in Microsoft WSE 2.0 Settings Tool" failed to load or threw an > Exception (Error 8013150a)". > > Does anybody have an idea of what is going on? The "Everything" CodeGroup > is effectively the same as FullThrust (or mayby not?). > > /Claus >
Thanks a zillion!
SN did the trick. Now - I'm just puzzled as to why the built-in CodeGroup (My_Computer_Zone) does not give everything fullthrust as it's condition is Zone = My Computer? I mean - everything on my C-drive fullfils this condition? That MS has made a SN-condition in addition to this group is just to maintain full trust to their own assemblies (maching a cretain sn). Am I totally way out here? /Claus [quoted text, click to view] "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message news:uPTyR7ZgFHA.2916@TK2MSFTNGP14.phx.gbl... > "Claus Konrad" <som@meal.it> wrote in message > news:OYdqZOZgFHA.1444@TK2MSFTNGP10.phx.gbl... >> Hi Nicole >> >> Thanks for the informative input! >> What I did not specify is that I naturally DID attempt with granting >> Full_Thrust to the assemblies (see below for a cut-paste from this >> Codegroup) >> >> **************** >> Description: >> WSE 2.0 related assemblies. >> >> Assembly evidence must match this membership condition to belong to the >> code group: Url - file://C:/Program Files/Microsoft WSE/v2.0/*. > > Code groups based on file paths can be tricky. You need to be using the > exact path that will be used at runtime, and finding that exact path can > require considerable troubleshooting. In this case, I would recommend > using a strong name membership condition instead of a URL membership > condition when defining the code group. > > >> You are correct about the AllowPartiallyThrustedCallers - but the caller >> here is a Microsoft Assembly (VS.NET), > > Actually, the problem assembly here is probably WseSettingsVS2.dll, which > is not signed with the same Microsoft strong naming key that is used for > signing the .NET Framework assemblies (which is granted full trust via the > My_Computer_Zone\Microsoft_Strong_Name group). > > >> and assemblies exibiting strongnameidentity of <Microsoft snkey> does >> receive Fullthrust, so VS.NET is therefore not partially thrusted. > > WseSettingsVS2.dll (the add-in assembly) is not signed with the same key, > so it isn't granted full trust under the > My_Computer_Zone\Microsoft_Strong_Name group. I would recommend creating > a similar group (e.g.: My_Computer_Zone\MicrosoftWseSettings_Strong_Name) > that uses the key from the WseSettingsVS2.dll assembly. Just so you know, > I've tested this approach, and it does work. > > >> Has it to do with the fact that VS.NET (the caller) is a COM application? > > Probably not since granting full trust to the add-in assembly resolves the > problem. > > >> >> Thanks >> /Claus >> >> >> >> >> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message >> news:%23QiKKmVgFHA.1048@tk2msftngp13.phx.gbl... >>> Actually, the Everything permission set is quite different from the >>> FullTrust set. There are three key differences in practice: >>> >>> 1. Everything excludes SecurityPermission\SkipVerification. >>> >>> 2. Everything includes only permissions that ship with the .NET >>> Framework, so new permissions deployed with other assemblies are not >>> granted with the Everything set. >>> >>> 3. It is possible for a demand for full trust to be made (e.g.: >>> implicit LinkDemand for FullTrust when calling into a strongly named >>> assembly that is not marked with AllowPartiallyTrustedCallersAttribute). >>> Such demands will not be passed by assemblies that are granted only the >>> Everything set. >>> >>> I suspect that #3 is the culprit here since the add-in assembly >>> references WseSettings2.dll, which is a strongly named assembly that is >>> not marked with AllowPartiallyTrustedCallersAttribute. To work around >>> this problem, you might want to consider granting full trust to >>> assemblies signed with the WSE setting strong name key (similar to the >>> My_Computer_Zone\Microsoft_Strong_Name group). >>> >>> >>> >>> "Claus Konrad" <som@meal.it> wrote in message >>> news:%235NZ9JNgFHA.1204@TK2MSFTNGP12.phx.gbl... >>> Having done a standard installation of WSE 2.0 (SP3), I'm perfectly able >>> to right-click a project and use the dialog from "WSE Settings...". >>> However - once I change the PermissionSet (CAS) for the CodeGroup called >>> "My_Computer_Zone" from 'FullThrust' -> 'Everything' (effectively to >>> enable CAS!), I am no longer able to run the WSE 2.0 Add-in. The error >>> is: "The Add-in Microsoft WSE 2.0 Settings Tool" failed to load or threw >>> an Exception (Error 8013150a)". >>> >>> Does anybody have an idea of what is going on? The "Everything" >>> CodeGroup is effectively the same as FullThrust (or mayby not?). >>> >>> /Claus >>> >> >> > >
Or put in another way - the CodeGroup "My_Computer_Zone" with PermissionSet
= "Full Trust" simply just trusts everything running from my harddrive, correct? It effectively disables CAS on my local harddrive? /Claus [quoted text, click to view] "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message news:uPTyR7ZgFHA.2916@TK2MSFTNGP14.phx.gbl... > "Claus Konrad" <som@meal.it> wrote in message > news:OYdqZOZgFHA.1444@TK2MSFTNGP10.phx.gbl... >> Hi Nicole >> >> Thanks for the informative input! >> What I did not specify is that I naturally DID attempt with granting >> Full_Thrust to the assemblies (see below for a cut-paste from this >> Codegroup) >> >> **************** >> Description: >> WSE 2.0 related assemblies. >> >> Assembly evidence must match this membership condition to belong to the >> code group: Url - file://C:/Program Files/Microsoft WSE/v2.0/*. > > Code groups based on file paths can be tricky. You need to be using the > exact path that will be used at runtime, and finding that exact path can > require considerable troubleshooting. In this case, I would recommend > using a strong name membership condition instead of a URL membership > condition when defining the code group. > > >> You are correct about the AllowPartiallyThrustedCallers - but the caller >> here is a Microsoft Assembly (VS.NET), > > Actually, the problem assembly here is probably WseSettingsVS2.dll, which > is not signed with the same Microsoft strong naming key that is used for > signing the .NET Framework assemblies (which is granted full trust via the > My_Computer_Zone\Microsoft_Strong_Name group). > > >> and assemblies exibiting strongnameidentity of <Microsoft snkey> does >> receive Fullthrust, so VS.NET is therefore not partially thrusted. > > WseSettingsVS2.dll (the add-in assembly) is not signed with the same key, > so it isn't granted full trust under the > My_Computer_Zone\Microsoft_Strong_Name group. I would recommend creating > a similar group (e.g.: My_Computer_Zone\MicrosoftWseSettings_Strong_Name) > that uses the key from the WseSettingsVS2.dll assembly. Just so you know, > I've tested this approach, and it does work. > > >> Has it to do with the fact that VS.NET (the caller) is a COM application? > > Probably not since granting full trust to the add-in assembly resolves the > problem. > > >> >> Thanks >> /Claus >> >> >> >> >> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message >> news:%23QiKKmVgFHA.1048@tk2msftngp13.phx.gbl... >>> Actually, the Everything permission set is quite different from the >>> FullTrust set. There are three key differences in practice: >>> >>> 1. Everything excludes SecurityPermission\SkipVerification. >>> >>> 2. Everything includes only permissions that ship with the .NET >>> Framework, so new permissions deployed with other assemblies are not >>> granted with the Everything set. >>> >>> 3. It is possible for a demand for full trust to be made (e.g.: >>> implicit LinkDemand for FullTrust when calling into a strongly named >>> assembly that is not marked with AllowPartiallyTrustedCallersAttribute). >>> Such demands will not be passed by assemblies that are granted only the >>> Everything set. >>> >>> I suspect that #3 is the culprit here since the add-in assembly >>> references WseSettings2.dll, which is a strongly named assembly that is >>> not marked with AllowPartiallyTrustedCallersAttribute. To work around >>> this problem, you might want to consider granting full trust to >>> assemblies signed with the WSE setting strong name key (similar to the >>> My_Computer_Zone\Microsoft_Strong_Name group). >>> >>> >>> >>> "Claus Konrad" <som@meal.it> wrote in message >>> news:%235NZ9JNgFHA.1204@TK2MSFTNGP12.phx.gbl... >>> Having done a standard installation of WSE 2.0 (SP3), I'm perfectly able >>> to right-click a project and use the dialog from "WSE Settings...". >>> However - once I change the PermissionSet (CAS) for the CodeGroup called >>> "My_Computer_Zone" from 'FullThrust' -> 'Everything' (effectively to >>> enable CAS!), I am no longer able to run the WSE 2.0 Add-in. The error >>> is: "The Add-in Microsoft WSE 2.0 Settings Tool" failed to load or threw >>> an Exception (Error 8013150a)". >>> >>> Does anybody have an idea of what is going on? The "Everything" >>> CodeGroup is effectively the same as FullThrust (or mayby not?). >>> >>> /Claus >>> >> >> > >
[quoted text, click to view]
"Claus Konrad" <som@meal.it> wrote in message news:Ou4SrgagFHA.1948@TK2MSFTNGP12.phx.gbl... > Thanks a zillion! > SN did the trick. > > Now - I'm just puzzled as to why the built-in CodeGroup (My_Computer_Zone) > does not give everything fullthrust as it's condition is Zone = My > Computer? Back in your first post in this thread, you reported changing the zone code group to use the Everything permission set instead of FullTrust. Why are you surprised that the FullTrust set is no longer being granted in the zone? [quoted text, click to view] > I mean - everything on my C-drive fullfils this condition? Almost everything. Assemblies loaded from the network are probably also stored on your C: drive even though they are not assessed as falling in the local zone. [quoted text, click to view] > That MS has made a SN-condition in addition to this group is just to > maintain full trust to their own assemblies (maching a cretain sn). The code groups for the Microsoft and ECMA strong names are redundant as long as the local zone is granted full trust. However, if someone alters the permissions grant on the local zone (as you did by changing the grant from FullTrust to Everything), these two code groups help ensure that the core .NET Framework assemblies and supporting utilities will continue to work correctly. [quoted text, click to view] > Am I totally way out here? > > /Claus > > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:uPTyR7ZgFHA.2916@TK2MSFTNGP14.phx.gbl... >> "Claus Konrad" <som@meal.it> wrote in message >> news:OYdqZOZgFHA.1444@TK2MSFTNGP10.phx.gbl... >>> Hi Nicole >>> >>> Thanks for the informative input! >>> What I did not specify is that I naturally DID attempt with granting >>> Full_Thrust to the assemblies (see below for a cut-paste from this >>> Codegroup) >>> >>> **************** >>> Description: >>> WSE 2.0 related assemblies. >>> >>> Assembly evidence must match this membership condition to belong to the >>> code group: Url - file://C:/Program Files/Microsoft WSE/v2.0/*. >> >> Code groups based on file paths can be tricky. You need to be using the >> exact path that will be used at runtime, and finding that exact path can >> require considerable troubleshooting. In this case, I would recommend >> using a strong name membership condition instead of a URL membership >> condition when defining the code group. >> >> >>> You are correct about the AllowPartiallyThrustedCallers - but the caller >>> here is a Microsoft Assembly (VS.NET), >> >> Actually, the problem assembly here is probably WseSettingsVS2.dll, which >> is not signed with the same Microsoft strong naming key that is used for >> signing the .NET Framework assemblies (which is granted full trust via >> the My_Computer_Zone\Microsoft_Strong_Name group). >> >> >>> and assemblies exibiting strongnameidentity of <Microsoft snkey> does >>> receive Fullthrust, so VS.NET is therefore not partially thrusted. >> >> WseSettingsVS2.dll (the add-in assembly) is not signed with the same key, >> so it isn't granted full trust under the >> My_Computer_Zone\Microsoft_Strong_Name group. I would recommend creating >> a similar group (e.g.: My_Computer_Zone\MicrosoftWseSettings_Strong_Name) >> that uses the key from the WseSettingsVS2.dll assembly. Just so you >> know, I've tested this approach, and it does work. >> >> >>> Has it to do with the fact that VS.NET (the caller) is a COM >>> application? >> >> Probably not since granting full trust to the add-in assembly resolves >> the problem. >> >> >>> >>> Thanks >>> /Claus >>> >>> >>> >>> >>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in >>> message news:%23QiKKmVgFHA.1048@tk2msftngp13.phx.gbl... >>>> Actually, the Everything permission set is quite different from the >>>> FullTrust set. There are three key differences in practice: >>>> >>>> 1. Everything excludes SecurityPermission\SkipVerification. >>>> >>>> 2. Everything includes only permissions that ship with the .NET >>>> Framework, so new permissions deployed with other assemblies are not >>>> granted with the Everything set. >>>> >>>> 3. It is possible for a demand for full trust to be made (e.g.: >>>> implicit LinkDemand for FullTrust when calling into a strongly named >>>> assembly that is not marked with >>>> AllowPartiallyTrustedCallersAttribute). Such demands will not be passed >>>> by assemblies that are granted only the Everything set. >>>> >>>> I suspect that #3 is the culprit here since the add-in assembly >>>> references WseSettings2.dll, which is a strongly named assembly that is >>>> not marked with AllowPartiallyTrustedCallersAttribute. To work around >>>> this problem, you might want to consider granting full trust to >>>> assemblies signed with the WSE setting strong name key (similar to the >>>> My_Computer_Zone\Microsoft_Strong_Name group). >>>> >>>> >>>> >>>> "Claus Konrad" <som@meal.it> wrote in message >>>> news:%235NZ9JNgFHA.1204@TK2MSFTNGP12.phx.gbl... >>>> Having done a standard installation of WSE 2.0 (SP3), I'm perfectly >>>> able to right-click a project and use the dialog from "WSE >>>> Settings...". >>>> However - once I change the PermissionSet (CAS) for the CodeGroup >>>> called "My_Computer_Zone" from 'FullThrust' -> 'Everything' >>>> (effectively to enable CAS!), I am no longer able to run the WSE 2.0 >>>> Add-in. The error is: "The Add-in Microsoft WSE 2.0 Settings Tool" >>>> failed to load or threw an Exception (Error 8013150a)". >>>> >>>> Does anybody have an idea of what is going on? The "Everything" >>>> CodeGroup is effectively the same as FullThrust (or mayby not?). >>>> >>>> /Claus >>>> >>> >>> >> >> > >
Answered in your new thread...
[quoted text, click to view] "Claus Konrad" <som@meal.it> wrote in message news:OiumwnagFHA.2156@TK2MSFTNGP14.phx.gbl... > Or put in another way - the CodeGroup "My_Computer_Zone" with > PermissionSet = "Full Trust" simply just trusts everything running from my > harddrive, correct? > > It effectively disables CAS on my local harddrive? > > /Claus > > > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:uPTyR7ZgFHA.2916@TK2MSFTNGP14.phx.gbl... >> "Claus Konrad" <som@meal.it> wrote in message >> news:OYdqZOZgFHA.1444@TK2MSFTNGP10.phx.gbl... >>> Hi Nicole >>> >>> Thanks for the informative input! >>> What I did not specify is that I naturally DID attempt with granting >>> Full_Thrust to the assemblies (see below for a cut-paste from this >>> Codegroup) >>> >>> **************** >>> Description: >>> WSE 2.0 related assemblies. >>> >>> Assembly evidence must match this membership condition to belong to the >>> code group: Url - file://C:/Program Files/Microsoft WSE/v2.0/*. >> >> Code groups based on file paths can be tricky. You need to be using the >> exact path that will be used at runtime, and finding that exact path can >> require considerable troubleshooting. In this case, I would recommend >> using a strong name membership condition instead of a URL membership >> condition when defining the code group. >> >> >>> You are correct about the AllowPartiallyThrustedCallers - but the caller >>> here is a Microsoft Assembly (VS.NET), >> >> Actually, the problem assembly here is probably WseSettingsVS2.dll, which >> is not signed with the same Microsoft strong naming key that is used for >> signing the .NET Framework assemblies (which is granted full trust via >> the My_Computer_Zone\Microsoft_Strong_Name group). >> >> >>> and assemblies exibiting strongnameidentity of <Microsoft snkey> does >>> receive Fullthrust, so VS.NET is therefore not partially thrusted. >> >> WseSettingsVS2.dll (the add-in assembly) is not signed with the same key, >> so it isn't granted full trust under the >> My_Computer_Zone\Microsoft_Strong_Name group. I would recommend creating >> a similar group (e.g.: My_Computer_Zone\MicrosoftWseSettings_Strong_Name) >> that uses the key from the WseSettingsVS2.dll assembly. Just so you >> know, I've tested this approach, and it does work. >> >> >>> Has it to do with the fact that VS.NET (the caller) is a COM >>> application? >> >> Probably not since granting full trust to the add-in assembly resolves >> the problem. >> >> >>> >>> Thanks >>> /Claus >>> >>> >>> >>> >>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in >>> message news:%23QiKKmVgFHA.1048@tk2msftngp13.phx.gbl... >>>> Actually, the Everything permission set is quite different from the >>>> FullTrust set. There are three key differences in practice: >>>> >>>> 1. Everything excludes SecurityPermission\SkipVerification. >>>> >>>> 2. Everything includes only permissions that ship with the .NET >>>> Framework, so new permissions deployed with other assemblies are not >>>> granted with the Everything set. >>>> >>>> 3. It is possible for a demand for full trust to be made (e.g.: >>>> implicit LinkDemand for FullTrust when calling into a strongly named >>>> assembly that is not marked with >>>> AllowPartiallyTrustedCallersAttribute). Such demands will not be passed >>>> by assemblies that are granted only the Everything set. >>>> >>>> I suspect that #3 is the culprit here since the add-in assembly >>>> references WseSettings2.dll, which is a strongly named assembly that is >>>> not marked with AllowPartiallyTrustedCallersAttribute. To work around >>>> this problem, you might want to consider granting full trust to >>>> assemblies signed with the WSE setting strong name key (similar to the >>>> My_Computer_Zone\Microsoft_Strong_Name group). >>>> >>>> >>>> >>>> "Claus Konrad" <som@meal.it> wrote in message >>>> news:%235NZ9JNgFHA.1204@TK2MSFTNGP12.phx.gbl... >>>> Having done a standard installation of WSE 2.0 (SP3), I'm perfectly >>>> able to right-click a project and use the dialog from "WSE >>>> Settings...". >>>> However - once I change the PermissionSet (CAS) for the CodeGroup >>>> called "My_Computer_Zone" from 'FullThrust' -> 'Everything' >>>> (effectively to enable CAS!), I am no longer able to run the WSE 2.0 >>>> Add-in. The error is: "The Add-in Microsoft WSE 2.0 Settings Tool" >>>> failed to load or threw an Exception (Error 8013150a)". >>>> >>>> Does anybody have an idea of what is going on? The "Everything" >>>> CodeGroup is effectively the same as FullThrust (or mayby not?). >>>> >>>> /Claus >>>> >>> >>> >> >> > >
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |