I'm developing customisation for NX generally in the form of compiled dlls written in VB.
I've had a few instances where I compile and sign (in the NX sense of the word) on my laptop.
When I copy the dll over to the client system the code fails to run.
In one instance they had visual studio installed on the test machine and if the code was compiled on this machine it would then run the dll.
To clarify the dlls in these instances were being run locally on the test machine, and not on a network.
I'm aware that in certain instances you need to trust network locations to allow the dll to run from a non local location.
This leads me to think that there is something set in the group policy or elsewhere in the .net framework set up that isn't allowing the code to run.
This leads me to my question (finally....)
If I used strong-name signing (signing the vb project, not the normal nxopen signing process) would this cure the types of problems I've seen?
Thanks in advance,
Some things to check: Do you have the correct version of the .Net Framework installed on all machines?
Are you building in Release mode? Microsoft does not allow redistribution of their debug libs, and we have had reports from customers that they were not able to run a .DLL built in debug mode on any machine without the Studio installed. This can cause the "...or one of its dependencies" situation.
And finally, be sure you are building for "x64", not ANY_CPU if you are using NX9 or higher.
If you still have trouble, please log an IR with GTAC and we will try to help you untangle it.
Thanks for the reply.
I've finally got my hands on the log files with one of the issues I was seeing.
The exact error is:
System.TypeInitializationException: The type initializer for 'Remoting_Server.NXModule' threw an exception. ---> System.IO.FileLoadException: Could not load file or assembly 'NXOpen, Version=10.0.0.24, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) ---> System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Program Files\Siemens\NX 10.0\ugii\managed\NXOpen.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
So this seemed to be telling me it couldn't load the NXOpen.dll file.
I copied the dll to the same folder as the Remoting_server.dll file and still I got the same error.
When compiled and signed on my laptop but run on the test system I always got this error.
The only thing that solved this one was to re-compile on the test machine that I was trying to run the dll on.
I did this by copying the whole project over to the test system and compiling on that. So no changes in the project files.
I checked .net version and they were the same.
The error message seemed to be pointing me in the direction of the dll not having permissions and suggests network locations, but that just doesn't make sense.
I was wondering wether there could be another issue with their setup only alowing strongly named/signed applications.
In reply to your comments about project setup.
I have always compiled in debug mode and so far haven't found this to be an issue at all. I have succesfully deployed upwards of 30 individual projects on one site and none of them are compiled as release. All are functioning in NX10.
Very few of the 50+ machines will have visual studio installed, so I'm surprised by that comment?
I can't say that this one has given me any issues so far either. However, as NX is only supported on 64bit systems now, I've swithced all of my projects over to build specifiaclly to x64.
I'm guessing this one may be hardware dependant.
If you do a Google search on the error:
Exception from HRESULT: 0x80131515
You can see that it is not exactly uncommon. (That one comes from the OS, rather than from NX code.) We have had a small number of reports of that error and some of them are very hard to isolate a cause for.
There is one thing you can check pretty easily, but there is no guaratee that this will be the cause. Start with this file, mentioned in your log:
C:\Program Files\Siemens\NX 10.0\ugii\managed\NXOpen.dll
Find it in a File Explorer window, MB3 on it and hit Properties. At the bottom of the Properties dialog, is there a warning that the file has been "blocked"? If so, there should be a method provided to un-block it.
Run the same check on all of the .DLL's in the ...ugii\managed folder.