No remote context on CoreCLR ?
See original GitHub issueA seemingly simple operation of retrieving a remote context document appears not to be supported on .NET Core for some reason???
From https://github.com/NuGet/json-ld.net/blob/master/src/json-ld.net/Core/DocumentLoader.cs#L15
namespace JsonLD.Core
{
public class DocumentLoader
{
/// <exception cref="JsonLDNet.Core.JsonLdError"></exception>
public virtual RemoteDocument LoadDocument(string url)
{
#if !PORTABLE && !IS_CORECLR
. . . snipped . . .
return doc;
#else
throw new PlatformNotSupportedException();
#endif
}
Is this code being used in anger?
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:10 (6 by maintainers)
Top Results From Across the Web
Migration story for running untrusted code in CoreCLR ...
Searching the internet returns various references to AppDomains not being supported in CoreCLR, and various explanations as to why that is.
Read more >Errors occuring when running simple Hello World in Visual ...
None of that output is an error message. It says your program ran to completion successfully and then exited. The C# compiler does...
Read more >unable to attach to coreCLR acces denied
i was able to run .net core 2.2 projects without any problems before i update to Vs 16.9.? but after update nothing can...
Read more >Putting Mix, Silverlight, the CoreCLR and the DLR into ...
During the demo, ScottGu showed a Windows Developer connecting to a "CoreCLR Remote Debugging Service." The text "CoreCLR" appeared briefly ...
Read more >Remote Debugging a .NET Core Linux app in WSL2 from ...
I wanted to see if it's possible to do 'remote' debugging with WSL and Visual Studio (not Code) and if so, is it...
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
I have a patch for this which I can submit as a PR if you’re open to it. We need it in our codebase and I’d rather be referencing the nuget version than a private fork.
If so, perhaps we can just use milestones? Stalebot can exempt issues associated with milestones as well. If we have an idea of a version number, let’s use that as milestone name, otherwise we can just use
future
,next
or something similar?