Fix dependency resolution for PCL assemblies
See original GitHub issueI dont know if this is a script host bug or a project oxford bug package bug or something else but I found this behavior strange.
Steps to reproduce:
Add a project.json that references project oxford computer vision api:
{
"frameworks": {
"net46":{
"dependencies": {
"Microsoft.ProjectOxford.Vision": "0.5.0.1"
}
}
}
}
Attempt to use the SDK from an async function:
#r "Microsoft.WindowsAzure.Storage"
using System;
using System.Threading.Tasks;
using Microsoft.WindowsAzure.Storage.Blob;
using Microsoft.ProjectOxford.Vision;
public static async Task Run(ICloudBlob myBlob, TraceWriter log, IAsyncCollector<object> document)
{
var visionClient = new VisionServiceClient("asdf");
var result = await visionClient.RecognizeTextAsync(myBlob.Uri.ToString(), "en");
var words = from r in result.Regions
from l in r.Lines
from w in l.Words
select w.Text;
var output = string.Join(" ", words.ToArray());
log.Verbose($"Recognized words: " + output);
myBlob.Metadata["ocr"] = output;
await myBlob.SetMetadataAsync();
var doc = new {
Id = myBlob.Uri,
Type = "ImageDocument",
Words = words
};
await document.AddAsync(doc);
}
Expected result: compiles successfully. Actual result:
2016-03-28T02:44:04.588 Script for function 'ocrtest' changed. Reloading.
2016-03-28T02:44:04.588 Compiling function script.
2016-03-28T02:44:04.713 (12,37): error CS0012: The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
2016-03-28T02:44:04.713 (12,24): error CS0012: The type 'Task<>' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Threading.Tasks, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
2016-03-28T02:44:04.713 Compilation failed.
The workaround is to add the following but why is this necessary?
#r "System.Runtime"
#r "System.Threading.Tasks"
#r "System.IO"
Issue Analytics
- State:
- Created 7 years ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
Xamarin - Could not load assembly 'PCLStorage.Abstractions
Adding the nuget package PclStorage v1.0.2 to the PCL project resolves both warnings and the deployment error. I'm not sure why this dependency...
Read more >Gotcha With DNX Dependency Resolution, the 'dotnet' ...
As part of that update, we re-added the classic PCL target .NETPortable,Version=v4.5 ... Collections Unable to resolve dependency fx/System.
Read more >Resolve problems related to System.Diagnostics.Tracing ...
PCL case study: How can I resolve problems related to System.Diagnostics.Tracing for the Microsoft TPL Dataflow NuGet package?
Read more >Xamarin.IOS and ServiceStack Dependency Issue
I am hoping someone has some insight on how to resolve this issue. ... NET Framework assemblies, they're all included as part of...
Read more >Linking User assemblies causes FreshMvvm to not work
For example, when trying to resolve a dependency using FreshIOC.Container.Resolve<ISettingsHelper>().Get(Constants.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@sxmichael , this is indeed a known issue/limitation involving PCL scenarios. ( SO answer on rlthis here http://stackoverflow.com/questions/40192646/azure-function-consuming-onedrive-api-returns-compile-errors/40195875#40195875)
Skipping the details of the underlying root cause, this is a nuance when referencing PCLs and we do have some options planned to remove the requirement, but your workaround is the correct approach at the moment.
I’ll reopen this so it is tracked
Most scenarios impacted by this (including the ones mentioned here) should be addressed with #1049, which will be in our next release.