Relevant dependencies (DLL) not being copied when deploying using Visual Studio 2013

Question

In one of the webjobs I'm deploying, I'm referencing one of my class libraries (Core) that is taking care of running some process (in this case sending an email using SendGrid).

When I deployed my webjobs manually (uploading .zip file) everything worked fine. I cleaned up the deployment and re-deployed using Visual Studio 2013 and the webjob started to have problems. The main issue here is that it's looking for the SendGrid dll that's referenced by my Core class library and not my Console app and it's not finiding it throwing the following error:

"Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'SendGrid.... Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"

I FTP'd into the website and found that effectively the SendGrid assembly is not where my WebJob is at.

My question is: is there a way to force that this dependencies get copied to the right directory when deploying using VS 2013?

Thanks,

Answer 1

I'm a member of the team who put the WebJobs tooling out in the Summer 2013 Update, and I can let you know we're aware of this issue and have checked in a fix for it for the next update, which is coming out soon. In the meantime, the workaround is to set assembly references to the assemblies you need - the NuGet packages alone will do solve this issue - and re-publish. We actually use a NuGet package to do our deployment logic for WebJobs within VS. Once we release the update, we'll also release the NuGet (which is going through final testing now), so customers on the Summer and Fall updates will have this issue mitigated.

Answer 2

It seems like this is a known bug from Microsoft and unfortunately they dont seem too eager to fix it. Possible solutions:

1. You can either manually copy it over
2. Create a build event to copy it over
3. Seems some people have had luck adding something like this var t = typeof(ThirdParty.SomeClass);

Answer 3

Solved my issue by doing the following.

1. Set your referenced assemblies "Copy Local -> True"
2. Set your solution configurations to "Release"