Are you trying to run a .DLL or a .EXE? If it is a .EXE, be sure to copy ...ugii\managed\NXOpen*.DLL into the folder where your .EXE lives.
In general we have not seen people having trouble running NXOpen .Net code from a shared drive when using versions of the Framework greater than 2.0. However we occasionally talk to someone who finds that his computer is seeing a mapped drive as part of the INTERnet, rather than the local INTRAnet.
If you need more detailed assistance with this, please create an IR with GTAC.
I've just posted a similar question myself here regarding running .dll's over the network, so I'm hoping you might be able to provide some guidance. We don't really want to lower the security level of the company to run these things is there another way?
We have a number of 3rd party apps that we have purchased which can only be run by copying the application onto the users c: drive which isn't ideal.
We would like to centralize these thing but we're struggling.
i've posted a copy of the sort of errors that are being generated
Loaded assembly: Microsoft.VisualBasic, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a from C:\Windows\assembly\GAC_MSIL\Microsoft.VisualBasic\22.214.171.124__b03f5f7f11d50a3a\Microsoft.VisualBasic.dll
Loaded assembly: System.Drawing, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a from C:\Windows\assembly\GAC_MSIL\System.Drawing\188.8.131.52__b03f5f7f11d50a3a\System.Drawing.dll
Caught exception while running: Main
System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
The action that failed was:
The type of the first permission that failed was:
The first permission that failed was:
if you are using dll on network path maybe changing security for a specific path where you have stored the dll can help
%PATH_TO_YOUR_FRAMEWORK_INSTALLATION%\caspol -q -force -rg 1.6.
caspol -q -machine -addgroup 1. -url %PATH_TO_YOUR_FOLDER%\* FullTrust
but it influence security
You only need to change the trusting level for .NET 2.0
I run the following on 32-bit and 64-bit Windows.
"%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\caspol.EXE" -q -m -cg LocalIntranet_Zone FullTrust
The following must only be run on 64-bit Windows, so you could remove the architecture check.
if %PROCESSOR_ARCHITECTURE% == AMD64 "%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\caspol.EXE" -q -m -cg LocalIntranet_Zone FullTrust
Production: NX10.0.3, VERICUT 8.2, FBM, MRL 3.1.7 | TcUA 10.1 MP7 Patch 0 (10.1.7.0) | TcVis 11.4
Development: C (ITK), .NET, Tcl/Tk Testing: NX12.0 | AWC 3.4 Preparing: NX12.0
Employees of the customers, together we are strong
How to Get the Most from Your Signature in the Community
NX Customization - Best Practice Guide
We've come across teh same issue and started looking into signing the assemblies using a strong name. This should allow them to be run off of the network without needing to change the zone security.
The problem we ran into here is the NX DLLs are not signed with a strong name. Visual Studio does not allow signing a DLL with a strong name if any of the dependencies are not signed. There is an article which describes how to sign 3rd party DLLs but we never went down that road.
Article about signing DLLs
Article about signing 3rd party DLLs