Assembly.Location not returning correct value #1073

brettsam opened this Issue Dec 22, 2016 · 2 comments


None yet

4 participants


A recent update changed the way that private assemblies were being loaded from the bin directory. A side effect of this is that now calls to Assembly.Location return an empty string. Some libraries depend on this, and as such, aren't functioning properly.

While we work on a fix, there are two workarounds:

Workaround 1 -- Move the assembly to a different folder:

  1. Move your assembly to a folder named something other than bin. For example, sharedfolder.
  2. Update your references to match the relocated assemblies. For example #r ..\sharedfolder\assembly.dll
  3. Restart the site by clicking Function app settings, then Go to App Service Settings, and clicking Restart at the top of the opened portal blade.

Workaround 2 -- Revert to the previous Functions version:

  1. In the portal, click Function app settings
  2. Click Configure app settings
  3. In the App settings section of the new portal blade, set FUNCTIONS_EXTENSION_VERSION to 1.0.10661 and click Save. This will restart your site and configure it to use the previous version. Note that you will need to reset this value to ~1 in order to receive future updates.
@fabiocav fabiocav self-assigned this Dec 22, 2016
@guitarrapc guitarrapc added a commit to guitarrapc/AzureFunctionsIntroduction that referenced this issue Dec 27, 2016
@guitarrapc guitarrapc avoid issue : Azure/azure-webjobs-sdk-script#1073 by change reference…
… dll location
@guitarrapc guitarrapc referenced this issue in guitarrapc/AzureFunctionsIntroduction Dec 27, 2016

Avoid Assembly.Location not returning correct value issue #3

guitarrapc commented Dec 27, 2016 edited

It also happen on me 6days ago and Workaround 2 completely avoid issue, thank you very much for share!

My situation was here.

  1. Using Roslyn Compiler service inside Azure Functions to evaluate C# Code requested from Slack.
  2. Issue happen when loading Assembly info at

Issue fix at my environment with following commit.


Appreciate for advice! Great help.


@guitarrapc thank you for sharing the details! I'm glad the workaround addressed the issue without requiring you to target the previous version.

As mentioned on the Twitter conversation, we'll be addressing this issue. Apologies for the inconvenience.

@christopheranderson christopheranderson added this to the Next - Triaged milestone Jan 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment