@davidanthoff are you able to load this dll on mac side without pythonnet, e.g. from powershell or scriptcs?

Hi, @denfromufa thanks and sorry for the delay.
The library works when loading from mac powershell
The problem seems to be not the content of the library, but the path of the dll.
For instance,

   clr.AddReference(r'/Users/pfsteam/Desktop/XXXX/YYYY/TestLibrary.dll')

works perfectly, but fails with System.Exception: File is blocked (NTFS Security) error if I try to do:

   clr.AddReference(r'TestLibrary.dll')

The path of the Python scripts is obviously /Users/pfsteam/Desktop/XXXX/YYYY

Just for completeness, you are also running from this path?

Hi @filmor,
Yes, I'm running from this path

I see the same issue on windows 7 with a DLL built internally in the company, and distributed via nuget
Python 3.7.1 (anaconda), pythonnet installed from git a couple of hours ago (pythonnet-2.4.0.dev0 according to pip install - I guess it must be this commit 3e4ebac - it' the first time I tried installing packages this way)

I believe this PR is what has introduced at least the error message: #655

So far I have been unable to find a format of the path that will allow me to add the reference to the DLL

I investigated a bit and found I could test this "security zone" from powershell ($name being the full path of the DLL):

PS C:\****> [System.Security.Policy.Zone]::CreateFromUrl($name).SecurityZone
MyComputer
PS C:\****> [System.Security.SecurityZone].GetEnumValues()
MyComputer
Intranet
Trusted
Internet
Untrusted
NoZone
PS C:\****> [System.Security.SecurityZone]::MyComputer
MyComputer
PS C:\****> [System.Security.SecurityZone]::MyComputer.value__
0
PS C:\****> [System.Security.Policy.Zone]::CreateFromUrl($name).SecurityZone.value__
0

That looks ok according to the change, so I am at a loss for what might be the actual issue here

@icetiger1974 any idea, multiple people (@davidguaita @Zleep-Dogg @amRsching) have issues with your PR?

@Zleep-Dogg can you check the security zones from python+pythonnet session like you did from powershell? It looks like NoZone should be added to the accepted list. Powershell may have different settings.

Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> import System
>>> import System.Security
>>> from System.Security import Policy
>>> Policy.Zone.CreateFromUrl('Python.Runtime').SecurityZone
-1
>>> from System.Security import SecurityZone
>>> SecurityZone.MyComputer
0
>>> SecurityZone.Intranet
1
>>> SecurityZone.Trusted
2
>>> SecurityZone.Untrusted
4
>>> SecurityZone.NoZone
-1

@denfromufa
I've run these several lines of codes you just posted. What I get is exactly the same as yours. (Python 3.7.0, Windows 10)

I guess this problem may be related to the Windows 10 new feature - "zone information".

The DLL files I want to use are all compressed in a zip file that I downloaded from the website.
Because the DLL file I want to add is extracted from the zip file, these DLL files may not have the corresponding "zone information", which may cause I can't successfully addReference on Windows 10.

I get the same results in PS and python - here on windows 7.

Here is an example to share, not using the company DLL's, and using latest pythonnet from git cloning with pip (2.4.0.dev0 - I assume it must be d3ca2e8 though it's not really visible anywhere):

C:\Windows\System32>python
Python 2.7.15 |Anaconda, Inc.| (default, Nov 13 2018, 17:33:26) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> import System
>>> import System.Security
>>> from System.Security import Policy
>>> clr.__version__
'2.4.0.dev0'
>>> Policy.Zone.CreateFromUrl(r'C:\Windows\System32\crypt32.dll').SecurityZone
0
>>> Policy.Zone.CreateFromUrl('crypt32.dll').SecurityZone
-1
>>> clr.FindAssembly('crypt32')
u'crypt32.dll'
>>> clr.AddReference('crypt32')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
System.IO.FileNotFoundException: Unable to find assembly 'crypt32'.
   at Python.Runtime.CLRModule.AddReference(String name)
>>> clr.AddReference('crypt32.dll')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
System.Exception: File is blocked (NTFS Security)
   at Python.Runtime.CLRModule.AddReference(String name)
>>> clr.AddReference('C:\Windows\System32\crypt32.dll')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
System.IO.FileNotFoundException: Unable to find assembly 'C:\Windows\System32\crypt32.dll'.
   at Python.Runtime.CLRModule.AddReference(String name)

Oh, and the results are btw the same in python 3.7.1

crypt32.dll is not .NET dll.

Ah, sorry, just picked a random one that I figured should be on most people's PC.
But the result is exactly the same when I use the same method on a .NET dll provided by the "PC tool department", so I assume the errors arise before loading is actually attempted?

(Disclaimer: I am by no means fluent in .NET, C# or Windows, so I will easily hit pitfalls - I mostly work with C, assembly and a bit of python, and prefer working on linux, when not at work)

@Zleep-Dogg would you like to contribute a PR to fix this? Probably only add NoZone (-1) to the accepted security zone in pythonnet. Test it on your machine and no unit test is required (hard to reproduce).

Also if someone can document differences between Win7/10 security zones - that would be great. I have no idea about this.

I won't have time this side of xmas, (the pythonnet work is sort of a side project to easily automate stuff otherwise only provided in GUI tools) - possibly after

I am experiencing the same issue on Windows 7 with Python 3.7 and pythonnet 2.4.0.dev0. I am trying to use a DLL file that is being used by another program in Windows. When I open the 3rd party program it works fine. But when I try to add it in python,
clr.AddReference('MyDesired.dll')

I get,

Exception: File is blocked (NTFS Security)
   at Python.Runtime.CLRModule.AddReference(String name)

I have followed the SecurityZone heck above and I get the same NoZone:

Policy.Zone.CreateFromUrl('Python.Runtime').SecurityZone
Out[53]: -1

Any suggestions? Or should I wait for a bug fix?