Remove reference to System.CommandLine in the SDK

[bamarsha]

This dependency should be gotten transitively from the CsharpGeneration package now.

[anpaz]

Actually, could we please remove the dependency to CSharpGeneration from the generated standalone executables?
CSharpGeneration is very heavy as it adds transitively dependencies to both Roslyn and F#, so now all Q# execs inclode those dlls in their output.
This probably means that we need to extract the EntryPoint into its own library.

[bamarsha]

Do you mean that EntryPointDriver.dll being in the same NuGet package as C# generation is causing C# generation to be a required runtime dependency for standalone executables? I'm not sure why that would happen since the EntryPointDriver.dll assembly is separate (despite being in the same package) and does not depend on C# generation.

[bamarsha]

EntryPointDriver.dll does depend on the Microsoft.Quantum.Compiler package, though, which we might want to change. That would bring in FSharp.Core and some other packages but I don't think it should bring in CsharpGeneration.

[bettinaheim]

@SamarSha I think the description in the PR may have caused some confusion.

[anpaz]

Yes, I mean that EntryPointDriver.dll being in the same nuget package as CSharpGeneration is causing it to be marked as a runtime dependency and the dlls are getting copied to the output folder:

BernsteinVazirani\bin\Debug\netcoreapp3.1>dir *csharp*
 Volume in drive C is OSDisk
 Volume Serial Number is 5E0B-15A4

09/12/2019  05:08 PM         5,218,168 Microsoft.CodeAnalysis.CSharp.dll
09/12/2019  05:09 PM           761,208 Microsoft.CodeAnalysis.CSharp.Workspaces.dll
05/14/2020  01:06 AM           185,776 Microsoft.Quantum.CsharpGeneration.dll
05/14/2020  12:41 AM            36,352 Microsoft.Quantum.CsharpGeneration.EntryPointDriver.dll
               4 File(s)      6,201,504 bytes

[anpaz]

Maybe is not because is not in the same package, but I suspect that is that reason. I would push it to its own package, that way you can mark the dependency to CsharpGeneration to be just for compile time and not include any of its resources in the output.

[bamarsha]

I am not sure that bin\Debug\netcoreapp3.1 is the right folder to look at. When I use the latest stable SDK package (Microsoft.Quantum.Sdk 0.11.2004.2825), then I also see those DLLs in that folder (minus Microsoft.Quantum.CsharpGeneration.EntryPointDriver.dll, which didn't exist yet), as well as FParsec and FSharp.Core, even though the entry point DLL isn't part of the CsharpGeneration package in that version.

I think the folder that contains runtime assets would be bin\Debug\netcoreapp3.1\publish (after running dotnet publish). For me, that folder is identical in both the old and new SDK versions. Actually, I think this is also a problem since it means that Microsoft.Quantum.CsharpGeneration.EntryPointDriver.dll is missing at runtime:

PS C:\Users\samarsha\Desktop\TestProject2\bin\Debug\netcoreapp3.1\publish> .\TestProject2.exe
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Quantum.CsharpGeneration.EntryPointDriver, Version=0.11.2005.1407, Culture=neutral, PublicKeyToken=null'. Das System kann die angegebene Datei nicht finden.
File name: 'Microsoft.Quantum.CsharpGeneration.EntryPointDriver, Version=0.11.2005.1407, Culture=neutral, PublicKeyToken=null'

That is probably because CsharpGeneration is tagged with PrivateAssets="All". So I agree that we want to include EntryPointDriver.dll without also including the rest of the CsharpGeneration package, which might mean creating separate packages, or maybe putting the DLL in a separate folder and using one of the more specific PrivateAssets options to specify which folders to keep at runtime.

I'd still like to merge this PR for now, since currently the dependency on System.CommandLine is specified in two places (CsharpGeneration and Quantum SDK), and I think that even if EntryPointDriver.dll is split into its own package, the dependency on System.CommandLine should go in that package instead of the SDK. But I'll keep looking into the packaging issue.