Open rmshaffer opened 4 years ago
Relatedly (?), it could be useful to have a way to be able to point at a directory containing a locally built qsharp-runtime in the process of compilation in general, independent of the SDK. (I'm not familiar enough with the msbuild/nuget ecology to know if there's an easy way to override such resolutions from the outside.)
I was just trying to run a "Hello World" using a locally built compiler. The suggested test in the README.md of printing "Hi from your locally built compiler!"
on startup gave me the message. But after that, I received an error regarding SyntaxExtensions coming from qsharp-runtime's CSharpGeneration. This is described in another issue as being due to the runtime being out of sync with the compiler.
It seemed like it would be forward-looking to figure out how to build the current qsharp-runtime and point to a local copy of that. This was difficult (for me). The CSharpGeneration DLL location doesn't seem to have any override in the SDK itself, the way you can specify <QscExe>
and <QscBuildConfigExe>
(Note: the latter option is not documented in the SDK Readme, is that intentional?)
What happens is that if you have <CSharpGeneration>
as true, you get hardcoded versions of dependencies coming from SDK.props, in the case of CSharpGeneration it is:
<PackageReference Condition="$(CSharpGeneration)"
Include="Microsoft.Quantum.CSharpGeneration" Version="0.15.2101126940" IsImplicitlyDefined="true"
IsQscReference="true" ExecutionTarget="Any" Priority="-1" PrivateAssets="All" />
This leads to an absolute path in a generated file called build.config
...which makes its way to a --load
parameter in qsc.rsp
. You can manually edit the qsc.rsp file and put a path to your own built copy of Microsoft.Quantum.CSharpGeneration.dll
and it works. But the files are regenerated each time you build.
I tried setting <CSharpGeneration>
to false, and then manually adding an <AdditionalQscArguments>
with a --load
of the locally built CSharpGeneration dll. But that dropped a lot of other things out of the --references
list that were needed.
In lieu of a better answer, being able to specify <QscBuildConfigExe>
, permits one to use a hacked up BuildConfiguration.Generate...which permits being arbitrarily invasive on the config generation process.
Is your feature request related to a problem? Please describe. In latest beta builds from
master
, the language server is creating a temporary project to compile and provide IntelliSense features for.qs
files that do not have an associated.csproj
file in the folder.The temporary
.csproj
file generated contains a reference to theMicrosoft.Quantum.Sdk
version that matches the version of the currently-installed extension (specifically, the version of the language server that is running). There is no way to customize the version of theMicrosoft.Quantum.Sdk
reference.Describe the solution you'd like For testing purposes it would be useful to have a setting to specify a different
Microsoft.Quantum.Sdk
version. It would also be nice to log the version ofMicrosoft.Quantum.Sdk
used at the time the.csproj
is generated.Describe alternatives you've considered No real alternatives here other than manually installing a different version of the extension and/or editing the
.csproj
manually after it is generated, neither of which are reasonable workarounds.