|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Different Permissions For Forms Control in Internet Explorer AppliedI have a Windows Forms Control running within the Internet Explorer. The application is able to download files from a remote store via drag and drop to the local filesystem. Some details: - The files are selected from a ListView - ListView.ItemDrag - calculates a temporary filename (beneath Path.GetTempPath()) for each of the selected files - and creates the necessary DataObject structure with DataFormts.FileDrop and DragDropEffects.Move - ListView.QueryContinueDrag watches for the DragAction.Drop event and than downloads the file(s) content from the remote location to the calculated temporary filename. The file does not exist prior to this point. Due to several circumstances the application is assigned FullTrust via the StrongName condition. All is running smoothly under .Net 1.1. For .Net 2.0 with equal security settings the temporary file is not moved from its temporary location to the drop location. To be clear: this is not done by the application itself but the Windows Explorer. Now comes the mistery: - With security turned off completly (caspol -s off) the application works - With a UrlCondition attached to the complete webserver (not only the controls dll location) the application works - http://servername/path/name.dll does not work - http://servername/path/* does not work - http://servername/* works Why is fulltrust not fulltrust? Any ideas? Thanks for your help, Markus ================================== caspol -a -resolveperm http://... path to dll ================================== Resolving permissions for level = Enterprise Resolving permissions for level = Machine Resolving permissions for level = User Grant = <PermissionSet class="System.Security.PermissionSet" version="1" Unrestricted="true"/> ================================== caspol -a -resolvegroup http://... path to dll ================================== Level = Enterprise Code Groups: 1. All code: FullTrust Level = Machine Code Groups: 1. All code: Nothing 1.2. Zone - Intranet: LocalIntranet 1.2.1. All code: Same site Web 1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery' 1.6. StrongName - 0024000004800000940000000602000000240000525341310004000001 0001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6ED165DFFE E84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F559A54A50 5CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCCAC4D96E2C CC2968AC2D3AA11DFB1FBB: FullTrust Level = User Code Groups: 1. All code: FullTrust Hi Markus,
Thank you for posting. This is a quick note to let you know that I am performing research on this issue and will get back to you as soon as possible. I appreciate your patience. Sincerely, Linda Liu Microsoft Online Community Support ==================================================== When responding to posts,please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ==================================================== Linda,
you find additional information in my answer to Nicoles reply. Thanks for your help, Markus Show quote "Linda Liu [MSFT]" <v-l***@online.microsoft.com> schrieb im Newsbeitrag news:0ncX3NSlGHA.5184@TK2MSFTNGXA01.phx.gbl... > Hi Markus, > > Thank you for posting. > > This is a quick note to let you know that I am performing research on this > issue and will get back to you as soon as possible. I appreciate your > patience. > > > Sincerely, > Linda Liu > Microsoft Online Community Support > > ==================================================== > When responding to posts,please "Reply to Group" via > your newsreader so that others may learn and benefit > from your issue. > ==================================================== > Is the 1.1 vs 2.0 difference being observed on identical assemblies, or did
you make some code changes for the 2.0 version? If the latter, you may want to take a look at http://blogs.msdn.com/shawnfa/archive/2003/06/26/57026.aspx to see if any of your changes might have impacted on the effect permission grant. For example, if your code uses assertions to work around the AppDomain permission limitation, and you've marked your 2.0 assembly as SecurityTransparent, your assertions will not work. If the problem is being observed on the same assembly, might it be that the 1.1 CAS policy is granting extended permissions based on something other than the strong name (e.g.: local intranet zone granted full trust)? If not, are any exception being thrown and, if so, could you please post the full exception details (incl. call stack listing), as returned by its ToString method? Show quote "Markus Kling" <markus.kling@nospam.nospam> wrote in message news:O0kwKvElGHA.3304@TK2MSFTNGP03.phx.gbl... > Hi, > > I have a Windows Forms Control running within the Internet Explorer. > > The application is able to download files from a remote store via drag and > drop to the local filesystem. Some details: > > - The files are selected from a ListView > > - ListView.ItemDrag > - calculates a temporary filename (beneath Path.GetTempPath()) for each > of the selected files > - and creates the necessary DataObject structure with DataFormts.FileDrop > and DragDropEffects.Move > > - ListView.QueryContinueDrag watches for the DragAction.Drop event and > than downloads the file(s) content from the remote location to the > calculated temporary filename. The file does not exist prior to this > point. > > Due to several circumstances the application is assigned FullTrust via the > StrongName condition. All is running smoothly under .Net 1.1. > > For .Net 2.0 with equal security settings the temporary file is not moved > from its temporary location to the drop location. To be clear: this is not > done by the application itself but the Windows Explorer. > > Now comes the mistery: > > - With security turned off completly (caspol -s off) the application works > - With a UrlCondition attached to the complete webserver (not only the > controls dll location) the application works > - http://servername/path/name.dll does not work > - http://servername/path/* does not work > - http://servername/* works > > > Why is fulltrust not fulltrust? > Any ideas? > > Thanks for your help, > Markus > > > ================================== > caspol -a -resolveperm http://... path to dll > ================================== > Resolving permissions for level = Enterprise > Resolving permissions for level = Machine > Resolving permissions for level = User > > Grant = > <PermissionSet class="System.Security.PermissionSet" > version="1" > Unrestricted="true"/> > > ================================== > caspol -a -resolvegroup http://... path to dll > ================================== > Level = Enterprise > Code Groups: > 1. All code: FullTrust > > Level = Machine > Code Groups: > 1. All code: Nothing > 1.2. Zone - Intranet: LocalIntranet > 1.2.1. All code: Same site Web > 1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery' > 1.6. StrongName - > 0024000004800000940000000602000000240000525341310004000001 > 0001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6ED165DFFE > E84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F559A54A50 > 5CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCCAC4D96E2C > CC2968AC2D3AA11DFB1FBB: FullTrust > > Level = User > Code Groups: > 1. All code: FullTrust > > > > Hi Nicole,
thanks for your answers. I allready knew that fabulous post ;) To answer your questsion: - All security permissions (1.1 & 2.0) are not touched except adding the described strong memebership codegroup. You can find the output from caspol for the remote location of the dll attached to my last post - As described the code runs perfect with equal permissions using the .Net 1.1 VM - There are no exceptions thrown at any point. I even stepped through the whole drag&drop code using a debugger... nothing! As mensioned, the code does a WebService-Call and stores the returned content to a temporary file location which should than be moved by native code from the explorer processes to the drop location. The temporary file is created correctly event with the file contents but the explorer only moves the created file under the following circumstances: - With security turned off completly (caspol -s off) the application works - With a UrlCondition attached to the complete webserver (not only the controls dll location) the application works - http://servername/path/name.dll does not work - http://servername/path/* does not work - http://servername/* works That's totally confusing me! Markus Show quote "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im Newsbeitrag news:e%23lzpfSlGHA.4872@TK2MSFTNGP04.phx.gbl... > Is the 1.1 vs 2.0 difference being observed on identical assemblies, or > did you make some code changes for the 2.0 version? If the latter, you > may want to take a look at > http://blogs.msdn.com/shawnfa/archive/2003/06/26/57026.aspx to see if any > of your changes might have impacted on the effect permission grant. For > example, if your code uses assertions to work around the AppDomain > permission limitation, and you've marked your 2.0 assembly as > SecurityTransparent, your assertions will not work. > > If the problem is being observed on the same assembly, might it be that > the 1.1 CAS policy is granting extended permissions based on something > other than the strong name (e.g.: local intranet zone granted full trust)? > If not, are any exception being thrown and, if so, could you please post > the full exception details (incl. call stack listing), as returned by its > ToString method? > > > "Markus Kling" <markus.kling@nospam.nospam> wrote in message > news:O0kwKvElGHA.3304@TK2MSFTNGP03.phx.gbl... >> Hi, >> >> I have a Windows Forms Control running within the Internet Explorer. >> >> The application is able to download files from a remote store via drag >> and drop to the local filesystem. Some details: >> >> - The files are selected from a ListView >> >> - ListView.ItemDrag >> - calculates a temporary filename (beneath Path.GetTempPath()) for each >> of the selected files >> - and creates the necessary DataObject structure with >> DataFormts.FileDrop and DragDropEffects.Move >> >> - ListView.QueryContinueDrag watches for the DragAction.Drop event and >> than downloads the file(s) content from the remote location to the >> calculated temporary filename. The file does not exist prior to this >> point. >> >> Due to several circumstances the application is assigned FullTrust via >> the StrongName condition. All is running smoothly under .Net 1.1. >> >> For .Net 2.0 with equal security settings the temporary file is not moved >> from its temporary location to the drop location. To be clear: this is >> not done by the application itself but the Windows Explorer. >> >> Now comes the mistery: >> >> - With security turned off completly (caspol -s off) the application >> works >> - With a UrlCondition attached to the complete webserver (not only the >> controls dll location) the application works >> - http://servername/path/name.dll does not work >> - http://servername/path/* does not work >> - http://servername/* works >> >> >> Why is fulltrust not fulltrust? >> Any ideas? >> >> Thanks for your help, >> Markus >> >> >> ================================== >> caspol -a -resolveperm http://... path to dll >> ================================== >> Resolving permissions for level = Enterprise >> Resolving permissions for level = Machine >> Resolving permissions for level = User >> >> Grant = >> <PermissionSet class="System.Security.PermissionSet" >> version="1" >> Unrestricted="true"/> >> >> ================================== >> caspol -a -resolvegroup http://... path to dll >> ================================== >> Level = Enterprise >> Code Groups: >> 1. All code: FullTrust >> >> Level = Machine >> Code Groups: >> 1. All code: Nothing >> 1.2. Zone - Intranet: LocalIntranet >> 1.2.1. All code: Same site Web >> 1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery' >> 1.6. StrongName - >> 0024000004800000940000000602000000240000525341310004000001 >> 0001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6ED165DFFE >> E84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F559A54A50 >> 5CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCCAC4D96E2C >> CC2968AC2D3AA11DFB1FBB: FullTrust >> >> Level = User >> Code Groups: >> 1. All code: FullTrust >> >> >> >> > > What does the caspol output look like on the 1.1 machine? Also, is fx 1.1
installed on the fx 2.0 machine? If so, are you sure that you've modified the CAS policy for 2.0 instead of 1.1 on that machine? If you're sure that you've modified the 2.0 policy, might it happen to be a 64-bit machine? If so, did you run the 32-bit or 64-bit version of caspol? Show quote "Markus Kling" <markus.kling@nospam.nospam> wrote in message news:u5py30TlGHA.3740@TK2MSFTNGP02.phx.gbl... > Hi Nicole, > > thanks for your answers. I allready knew that fabulous post ;) > > To answer your questsion: > - All security permissions (1.1 & 2.0) are not touched except adding the > described strong memebership codegroup. You can find the output from > caspol for the remote location of the dll attached to my last post > - As described the code runs perfect with equal permissions using the .Net > 1.1 VM > - There are no exceptions thrown at any point. I even stepped through the > whole drag&drop code using a debugger... nothing! > > As mensioned, the code does a WebService-Call and stores the returned > content to a temporary file location which should than be moved by native > code from the explorer processes to the drop location. The temporary file > is created correctly event with the file contents but the explorer only > moves the created file under the following circumstances: > > - With security turned off completly (caspol -s off) the application works > - With a UrlCondition attached to the complete webserver (not only the > controls dll location) the application works > - http://servername/path/name.dll does not work > - http://servername/path/* does not work > - http://servername/* works > > > That's totally confusing me! > Markus > > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im > Newsbeitrag news:e%23lzpfSlGHA.4872@TK2MSFTNGP04.phx.gbl... >> Is the 1.1 vs 2.0 difference being observed on identical assemblies, or >> did you make some code changes for the 2.0 version? If the latter, you >> may want to take a look at >> http://blogs.msdn.com/shawnfa/archive/2003/06/26/57026.aspx to see if any >> of your changes might have impacted on the effect permission grant. For >> example, if your code uses assertions to work around the AppDomain >> permission limitation, and you've marked your 2.0 assembly as >> SecurityTransparent, your assertions will not work. >> >> If the problem is being observed on the same assembly, might it be that >> the 1.1 CAS policy is granting extended permissions based on something >> other than the strong name (e.g.: local intranet zone granted full >> trust)? If not, are any exception being thrown and, if so, could you >> please post the full exception details (incl. call stack listing), as >> returned by its ToString method? >> >> >> "Markus Kling" <markus.kling@nospam.nospam> wrote in message >> news:O0kwKvElGHA.3304@TK2MSFTNGP03.phx.gbl... >>> Hi, >>> >>> I have a Windows Forms Control running within the Internet Explorer. >>> >>> The application is able to download files from a remote store via drag >>> and drop to the local filesystem. Some details: >>> >>> - The files are selected from a ListView >>> >>> - ListView.ItemDrag >>> - calculates a temporary filename (beneath Path.GetTempPath()) for each >>> of the selected files >>> - and creates the necessary DataObject structure with >>> DataFormts.FileDrop and DragDropEffects.Move >>> >>> - ListView.QueryContinueDrag watches for the DragAction.Drop event and >>> than downloads the file(s) content from the remote location to the >>> calculated temporary filename. The file does not exist prior to this >>> point. >>> >>> Due to several circumstances the application is assigned FullTrust via >>> the StrongName condition. All is running smoothly under .Net 1.1. >>> >>> For .Net 2.0 with equal security settings the temporary file is not >>> moved from its temporary location to the drop location. To be clear: >>> this is not done by the application itself but the Windows Explorer. >>> >>> Now comes the mistery: >>> >>> - With security turned off completly (caspol -s off) the application >>> works >>> - With a UrlCondition attached to the complete webserver (not only the >>> controls dll location) the application works >>> - http://servername/path/name.dll does not work >>> - http://servername/path/* does not work >>> - http://servername/* works >>> >>> >>> Why is fulltrust not fulltrust? >>> Any ideas? >>> >>> Thanks for your help, >>> Markus >>> >>> >>> ================================== >>> caspol -a -resolveperm http://... path to dll >>> ================================== >>> Resolving permissions for level = Enterprise >>> Resolving permissions for level = Machine >>> Resolving permissions for level = User >>> >>> Grant = >>> <PermissionSet class="System.Security.PermissionSet" >>> version="1" >>> Unrestricted="true"/> >>> >>> ================================== >>> caspol -a -resolvegroup http://... path to dll >>> ================================== >>> Level = Enterprise >>> Code Groups: >>> 1. All code: FullTrust >>> >>> Level = Machine >>> Code Groups: >>> 1. All code: Nothing >>> 1.2. Zone - Intranet: LocalIntranet >>> 1.2.1. All code: Same site Web >>> 1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery' >>> 1.6. StrongName - >>> 0024000004800000940000000602000000240000525341310004000001 >>> 0001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6ED165DFFE >>> E84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F559A54A50 >>> 5CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCCAC4D96E2C >>> CC2968AC2D3AA11DFB1FBB: FullTrust >>> >>> Level = User >>> Code Groups: >>> 1. All code: FullTrust >>> >>> >>> >>> >> >> > > Nicole,
What does the caspol output look like on the 1.1 machine? <PermissionSet class="System.Security.PermissionSet" version="1" Unrestricted="true"> <IPermission class="System.Security.Permissions.SiteIdentityPermission, mscor lib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Site="<site>"/> <IPermission class="System.Security.Permissions.StrongNameIdentityPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" PublicKeyBlob="0024000004800000940000000602000000240000525341310 0040000010001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6 ED165DFFEE84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F 559A54A505CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCC AC4D96E2CCC2968AC2D3AA11DFB1FBB" Name="<dll name>" AssemblyVersion="1.7.2355.17871"/> <IPermission class="System.Security.Permissions.UrlIdentityPermission, mscorl ib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Url="<... dllpath ... >"/> <IPermission class="System.Security.Permissions.ZoneIdentityPermission, mscor lib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Zone="Intranet"/> </PermissionSet> Also, is fx 1.1 installed on the fx 2.0 machine? Yes If so, are you sure that you've modified the CAS policy for 2.0 instead of 1.1 on that machine? Yes, they are both modified. If you're sure that you've modified the 2.0 policy Yes, definitly. Might it happen to be a 64-bit machine? No, 32 bit OS Sorry, I meant a caspol -a -resolvegroup output, like the one you included
in your first message. Also, could you please confirm whether the problem is being observed on _exactly_ the same assembly or whether it has been modified in _any_ way (including recompilation with VStudio 2005) for 2.0. Show quote "Markus Kling" <markus.kling@nospam.nospam> wrote in message news:%238MJ7vUlGHA.3396@TK2MSFTNGP05.phx.gbl... > Nicole, > > What does the caspol output look like on the 1.1 machine? > > <PermissionSet class="System.Security.PermissionSet" > version="1" > Unrestricted="true"> > <IPermission class="System.Security.Permissions.SiteIdentityPermission, > mscor > lib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > version="1" > Site="<site>"/> > <IPermission > class="System.Security.Permissions.StrongNameIdentityPermission, > mscorlib, Version=1.0.5000.0, Culture=neutral, > PublicKeyToken=b77a5c561934e089" > > version="1" > > PublicKeyBlob="0024000004800000940000000602000000240000525341310 > 0040000010001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6 > ED165DFFEE84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F > 559A54A505CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCC > AC4D96E2CCC2968AC2D3AA11DFB1FBB" > Name="<dll name>" > AssemblyVersion="1.7.2355.17871"/> > <IPermission class="System.Security.Permissions.UrlIdentityPermission, > mscorl > ib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > version="1" > Url="<... dllpath ... >"/> > <IPermission class="System.Security.Permissions.ZoneIdentityPermission, > mscor > lib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > version="1" > Zone="Intranet"/> > </PermissionSet> > > > Also, is fx 1.1 installed on the fx 2.0 machine? > Yes > > If so, are you sure that you've modified the CAS policy for 2.0 instead > of 1.1 on that machine? > Yes, they are both modified. > > If you're sure that you've modified the 2.0 policy > Yes, definitly. > > Might it happen to be a 64-bit machine? > No, 32 bit OS > > > 1) Sorry, I meant a caspol -a -resolvegroup output, like the one you
included in your first message. Level = Enterprise Code Groups: 1. All code: FullTrust Level = Machine Code Groups: 1. All code: Nothing 1.1. Zone - Intranet: LocalIntranet 1.1.1. All code: Same site Web. 1.1.2. All code: Same directory FileIO - Read, PathDiscovery 1.5. StrongName - 0024000004800000940000000602000000240000525341310004000001 0001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6ED165DFFE E84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F559A54A50 5CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCCAC4D96E2C CC2968AC2D3AA11DFB1FBB: FullTrust Level = User Code Groups: 1. All code: FullTrust 2) Is being observed on _exactly_ the same assembly or whether it has been modified in _any_ way (including recompilation with VStudio 2005) for 2.0. Yes! The machines running the dll for test purposes are even fresh installed VPCs only having the latest servicepacks and .Net Framework installed. Show quote "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im Newsbeitrag news:OSs6WnqlGHA.3632@TK2MSFTNGP03.phx.gbl... > Sorry, I meant a caspol -a -resolvegroup output, like the one you included > in your first message. Also, could you please confirm whether the problem > is being observed on _exactly_ the same assembly or whether it has been > modified in _any_ way (including recompilation with VStudio 2005) for 2.0. > > > "Markus Kling" <markus.kling@nospam.nospam> wrote in message > news:%238MJ7vUlGHA.3396@TK2MSFTNGP05.phx.gbl... >> Nicole, >> >> What does the caspol output look like on the 1.1 machine? >> >> <PermissionSet class="System.Security.PermissionSet" >> version="1" >> Unrestricted="true"> >> <IPermission class="System.Security.Permissions.SiteIdentityPermission, >> mscor >> lib, Version=1.0.5000.0, Culture=neutral, >> PublicKeyToken=b77a5c561934e089" >> version="1" >> Site="<site>"/> >> <IPermission >> class="System.Security.Permissions.StrongNameIdentityPermission, >> mscorlib, Version=1.0.5000.0, Culture=neutral, >> PublicKeyToken=b77a5c561934e089" >> >> version="1" >> >> PublicKeyBlob="0024000004800000940000000602000000240000525341310 >> 0040000010001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6 >> ED165DFFEE84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F >> 559A54A505CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCC >> AC4D96E2CCC2968AC2D3AA11DFB1FBB" >> Name="<dll name>" >> AssemblyVersion="1.7.2355.17871"/> >> <IPermission class="System.Security.Permissions.UrlIdentityPermission, >> mscorl >> ib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >> version="1" >> Url="<... dllpath ... >"/> >> <IPermission class="System.Security.Permissions.ZoneIdentityPermission, >> mscor >> lib, Version=1.0.5000.0, Culture=neutral, >> PublicKeyToken=b77a5c561934e089" >> version="1" >> Zone="Intranet"/> >> </PermissionSet> >> >> >> Also, is fx 1.1 installed on the fx 2.0 machine? >> Yes >> >> If so, are you sure that you've modified the CAS policy for 2.0 instead >> of 1.1 on that machine? >> Yes, they are both modified. >> >> If you're sure that you've modified the 2.0 policy >> Yes, definitly. >> >> Might it happen to be a 64-bit machine? >> No, 32 bit OS >> >> >> > > Sorry, my answer was a bit mistakable. The dll is .Net 1.1 compilated and
has not been touched in any of the described cases. Show quote "Markus Kling" <markus.kling@nospam.nospam> schrieb im Newsbeitrag news:e4SN%23zqlGHA.4772@TK2MSFTNGP04.phx.gbl... > 1) Sorry, I meant a caspol -a -resolvegroup output, like the one you > included in your first message. > > Level = Enterprise > Code Groups: > > 1. All code: FullTrust > Level = Machine > > Code Groups: > 1. All code: Nothing > 1.1. Zone - Intranet: LocalIntranet > 1.1.1. All code: Same site Web. > 1.1.2. All code: Same directory FileIO - Read, PathDiscovery > 1.5. StrongName - > 0024000004800000940000000602000000240000525341310004000001 > 0001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6ED165DFFE > E84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F559A54A50 > 5CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCCAC4D96E2C > CC2968AC2D3AA11DFB1FBB: FullTrust > > Level = User > Code Groups: > 1. All code: FullTrust > > > 2) Is being observed on _exactly_ the same assembly or whether it has been > modified in _any_ way (including recompilation with VStudio 2005) for 2.0. > > Yes! The machines running the dll for test purposes are even fresh > installed VPCs only having the latest servicepacks and .Net Framework > installed. > > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im > Newsbeitrag news:OSs6WnqlGHA.3632@TK2MSFTNGP03.phx.gbl... >> Sorry, I meant a caspol -a -resolvegroup output, like the one you >> included in your first message. Also, could you please confirm whether >> the problem is being observed on _exactly_ the same assembly or whether >> it has been modified in _any_ way (including recompilation with VStudio >> 2005) for 2.0. >> >> >> "Markus Kling" <markus.kling@nospam.nospam> wrote in message >> news:%238MJ7vUlGHA.3396@TK2MSFTNGP05.phx.gbl... >>> Nicole, >>> >>> What does the caspol output look like on the 1.1 machine? >>> >>> <PermissionSet class="System.Security.PermissionSet" >>> version="1" >>> Unrestricted="true"> >>> <IPermission >>> class="System.Security.Permissions.SiteIdentityPermission, mscor >>> lib, Version=1.0.5000.0, Culture=neutral, >>> PublicKeyToken=b77a5c561934e089" >>> version="1" >>> Site="<site>"/> >>> <IPermission >>> class="System.Security.Permissions.StrongNameIdentityPermission, >>> mscorlib, Version=1.0.5000.0, Culture=neutral, >>> PublicKeyToken=b77a5c561934e089" >>> >>> version="1" >>> >>> PublicKeyBlob="0024000004800000940000000602000000240000525341310 >>> 0040000010001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6 >>> ED165DFFEE84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F >>> 559A54A505CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCC >>> AC4D96E2CCC2968AC2D3AA11DFB1FBB" >>> Name="<dll name>" >>> AssemblyVersion="1.7.2355.17871"/> >>> <IPermission class="System.Security.Permissions.UrlIdentityPermission, >>> mscorl >>> ib, Version=1.0.5000.0, Culture=neutral, >>> PublicKeyToken=b77a5c561934e089" >>> version="1" >>> Url="<... dllpath ... >"/> >>> <IPermission >>> class="System.Security.Permissions.ZoneIdentityPermission, mscor >>> lib, Version=1.0.5000.0, Culture=neutral, >>> PublicKeyToken=b77a5c561934e089" >>> version="1" >>> Zone="Intranet"/> >>> </PermissionSet> >>> >>> >>> Also, is fx 1.1 installed on the fx 2.0 machine? >>> Yes >>> >>> If so, are you sure that you've modified the CAS policy for 2.0 instead >>> of 1.1 on that machine? >>> Yes, they are both modified. >>> >>> If you're sure that you've modified the 2.0 policy >>> Yes, definitly. >>> >>> Might it happen to be a 64-bit machine? >>> No, 32 bit OS >>> >>> >>> >> >> > > Might you be able to provide a sample (à la
http://www.yoda.arachsys.com/csharp/complete.html) that demonstrates the problem? What you're describing is very unexpected, and I cannot reproduce the problem in code that I've written myself. Show quote "Markus Kling" <markus.kling@nospam.nospam> wrote in message news:OcFh42qlGHA.4076@TK2MSFTNGP03.phx.gbl... > Sorry, my answer was a bit mistakable. The dll is .Net 1.1 compilated and > has not been touched in any of the described cases. > > > "Markus Kling" <markus.kling@nospam.nospam> schrieb im Newsbeitrag > news:e4SN%23zqlGHA.4772@TK2MSFTNGP04.phx.gbl... >> 1) Sorry, I meant a caspol -a -resolvegroup output, like the one you >> included in your first message. >> >> Level = Enterprise >> Code Groups: >> >> 1. All code: FullTrust >> Level = Machine >> >> Code Groups: >> 1. All code: Nothing >> 1.1. Zone - Intranet: LocalIntranet >> 1.1.1. All code: Same site Web. >> 1.1.2. All code: Same directory FileIO - Read, PathDiscovery >> 1.5. StrongName - >> 0024000004800000940000000602000000240000525341310004000001 >> 0001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6ED165DFFE >> E84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F559A54A50 >> 5CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCCAC4D96E2C >> CC2968AC2D3AA11DFB1FBB: FullTrust >> >> Level = User >> Code Groups: >> 1. All code: FullTrust >> >> >> 2) Is being observed on _exactly_ the same assembly or whether it has >> been modified in _any_ way (including recompilation with VStudio 2005) >> for 2.0. >> >> Yes! The machines running the dll for test purposes are even fresh >> installed VPCs only having the latest servicepacks and .Net Framework >> installed. >> >> >> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im >> Newsbeitrag news:OSs6WnqlGHA.3632@TK2MSFTNGP03.phx.gbl... >>> Sorry, I meant a caspol -a -resolvegroup output, like the one you >>> included in your first message. Also, could you please confirm whether >>> the problem is being observed on _exactly_ the same assembly or whether >>> it has been modified in _any_ way (including recompilation with VStudio >>> 2005) for 2.0. >>> >>> >>> "Markus Kling" <markus.kling@nospam.nospam> wrote in message >>> news:%238MJ7vUlGHA.3396@TK2MSFTNGP05.phx.gbl... >>>> Nicole, >>>> >>>> What does the caspol output look like on the 1.1 machine? >>>> >>>> <PermissionSet class="System.Security.PermissionSet" >>>> version="1" >>>> Unrestricted="true"> >>>> <IPermission >>>> class="System.Security.Permissions.SiteIdentityPermission, mscor >>>> lib, Version=1.0.5000.0, Culture=neutral, >>>> PublicKeyToken=b77a5c561934e089" >>>> version="1" >>>> Site="<site>"/> >>>> <IPermission >>>> class="System.Security.Permissions.StrongNameIdentityPermission, >>>> mscorlib, Version=1.0.5000.0, Culture=neutral, >>>> PublicKeyToken=b77a5c561934e089" >>>> >>>> version="1" >>>> >>>> PublicKeyBlob="0024000004800000940000000602000000240000525341310 >>>> 0040000010001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6 >>>> ED165DFFEE84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F >>>> 559A54A505CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCC >>>> AC4D96E2CCC2968AC2D3AA11DFB1FBB" >>>> Name="<dll name>" >>>> AssemblyVersion="1.7.2355.17871"/> >>>> <IPermission >>>> class="System.Security.Permissions.UrlIdentityPermission, mscorl >>>> ib, Version=1.0.5000.0, Culture=neutral, >>>> PublicKeyToken=b77a5c561934e089" >>>> version="1" >>>> Url="<... dllpath ... >"/> >>>> <IPermission >>>> class="System.Security.Permissions.ZoneIdentityPermission, mscor >>>> lib, Version=1.0.5000.0, Culture=neutral, >>>> PublicKeyToken=b77a5c561934e089" >>>> version="1" >>>> Zone="Intranet"/> >>>> </PermissionSet> >>>> >>>> >>>> Also, is fx 1.1 installed on the fx 2.0 machine? >>>> Yes >>>> >>>> If so, are you sure that you've modified the CAS policy for 2.0 >>>> instead of 1.1 on that machine? >>>> Yes, they are both modified. >>>> >>>> If you're sure that you've modified the 2.0 policy >>>> Yes, definitly. >>>> >>>> Might it happen to be a 64-bit machine? >>>> No, 32 bit OS >>>> >>>> >>>> >>> >>> >> >> > > Attached you find a demo project. I removed all unnecessary stuff as far as
reasonable to retain the fundamental code. - Build the project. The postbuild event of the WindowsControlLibrary1 project copies the WindowsControlLibrary1.dll to WebProject1 - Give the WindowsControlLibrary1.dll assembly full trust via strong name To Recreate: - Start WebForm1.aspx in your browser and drag one of the list elements to your desktop - You will see File1 or File2 beeing create in %TEMP% but not beeing moved to your desktop Disable Security caspol -s off and drag one of the files again -> voila. Thanks for your support Markus "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im [attached file: DragDropTest.zip]Newsbeitrag news:u8F3bKemGHA.4512@TK2MSFTNGP04.phx.gbl... > Might you be able to provide a sample (à la > http://www.yoda.arachsys.com/csharp/complete.html) that demonstrates the > problem? What you're describing is very unexpected, and I cannot > reproduce > the problem in code that I've written myself. > > I suspect that the problem is likely due to the changes in delegate
behaviour described at http://blogs.msdn.com/eugene_bobukh/default.aspx (and masked by a lovely bit of exception swallowing on the part of Control.DoDragDrop). If the new delegate creation-time cacheing does not take assertions into account (as would appear to be the case), there's essentially nothing you can do in your code to avoid the issue you are seeing. Instead, you would need to modify CAS policy to grant additional permissions based on URL evidence rather than strong name evidence. Show quote "Markus Kling" <markus.kling@nospam.nospam> wrote in message news:OStZ6RfmGHA.4772@TK2MSFTNGP04.phx.gbl... > Attached you find a demo project. I removed all unnecessary stuff as far > as reasonable to retain the fundamental code. > > - Build the project. The postbuild event of the WindowsControlLibrary1 > project copies the WindowsControlLibrary1.dll to WebProject1 > - Give the WindowsControlLibrary1.dll assembly full trust via strong name > > To Recreate: > - Start WebForm1.aspx in your browser and drag one of the list elements to > your desktop > - You will see File1 or File2 beeing create in %TEMP% but not beeing moved > to > your desktop > > Disable Security caspol -s off and drag one of the files again -> voila. > > Thanks for your support > Markus > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im > Newsbeitrag news:u8F3bKemGHA.4512@TK2MSFTNGP04.phx.gbl... >> Might you be able to provide a sample (à la >> http://www.yoda.arachsys.com/csharp/complete.html) that demonstrates the >> problem? What you're describing is very unexpected, and I cannot >> reproduce >> the problem in code that I've written myself. >> >> > > > "Does not take assertions into account": Ihmo an assertion must prevent the
stackwalk. Such this behavior would be wrong. Am I missing something. I think rather than the security that the change in Control.DoDragDrop to not masquerade all exceptions forces the native code to stop. What to do now? File a bug? Markus Show quote "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im Newsbeitrag news:O2etQHsmGHA.3796@TK2MSFTNGP05.phx.gbl... >I suspect that the problem is likely due to the changes in delegate > behaviour described at http://blogs.msdn.com/eugene_bobukh/default.aspx > (and masked by a lovely bit of exception swallowing on the part of > Control.DoDragDrop). If the new delegate creation-time cacheing does not > take assertions into account (as would appear to be the case), there's > essentially nothing you can do in your code to avoid the issue you are > seeing. Instead, you would need to modify CAS policy to grant additional > permissions based on URL evidence rather than strong name evidence. > > > "Markus Kling" <markus.kling@nospam.nospam> wrote in message > news:OStZ6RfmGHA.4772@TK2MSFTNGP04.phx.gbl... >> Attached you find a demo project. I removed all unnecessary stuff as far >> as reasonable to retain the fundamental code. >> >> - Build the project. The postbuild event of the WindowsControlLibrary1 >> project copies the WindowsControlLibrary1.dll to WebProject1 >> - Give the WindowsControlLibrary1.dll assembly full trust via strong name >> >> To Recreate: >> - Start WebForm1.aspx in your browser and drag one of the list elements >> to >> your desktop >> - You will see File1 or File2 beeing create in %TEMP% but not beeing >> moved >> to >> your desktop >> >> Disable Security caspol -s off and drag one of the files again -> voila. >> >> Thanks for your support >> Markus >> >> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im >> Newsbeitrag news:u8F3bKemGHA.4512@TK2MSFTNGP04.phx.gbl... >>> Might you be able to provide a sample (à la >>> http://www.yoda.arachsys.com/csharp/complete.html) that demonstrates the >>> problem? What you're describing is very unexpected, and I cannot >>> reproduce >>> the problem in code that I've written myself. >>> >>> >> >> >> > > > "Markus Kling" <markus.kling@nospam.nospam> wrote in message Inconvenient, but perhaps not "wrong". Depends on what the CLR designers news:%23JcPJynnGHA.3272@TK2MSFTNGP03.phx.gbl... > "Does not take assertions into account": Ihmo an assertion must prevent > the stackwalk. Such this behavior would be wrong. decided would be appropriate in this scenario. > Am I missing something. Unfortunately, since there's very little documentation available on the subject, it's quite difficult to know what the intended behaviour might be. > I think rather than the security that the change in Control.DoDragDrop to Couldn't hurt--at least it might get the right people looking at the issue. > not masquerade all exceptions forces the native code to stop. > > What to do now? > File a bug? In the meantime, you do have a known solution for your immediate problem: use URL evidence if the functionality cannot be changed. Show quote > > Markus > > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im > Newsbeitrag news:O2etQHsmGHA.3796@TK2MSFTNGP05.phx.gbl... >>I suspect that the problem is likely due to the changes in delegate >> behaviour described at http://blogs.msdn.com/eugene_bobukh/default.aspx >> (and masked by a lovely bit of exception swallowing on the part of >> Control.DoDragDrop). If the new delegate creation-time cacheing does not >> take assertions into account (as would appear to be the case), there's >> essentially nothing you can do in your code to avoid the issue you are >> seeing. Instead, you would need to modify CAS policy to grant additional >> permissions based on URL evidence rather than strong name evidence. >> >> >> "Markus Kling" <markus.kling@nospam.nospam> wrote in message >> news:OStZ6RfmGHA.4772@TK2MSFTNGP04.phx.gbl... >>> Attached you find a demo project. I removed all unnecessary stuff as far >>> as reasonable to retain the fundamental code. >>> >>> - Build the project. The postbuild event of the WindowsControlLibrary1 >>> project copies the WindowsControlLibrary1.dll to WebProject1 >>> - Give the WindowsControlLibrary1.dll assembly full trust via strong >>> name >>> >>> To Recreate: >>> - Start WebForm1.aspx in your browser and drag one of the list elements >>> to >>> your desktop >>> - You will see File1 or File2 beeing create in %TEMP% but not beeing >>> moved >>> to >>> your desktop >>> >>> Disable Security caspol -s off and drag one of the files again -> voila. >>> >>> Thanks for your support >>> Markus >>> >>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im >>> Newsbeitrag news:u8F3bKemGHA.4512@TK2MSFTNGP04.phx.gbl... >>>> Might you be able to provide a sample (à la >>>> http://www.yoda.arachsys.com/csharp/complete.html) that demonstrates >>>> the >>>> problem? What you're describing is very unexpected, and I cannot >>>> reproduce >>>> the problem in code that I've written myself. >>>> >>>> >>> >>> >>> >> >> >> > > I found a similar issue on Microsoft.Connect
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=94722 but I think our discussion is a bit more precise. You could probably vote for it ;) Thanks for your time! Markus Show quote "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im Newsbeitrag news:OAIean3nGHA.4604@TK2MSFTNGP02.phx.gbl... > "Markus Kling" <markus.kling@nospam.nospam> wrote in message > news:%23JcPJynnGHA.3272@TK2MSFTNGP03.phx.gbl... >> "Does not take assertions into account": Ihmo an assertion must prevent >> the stackwalk. Such this behavior would be wrong. > > Inconvenient, but perhaps not "wrong". Depends on what the CLR designers > decided would be appropriate in this scenario. > >> Am I missing something. > > Unfortunately, since there's very little documentation available on the > subject, it's quite difficult to know what the intended behaviour might > be. > > >> I think rather than the security that the change in Control.DoDragDrop to >> not masquerade all exceptions forces the native code to stop. >> >> What to do now? >> File a bug? > > Couldn't hurt--at least it might get the right people looking at the > issue. In the meantime, you do have a known solution for your immediate > problem: use URL evidence if the functionality cannot be changed. > > >> >> Markus >> >> >> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im >> Newsbeitrag news:O2etQHsmGHA.3796@TK2MSFTNGP05.phx.gbl... >>>I suspect that the problem is likely due to the changes in delegate >>> behaviour described at http://blogs.msdn.com/eugene_bobukh/default.aspx >>> (and masked by a lovely bit of exception swallowing on the part of >>> Control.DoDragDrop). If the new delegate creation-time cacheing does >>> not >>> take assertions into account (as would appear to be the case), there's >>> essentially nothing you can do in your code to avoid the issue you are >>> seeing. Instead, you would need to modify CAS policy to grant >>> additional >>> permissions based on URL evidence rather than strong name evidence. >>> >>> >>> "Markus Kling" <markus.kling@nospam.nospam> wrote in message >>> news:OStZ6RfmGHA.4772@TK2MSFTNGP04.phx.gbl... >>>> Attached you find a demo project. I removed all unnecessary stuff as >>>> far >>>> as reasonable to retain the fundamental code. >>>> >>>> - Build the project. The postbuild event of the WindowsControlLibrary1 >>>> project copies the WindowsControlLibrary1.dll to WebProject1 >>>> - Give the WindowsControlLibrary1.dll assembly full trust via strong >>>> name >>>> >>>> To Recreate: >>>> - Start WebForm1.aspx in your browser and drag one of the list elements >>>> to >>>> your desktop >>>> - You will see File1 or File2 beeing create in %TEMP% but not beeing >>>> moved >>>> to >>>> your desktop >>>> >>>> Disable Security caspol -s off and drag one of the files again -> >>>> voila. >>>> >>>> Thanks for your support >>>> Markus >>>> >>>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im >>>> Newsbeitrag news:u8F3bKemGHA.4512@TK2MSFTNGP04.phx.gbl... >>>>> Might you be able to provide a sample (à la >>>>> http://www.yoda.arachsys.com/csharp/complete.html) that demonstrates >>>>> the >>>>> problem? What you're describing is very unexpected, and I cannot >>>>> reproduce >>>>> the problem in code that I've written myself. >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> > >  |
|||||||||||||||||||||||
Other interesting topics