I have a project with an action list that runs a couple of python scripts that works fine. When trying to run the action list from another project using the "Include project" i get the following error:
Error loading Script Engine : Dynamic Language Runtime is not installed or is not accessible.
Is this a limitation ? or a bug? Really would like to keep these action lists in a seperate project file if possible to keep my projects looking clean.
I just tried this here on my home machine (vista business x64) using 6.3.0.1472. Worked fine. Are you able to narrow this down to an example that reproduces the problem? If so please send it to support at finalbuilder dot com
The Project works in the IDE on our server machine, but not when running within FinalBuilder Server on the server machine.
Perhaps you can clarify where the FinalBuilder Server gets its settings from? Specifically, the Script Option that points at the Python lib, which I needed to update to get the IDE to work at first. (Note: Since getting the IDE to work, I have rebooted the server machine and FinalBuilder Server still gets the Dynamic Language Runtime issue.)
How does FinalBuilder Server know where to look for Python lib? Or is FinalBuilder Server just invoking FinalBuilder IDE? If so, why does it run correctly in the IDE and not via the Server? I’ve also noticed a situation where the Server runs something correctly but the IDE on the same machine does not. This is also related to paths (“make.exe” must be changed to “c:\cygwin\bin\make.exe” to work in the IDE, even when the “c:\cygwin\bin” is the first item in the PATH environment variable).
You have to manually browse to the Python Lib folder in the IDE for it to work every time you start the IDE. As you can’t do this with the Server version, it doesn’t work EVER!
There are three main ways to get the IDE to have the Dynamic Runtime issue: * type in the wrong path or don’t set it - fair enough, I accept this is my fault! * type in the correct path, rather than browse to it - this is clearly a bug! * browse to the right path, but then restart IDE, expecting it to still work - this is clearly a bug
Note that once you have it working in the IDE, without restarting, you can do these things and it will still work: * type in the correct path over the top of the path you browsed to - seems sensible! * type in a dodgy path over the top of the working path you browsed to - well, I guess you did say you only look at the value when you restart * browse to an incorrect folder - as above
Final observations: * you can manually go to the right folder and choose OK, and then immediately (without running a Project) manually go to the wrong folder and hit OK, and then run your Project and it will WORK! * BUT if you manually go to the wrong folder and hit ok and then immediately manually go to the right folder and hit ok then it will still work. * My guess is that you try to invoke python on each manually selected path and only when python actually runs is this remembered
I don’t know if this is an issue with Included Projects or normal Projects, but I expect you will easily be able to solve this if you look at your source code.
Please get back to me with a fix ASAP because this is holding us up in a big way and I have already spent a few days on this.
We were not able to reproduce the issue here, even using your steps on several machines. I suspect this is an installer issue. Part of the problem is the installer is copying the DLR (Microsoft.Scripting.*) and IronPython assemblies to two folders. It’s possible that there is an older version of the assemblies in the FinalBuilder folder. Try deleting these dlls in the FinalBuilder Folder :
The only change we made today was to improve the error handling so that we can see the actual cause of the error, and fixed the installer so that the files are not duplicated.
If this build does not work, then check the GAC for the above mentioned assemblies. Incredibly, the CLR looks at the GAC first, then the application folder and then the private bin folders (we add the IronPython subfolder as a PrivatePath to the appdomain). Welcome to dll hell version 2. If the IronPython assemblies are GAC installed, then you will have to removed them from the GAC for FinalBuilder to work correctly. FinalBuilder doesn’t GAC install the IronPython assemblies, but it’s possible another application does.
Perhaps you can clarify where the FinalBuilder Server gets its settings from? Specifically, the Script Option that points at the Python lib, which I needed to update to get the IDE to work at first. (Note: Since getting the IDE to work, I have rebooted the server machine and FinalBuilder Server still gets the Dynamic Language Runtime issue.)
The Python Lib Option is stored in the user's FinalBuilder6.ini file, which on Vista lives in :
If you are running FBServer, or the projects in FBServer as a different user then you will need to log into the machine as that user and open the FinalBuilder IDE and set the option appropriately. Note that this option just tells IronPython where to find the lib files, and has nothing to do with IronPython failing to load at all.
I'm in two minds as the whether this option should be stored at a machine level or at a user level. It's difficult to change this now without potentially breaking users builds, so if it is changed at all it will have to wait till the next major version.
I have had to do the reinstall and now I get a slightly more useful error message:
Error loading Script Engine : Dynamic Language Runtime is not installed or is not accessible. System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Scripting, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The specified module could not be found. File name: ‘Microsoft.Scripting, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ —> System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E) at VSoft.DLRHost.DLRHost…ctor() at VSoft.DLRHost.IronPythonHost…ctor()
I notice that the supplied Microsoft.Scripting.dll is v1.11020.0.0. Any ideas what is happening?
HOORAY! I have found exactly what is going wrong and can see why you couldn’t reproduce it.
My FinalBuilder project runs a DOS command before the Python Run Script action.
I have no idea why this makes it break, but I have confirmed this is the reason by having a single Project with only two actions:
1. DOS command (“dir”, no wait for completion) 2. Run Python Script (print “hello”)
This gives me the following error in the IDE and the Server:
Error loading Script Engine : Dynamic Language Runtime is not installed or is not accessible. System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Scripting, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The specified module could not be found. File name: ‘Microsoft.Scripting, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ —> System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E) at VSoft.DLRHost.DLRHost…ctor() at VSoft.DLRHost.IronPythonHost…ctor()
You have to disable the DOS command (or move it below the the Run Script action) to make it work.
Note that once it is broken, you need to restart the IDE to make it work after you have fixed it.
Also note that you can do all the Python you want after the DOS command providing you do at least one Python action before the DOS command. In other words, the DOS command does not break subsequent Python if you have managed one successful Python.
Well, I am very relieved to have solved this because I have spent a number of days trying to work out why it is broken. I’m sure my manager will be even happier.
Now only two questions remain: what prize have I won and do you have any jobs going in Australia?
Well, you nailed it on the head. We were able to reproduce the problem here using the Run Dos command trick. The bug was introduced in the recent 6.3 update, it has to do with turning off wow64 file system redirection when running windows (ie in the System32 folder) executables. I'll have to put my hand up for this one as I was the person who made the change. Paul figured it out this morning (before I even made it to the office), and we have a fix available :
We'll be issuing an official update in the next day or so.
As for prizes and jobs, well we do have a position for .net developer open, however we're not in a position sponser anyone's visa applications. Australia's a tough place to get into, I've been here for 13+ years, and wouldn't move back to uk for any money (well ok, everyone has a price, it's just that mine is not really affordable!).
I can’t say I fully understand all of the explanation, but as long as you understand it then that’s good enough for me
Thanks for the patch, I will apply it today.
I’m glad you are enjoying Australia. (The UK isn’t too bad really, if you set your expectations very low.) I think this job will be more enjoyable too now this peculiar behaviour has been resolved.
