More data: If I'm running Python from a Novell network share volume (that is, no local Python install) and try running a Python.NET script, I receive: Unhandled Exception: System.Security.Policy.PolicyException: Required permissions cannot be acquired. at CLRModule.initCLR() The script I'm running is simply a single line, "import CLR". Any tips from the .NET savvy programmers on the list? (Aside from: "Don't do that." ;) Additionally, I'm having trouble getting McMillan's installer to behave with the CLR imports. Is this something that may get resolved in the next beta? I've seen mention of switching to using the official import hooks in the TODO file in CVS. This sounds like something promising. TIA - It's really remarkable how well Python.NET works, and how simple it is to take C# code and convert it.
If I'm running Python from a Novell network share volume (that is, no local Python install) and try running a Python.NET script, I receive:
Unhandled Exception: System.Security.Policy.PolicyException: Required permissions cannot be acquired. at CLRModule.initCLR()
The script I'm running is simply a single line, "import CLR".
Any tips from the .NET savvy programmers on the list? (Aside from: "Don't do that." ;)
I'm guessing that the Python for .NET runtime dll isn't asserting some permission that is required to run off of the share - I'd appreciate any help from those more clueful than me as to what that permission is...
Additionally, I'm having trouble getting McMillan's installer to behave with the CLR imports. Is this something that may get resolved in the next beta? I've seen mention of switching to using the official import hooks in the TODO file in CVS. This sounds like something promising.
I've tried everything I can think of (including the new import hooks), but unfortunately there is no good way to take control during the actual import that bootstraps the CLR module. Any subsequent imports are not a problem. I __really__ wanted to make sure that imports would work in a consistent way whether you were running the managed python.exe or importing the CLR module into a stock Python, but that turns out to be a really tough problem, at least for that initial import. I'm not sure if that's related at all to the McMillan installer issue (I'm not familiar with it), just me ranting ;) Can you give me a little more detail on the issue you're seeing?
TIA - It's really remarkable how well Python.NET works, and how simple it is to take C# code and convert it.
Thanks! Its good to hear that its useful to people! Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
--- Brian Lloyd <brian@zope.com> wrote:
I'm guessing that the Python for .NET runtime dll isn't asserting some permission that is required to run off of the share - I'd appreciate any help from those more clueful than me as to what that permission is...
Turns out the Novell fileshare is, to .NET, part of the "Local Intranet" ... Going to the .NET framework wizards in the control panel and adjusting security of "Local Intranet" to full trust has solved the problem. Woohoo! I solved that after finding a related message on microsoft.public.dotnet.general that clued me in. This means I have to do this on every machine I want to run my app from. Of course, I was going to have to install the .NET framework on all those machines anyway, so no biggie :) I hope this message saves someone else some grief.
Additionally, I'm having trouble getting McMillan's installer to behave with the CLR imports. Is this something that may get resolved in the next beta? [snip] Can you give me a little more detail on the issue you're seeing?
You mean telling you, "it goes boom!" isn't enough? <wink> Actually I need to re-install McMillan's installer and give it another go. IIRC, McMillan's installer does lot of inspection of the source file you give it, and processes imports itself. In my recollection, it tried to import the CLR module and then add attributes to it, choking followed... I'll take another look at it and get back to you as well as its author. Basically, I'm just testing all the deployment options I have if I want to deploy a PythonNet app to a bunch of people. I'll test the network-homed deploy further tomorrow and see if it continues to work OK.
participants (2)
-
Brian Almond -
Brian Lloyd