Hi all
I’m using FinalBuilder 8.0.0.2228 on a Windows Server 2012 R2 machine.
Our new web hosting is switching to using SFTP rather than FTP.
I was adding SFTP actions to our FinalBuilder scripts to replace the FTP ones and now get this really long validation error when loading the project:
Error Validating action :: System.IO.FileNotFoundException: Could not load file or assembly ‘VSoftSFTPLibrary’ or one of its dependencies. …
It trails off to the right and I couldn’t copy the error to the clipboard to capture the whole thing. Is there someway to capture the whole message?
Anyway, if I look in the FinalBuilder 8 directory there is indeed no VSoftSFTPLibrary.dll present in that directory assuming that’s where it’s looking.
How might I resolve this? Has something gone wrong with the installer to not place that file there?
Cheers,
Paul.
Hi Paul
The assembly (and it’s dependencies) lives in the ActionDefs\Assemblies\4.0 folder under the FinalBuilder 8 directory.
It also depends on :
SecureBlackbox.dll
SecureBlackbox.SFTP.dll
SecureBlackbox.SFTPCommon.dll
SecureBlackbox.SSHClient.dll
SecureBlackbox.SSHCommon.dll
If any of those are missing then a re-install will be needed. I would also check if your antivirus software is messing with the install.
Also, FinalBuilder 8 needs the .net framework version 4.0 installed (although the installer does check for that).
I just installed the same build on server 2012 R2 and was able to create a project, add all the sftp actions, and run validation (lots of errors, but none about loading the assembly).
I hate to say this (since it’s a standard support answer), but did you try rebooting. I’ve had issues with dll’s not loading after installing software that magically disappeared after rebooting, so it might be worth a try.
If you send your project to support at finalbuilder.com we can see if we can reproduce the problem here, although I doubt it’s a project specific issue.
OK, I’ve checked and all those files are present in the indicated directory.
I’m restarting the server now to see if that helps.
I can also repro the problem on our other older build server which is running Server 2008 R2.
I’ll try creating a fresh project and see if the action validates OK inside that.
Cheers,
Paul.
OK, I’ve restarted, created a new project with a single SFTP action and tried turning off Symantec temporarily. No joy.
When it fails on Finalbuilder startup, it gives more easily capturable details so I’ve included a screenshot:
Next, I’ll might try a ProcMon trace and see if I can determine whether it finds the dll in question.
Cheers,
Paul.
As far as .NET frameworks, I have 4.6 installed. FinalBuilder 8 is all working fine apart from SFTP. I tried running the 4.0 .NET framework installer and it said a later version was already present. Does SFTP specifically need .NET framework 4.0 to be installed?
Ok, After fighting with ProcMon for a bit, I can see the attempt to find VSoftSFTPLibrary.dll but it only shows it looking in the FinalBuilder 8 directory and nowhere else. It doesn’t look down in the ActionDefs directory. Is that path configured somewhere in an FinalBuilder.ini or something similar?
I still have Final Builder 7 installed so I tried an SFTP Connect with that and get the same issue.
I tried copying those DLLs into the FinalBuilder 8 directory (just to see if it was some kind of missing path configuration issue) and whilst it no longer fails with VSoftSFTPLibrary not found, instead it gives an “unable to create an instance of VSoft.SFTP.SFTPConnect”.
Obviously it works for you and other people, yet it looks like SFTP use is impossible with FinalBuilder for us.
Hi Paul,
We are wondering if its just the SFTP actions or whether its other actions are also at issue. Would you be able to also test just the FTPS actions to see if they load?
Another test here would be to remove FinalBuilder 7 and 8 from the machine and then install just FinalBuilder 8 to see if there is some issue with capability that we are unaware of. We have designed them so they can be installed on the same machine, although they do need to be installed to their own folders.
Ah, Interesting. Both the FTPS and SSH Connections options fail in exactly the same manner.
I’ve uninstalled FinalBuilder 7 and 8 on the Server 2008 R2 machine (our fallback server) and I’ve just reinstalled FinalBuilder 8.0.0.2228 afresh.
Once the server has restarted, I’ll try again.
Ok, After restart with only FinalBuilder 8 freshly reinstalled, it still fails.
I didn’t wipe out FinalBuilder8.ini in the APPDATA before reinstalling. Should I have?
Cheers,
Paul.
Hi Paul,
Yes back these settings up by renaming the AppData\FinalBuilder 8 folder, also the FinalBuilder 7 folder if its there.
Ok, Uninstalled it, renamed APPDATA\FinalBuilder 7 and 8, Reinstalled FinalBuilder8 and still fails as before.
Any other suggestions?
Hi Paul,
We will need to perform fusion logging to figure about why the binaries are not loading. To enable this on the machine using the following steps:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Add:
DWORD ForceLog set value to 1
DWORD LogFailures set value to 1
DWORD LogResourceBinds set value to 1
DWORD EnableLog set value to 1
String LogPath set value to folder for logs (e.g. C:\FusionLog)
Once this is done, load FinalBuilder 8 again and you should get a log generated in C:\FusionLog\ (or the directory you choose). Please send us that log to support@finalbuilder.com.
Once you have done this please reverse the above setting so that fusion logging is turned off. Having it on does slow binary loading.
Ok. I generated the Fusion log files and figured I’d have a quite look in them before sending them off and I noticed a strange path listed as the Initial PrivatePath which contained the value of one of my environment variables that I use to globally configure my FinalBuilder projects.
I had an environment variable called RELPATH which contains where our release builds are to be copied to and that was being picked up by the .NET Assembly loader for the FinalBuilder 7 and 8 PrivatePaths which was defeating where it would normally provide the Assemblies subfolder (I’m guessing).
When I removed that from the environment, the assembly loading errors stopped so I’m hoping SFTP will work now. Of course, I’ll need to go through all my FinalBuilder projects (ugh) and change the RELPATH references to RELXPATH but at least it’s working.
Is a RELPATH environment variable an (un)documented part of .NET Assembly loading or does FinalBuilder expand RELPATH itself for it’s PrivatePath?
Cheers,
Paul.
Ah, just found that RELPATH is an undocumented environment variable for futzing with PrivatePath handling for .NET assembly loading as an alternative to DEVPATH.
http://geekswithblogs.net/akraus1/archive/2009/05/14/132125.aspx
Hi Paul
Wow, that is just an evil environment variable. Might as well have called it TEMP! Nice find, at least we will have it here in the forums for future reference. This issue has had us stumped for the last few days trying to figure out what is going on as non of it made any sense. There’s many hours we’ll never get back (customer and vendor) thanks to this. I googled this variable and didn’t come up with much, not sure what search terms you used, must have better google foo than me!