So i am using this 3rd party API in one of my applications. Both the
DLL for the API and my executable sit on a network drive for everyone
to access. Therefore all of the machines in my company have code
groups set up to allow the application to run.
For a large majority of the 80 or so machines, this works beautifully.
I've identified 4 machines that give this error:
"Exception Occured. Request for the permission of type
System.Security.Permissions.SecurityPermission, mscorlib,
Version=1.0.5000.0, Culture=nuetral, PublicKeyToken=b77wrfewreq34rfq
failed."
When comparing the code groups on the different machines, I see that
they are all the same. On the machines the application works, it works
100% of the time. On the machines it does not work, it fails 100% of
the time, aside from one case. When the .Net Configuration 1.1 Tool in
"Administrative Tools" is open, you do not get the error message. It's
as if having the tool open puts the machine into some other state and
allows my app to run properly. Then when I close the tool, i go back
to getting the error message.
Can anyone make any sense out of this and possibly suggest a solution?
Thanks,
Mike
Alvin Bruney [MVP] - 06 Oct 2007 03:09 GMT
Yup, it makes sense to me. The first thing i would do is turn CAS policy off
on the sick machine. If you are still having an issue it is NOT related to
CAS. If it is, then you simply need to tweak CAS policy to allow the
assembly to download correctly.

Signature
Regards,
Alvin Bruney
------------------------------------------------------
Shameless Author Plug
OWC Black Book 2nd Edition
Exclusively on www.lulu.com/owc
$24.99
> So i am using this 3rd party API in one of my applications. Both the
> DLL for the API and my executable sit on a network drive for everyone
[quoted text clipped - 22 lines]
> Thanks,
> Mike
Michael.Suarez@gmail.com - 09 Oct 2007 16:14 GMT
Alvin,
Thank you very much for the response. Even though the Code groups were
set up exactly the same on the two machines, I actually just replaced
the security.config file on the "sick" machine with the
security.config file on the working machine, and that seemed to do the
trick.
-Mike
On Oct 5, 10:09 pm, "Alvin Bruney [MVP]" <some guy without an email
address> wrote:
> Yup, it makes sense to me. The first thing i would do is turn CAS policy off
> on the sick machine. If you are still having an issue it is NOT related to
[quoted text clipped - 42 lines]
>
> - Show quoted text -