Showing results for 
Search instead for 
Do you mean 
Reply
Solved! Go to solution

Run application from shared network drive

Hi All,

 

How can I set my .NET application to full trust and run it from shared network drive?

 

My environment:

NX9.0, .NET framwork 4.5

 

Thanks

 

Terry

5 REPLIES
Solution
Solution
Accepted by topic author terchan1
‎08-26-2015 04:32 AM

Re: Run application from shared network drive

 

Terry,

 

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.

 

Regards,

 

Steve

 

Re: Run application from shared network drive

 

Hi Steve,

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

 

JSON

 

 

 

Loaded assembly: Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a from C:\Windows\assembly\GAC_MSIL\Microsoft.VisualBasic\8.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualBasic.dll

Loaded assembly: System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a from C:\Windows\assembly\GAC_MSIL\System.Drawing\2.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll

Caught exception while running: Main

System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

at GenerateAdaptiveGeometricPoints.GenerateAdaptiveGeometricPoints.Main()

The action that failed was:

Demand

The type of the first permission that failed was:

System.Security.Permissions.SecurityPermission

 

The first permission that failed was:

 

Re: Run application from shared network drive

Hello,

 

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

 

Greetings

 

Re: Run application from shared network drive

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

 

Stefan Pendl, Systemmanager CAx, HAIDLMAIR GmbH
Production: NX10.0.3, VERICUT 8.0, FBM, MRL 3.1.4 | TcUA 10.1 MP7 Patch 0 (10.1.7.0) | TcVis 10.1
Development: VB.NET, Tcl/Tk    Testing: NX11.0 EAP, NX12.0 EAP

How to Get the Most from Your Signature in the Community

Re: Run application from shared network drive

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

http://blogs.msdn.com/b/shawnfa/archive/2003/06/20/57023.aspx

 

Article about signing 3rd party DLLs

http://ryanfarley.com/blog/archive/2010/04/23/sign-a-.net-assembly-with-a-strong-name-without-recomp...