Cannot compile queries using nuget package Microsoft.CodeAnalysis 2.0.0 #13
Comments
|
I prepared a LINQPad query as you described and named it The output from the compilation was: The compilation was indeed unsuccessful because the C# compiler emitted the following error: I suspect that the following warning has something to do with (i.e. no references found): Since most of the libraries in those packages target .NET Standard 1.3, I also tried invoking |
|
Indeed, without specifying the target, the default compilation target of linqpadless is used, so it's Patch from #17 makes correct use of target framework ('-fx' key). Results of testing: -fx=net462 or -fx=netstandard1.3
Error details: |
|
The type in case is residing in Microsoft.Composition package. But there's #20 |
|
With #16 and #20 resolved, the compilation now fails due to the following error from the C# compiler: That happens when targeting .NET Framework 4.6. When targeting 4.6.2 instead, compilation passes but running the executable throws the following error: The and The The actual version of <dependentAssembly>
<assemblyIdentity name="System.Collections.Immutable"
publicKeyToken="b03f5f7f11d50a3a"
culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.2.1.0"
newVersion="1.2.1.0" />
</dependentAssembly>It seems then that |
|
I remember dealing with similar issues. If there's no API level compatibility issues (missing types, signatures, members) dynamic assembly resolution might work. A good example can be found in somewhat related issue for scriptsc. And implementation. Thoughts? |
|
@vcaraulean Thanks for the scriptcs pointers, and yeah, I thought of dynamic assembly resolution too but at this stage things seem to be getting quite complicated and I'm wondering if the scenario of compiling to C# script versus an executable is buying anything extra. After all, it's not like the C# interpreter is readily downloadable from anywhere (even keeps moving locations and redistribution channels) so it's only good for environments where the build tools are installed. With NuGet integration, compilation and more, I fear that LINQPadless might end up replicating the complexity of the build process and artifacts (developer packs, references per target framework, forwarded types, facades) & package installation. @wangzq took an interesting approach with lpmake where he compiles the LINQPad query to a project and then leverages the build tools to do all the heavy-lifting. With LINQPadless, the goal was having few files to manage and distribute ( |
|
This issue is really about how to get correct assembly references from a nuget package for a specific framework version. This used to be easier with just .NET 4.x, with NetStandard it is getting more complicated. In lpmake I am relying on project.json to figure out the correct references for me, but it also stopped working for recent packages such as 2.0 of Microsoft.CodeAnalysis. My plan is to either learn more about how Linqpad is able to do that, and/or check if the new msbuild is able to solve this problem. |
Looks like C# interpreter is available as part of Microsoft.Net.Compilers so doesn't require a Microsoft Build Tools 2015 installation. |
To repro, create a new query and add nuget package Microsoft.CodeAnalysis which is 2.0.0, add following code:
Add missing namespace imports and ensure it works in Linqpad.
Now try to generate an exe with lpless, it will fail to compile since it cannot correctly add the assemblies from the nuget package.
The text was updated successfully, but these errors were encountered: