Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When .NET Core 3.1 installed, "Cannot compile typed context" error #19

Closed
sblom opened this issue Jan 1, 2020 · 4 comments
Closed

When .NET Core 3.1 installed, "Cannot compile typed context" error #19

sblom opened this issue Jan 1, 2020 · 4 comments

Comments

@sblom
Copy link

sblom commented Jan 1, 2020

When running LINQPad 6 (have tried both 6.5.5 and 6.6.1) with .NET Core 3.1 installed, I get an error when attempting to interact with connections that use the Azure Storage Driver:

Error: Cannot compile typed context: Assuming assembly reference 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' used by 'Madd0.AzureStorageDriver' matches identity 'System.Runtime, Version=4.2.2.0, Culture=neu

(the tooltip is truncated at that point)

If only netcore3.0 is installed, everything works fine.

If netcore3.1 and netcore3.0 are both installed, it fails. If only netcore3.1 is installed, it fails.

@madd0
Copy link
Owner

madd0 commented Jan 2, 2020

That's strange, I have both SDKs installed and have had LinqPad use both runtimes without any problems. The error sounds familiar though.
I'll try to take a look at it before going back to work on Monday, but for the moment, I can't reproduce

@sblom
Copy link
Author

sblom commented Jan 2, 2020

I wonder if it matters what version(s) were installed when I first made use of the driver. Let me try reinstalling the driver and some other things like that. Do you know much about how LINQPad handles dependency resolution for storage drivers?

@madd0
Copy link
Owner

madd0 commented Jan 2, 2020

As far as I know, in LinqPad 6, Nuget does all the dependency resolution.
What I have so far is that since the driver currently targets netcoreapp3.0;net46, I guess if only netcore3.1 is installed, it might be normal that it won't work. I'm guessing that, in a fresh environment, the driver shouldn't even install if only netcore3.1 is installed, but you're still seeing it from LinqPad's cache or something.
Best clue for now is to update the package to target both netcore3.0 and netcore3.1. I'll publish a new version on Nuget as soon as it's done ;)

madd0 added a commit that referenced this issue Jan 4, 2020
From #19, targeting only netcore3.0 might be a problem when only the 3.1 SDK is installed.
The plugin can be compiled with both SDKs and only 3.1 is LTS so it's as good a time as any to start targeting the newer version.
@madd0 madd0 closed this as completed in 8614c97 Jan 5, 2020
@madd0
Copy link
Owner

madd0 commented Jan 5, 2020

@sblom new package published, let me know if it solves the problem 😉

madd0 added a commit that referenced this issue Feb 4, 2020
This is a workaround for issue #20, which appears to be the opposite of #19. In the latter, the driver was given .net core 3.1 references when it was trying to target 3.0. This time, the driver is given 3.0 references while trying to target 3.1.
It looks like LinqPad is downloading the 3.1 version of the driver, which tries to generate a dynamic assembly by targeting 3.1 too. This is necessary because the generated code references the driver assembly, which in this scenario targets 3.1. However, LinqPad is providing reference assemblies for .net core 3.0, which results in a compiler error.
I talked about the problem with Joe Albahari and hope that in the future the driver will be able to request version-specific reference assemblies from LinqPad. In the meanwhile, since the dynamic assembly should be 3.0-compatible if it doesn't reference the 3.1 driver itself, I have removed the reference and am now compiling the required classes with the rest of the code. This way, whether LinqPad provides 3.0 or 3.1 references, the generated code is totally agnostic and works with both.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants