I'm trying to add an Assembly Execute task to a job and have noticed that when the target class tries to load a type from another assembly (not in .Net framework) it fails to run.
I have made sure all the secondary assemblies that are required are present in the working directory but nothing seems to resolve the dependency issue.
The app.config file is loaded as are the sections that are defined in the configuration file.
The target .net framework is 4.5.2

Any useful ideas will be appreciated

Have you tried running Fuslogvw.exe? It's useful in cases where it cannot find the assemblies. The log will show where it is looking for the assemblies (which folders, Gac and so on)

I have run that tool but nothing shows up on the UI.
Should the tool be pointed at Visual Cron logs or does it automatically pick up assembly binding failures?

Place it on the server where VC is installed, go to settings, click Log bind failures (or all binds if you want). Run the VC job that fails, and check the log. Remember to turn of logging when done. Post the log here, if you want some help with it. I am not an expert, but I spent 2 weeks last year dealing with dll nightmares, so I may be able to help out. One thing that can easily go wrong, is when VisualCron har installed the same assemblies as you use, but a different version. We use ITextSharp.dll for example, and so does VisualCron. They use a different version from us, and so the .NET runtime cannot find the version we use. There a different ways of solving this issue.

Thomas

The VC server is installed on my machine but the logging tool still doesn't pick up any information on screen. I have tweaked the settings between "all bindings" and "binding failures" - neither has any effect. Does the tool have to be in the same physical folder as VC?

Would you know if VisualCron uses a different version of Newtonsoft.json.dll?

Any assistance you can offer would be really appreciated.

Hi



Yes VC uses Newtonsoft. I don't know which version of VC you use. This (image) is the version in 8.3.3. Try right-click and run Fuslog as admin and set a custom path, just to make sure we know where the log is supposed to end up



Edit: Fuslog can be placed anywhere on the same machine, as far as I know

It is possible you have to add a registry key

https://stackoverflow.co...re-logging-fusion-in-net 

It has been a long time since I set this up, so I cannot remember if this is really necessary

Ok, setting the custom log path seems to have made the tool work
I have now attached the generated log files  NETExecute40.zip (3kb) downloaded 43 time(s).

I am running 8.3.2 of VC

Here is the code of the method the Assembly Execute task is trying to run


If I comment out lines 31-33, the task executes fine

It seems it is looking for PLedge.Remote.dll, but with a partial bind warning it is more tricky. It does not seem to be looking for the assembly in the GAC in that case. What is the Nuget package behind Credential.Decrypt?

I have to run now. Poker game tonight

Anyway, here is one thing you can try. It may not be the best solution, but it is a useful test, just to see if it works. Go to the installation folder of VC.
C:\Program Files (x86)\VisualCron. Create a folder called assemblies. Put all the assemblies from your project in there. Then go to NETExecute40.exe.config (In the installation folder of VC), right click and open in notepad.



Add the runtime section from the picture. Go to the VisualCron task and call the assembly from this new location , and see if it works.

It's not pretty, but the trouble is that with partial binding you cannot use the GAC. From the log you can see it checks a couple of config files, and that's all. This also means you have to add this section in the config file every time you upgrade VC (the assembly folder stays untouched even on upgrade)..... Support can probably come up with something better.

Have a nice weekend

Thanks I will give that a try and let you know how I get on.
I hope you clean up at poker! 🙂

After deconstructing my assembly and putting it back together a bit at a time, I've finally found out the cause of the problem.
VC seems unable to load custom sections in a configuration file that deserialize into a known type in code.





Additionally, the app domain that VC must be creating to load these libraries is unale to cope with minimum versions for referenced assemblies.
For example a nuget package that states it that it needs a minimum of v6.0.4 of Newtonsoft.json.dll to run will not work if v9.0.1 is loaded.



Is there a way you can assist with this? We intend to create additional custom tasks in the future and we won't always be able to work around these problems.

This is quickly getting outside my area of expertise 😢 Hopefully support can come up with something better. The way I understand it, it works roughly like this (take it with a huge pinch of salt):

1) When you execute a .Net task in VC, the excuting program is NETExecute40x86.exe, located in the VC installation folder C:\Program Files (x86)\VisualCron

2) It then checks the app.config file to see which assemblies to load. The way the .NET runtime searches for assemblies is described in this article below.

https://docs.microsoft.c...ntime-locates-assemblies 

3) For strongly named assemblies, it will first look in the GAC (Global assembly cache), but this does not work for partially bound assemblies. So your Newtonsoft problem is easy to fix (it is strongly named). Just add to the GAC. If you don't do this, it will attempt to load the Newtonsoft library that VisualCron is using. This is a different major version from what you are using, and so it fails.

4) The other one, pledge.remote is the more tricky one, since it is partially bound. It won't look in the GAC, and just gives up as it cannot find it in C:\Program Files (x86)\VisualCron. That is why we have created a subfolder C:\Program Files (x86)\VisualCron\Assemblies where we place our assemblies. In the NETExecute40x86.exe.config we have added a probingPath, where we tell it to look in this folder for assemblies. Unfortunately this has to be a subfolder to the executing program, which kind of sucks. But this is outside the control of VC.

To load assemblies into the GAC, I like to use the GAC manager which is open source and free. https://www.codeproject....-Manager-Utility-and-API . Just download, place it on the server, and do File => Add.

I believe you can also use the machine.config file to tell the runtime where to look for assemblies, but I have never tried this. Just note that this is not really a VC issue, it's just that working with dll's is a nightmare, and especially the partially bound ones. I would try very hard to avoid those type of assemblies (ie look for another library that is strongly named and does a similar job)