Allow environment variables in #r interactive directive

[xperiandri]

With introduction of dnx all the packages are located at path %UserProfile%\.dnx\Packages
How to reference assemblies there?
This workaround does not work for me.

Repro steps

I tried

open System
open System.IO
let pathToPackage package =
    let packagesFolder = Path.Combine(System.Environment.GetFolderPath(System.Environment.SpecialFolder.UserProfile), @".dnx\packages\")
    Path.Combine(packagesFolder, package)

let referncedFolders =
    [ pathToPackage @"FunScript.TypeScript.Binding.angular\1.1.0.37\lib\net40\" ]

#r "EnvDTE"
#r "EnvDTE80"
#r "VSLangProj"

let appObj = System.Runtime.InteropServices.Marshal.
               GetActiveObject("VisualStudio.DTE") :?> EnvDTE80.DTE2
let solnDir = Path.GetDirectoryName(appObj.Solution.FileName)
let cfg = appObj.Solution.SolutionBuild.ActiveConfiguration.Name

//#r libraryDLL  // illegal, since #r takes a string literal, but...
let props = appObj.Properties("F# Tools", "F# Interactive")
let cla = props.Item("FsiCommandLineArgs")
cla.Value <- sprintf "--optimize -I:\"%s\"" (String.concat "\" \"" referncedFolders)

appObj.ExecuteCommand("View.F#Interactive", "")
appObj.ExecuteCommand("OtherContextMenus.FSIConsoleContext.ResetSession", "")

Expected behavior

It is possible to reference an assembly from a path with environment variable

Actual behavior

The is no way to load assemblies from path other than relative except this enormous approach
https://github.com/nrolland/FStat/blob/master/FStat/scriptSetup.fsx

Related information

• Windows 8.1 x64 UKR
• F# 4.0
• FSX
• Visual Studio 2015 Enterprise Update 2

[smoothdeveloper]

@xperiandri I believe what is needed is to make fsi expose some hooks for #r parsing, people would like to reference nuget packages or similar type of extension.

The same way fsi.AddPrinter we could have fsi.AddHashReferenceDirectiveResolver that allow to hook up custom resolution, where you can implement environment variable resolution or others.

[KevinRansom]

Oooo I like this ... although it will be really painful to diagnose errors due to missing environment variable values.
.

[forki]

Please be very careful here. As discussed in many places I think this is
not the solution to nuget issues. They removed the packages folder, but we
should fight to get it back and currently everything is changing. So please
please please be careful here.
On May 12, 2016 9:27 PM, "Kevin Ransom (msft)" notifications@github.com
wrote:

Oooo I like this ... although it will be really painful to diagnose errors
due to missing environment variable values.
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1177 (comment)

[KevinRansom]

It never even occurred to me this would be used to locate nuget packages. Although I can see how it might be used for that.

[forki]

The thing is: I'm not completely arguing against adding environment
variable support. It's just that I think we should not do that just to
locate nuget packages. The current nuget situation is not good and it
should be fixed instead of "fixing" fsi. Tbh with all my recent tests I'm
not completely sure if it would be even enough to locate the packages in
all circumstances.
On May 13, 2016 12:58 AM, "Kevin Ransom (msft)" notifications@github.com
wrote:

It never even occurred to me this would be used to locate nuget packages.
Although I can see how it might be used for that.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1177 (comment)

[dsyme]

At the high level

• I'm OK with adding environment variable support to #r.
• I'm totally in favour of making it possible to find nuget v3 DLLs from F# scripts
• I'm in favour of making it possible to reference nuget packages with #N (or #r if that's what C# Interactive uses)
• I'd also love it if it were possible to reference & resolve Paket dependencies from scripts.

So, I'd love to be able to do all of that. We just need to get there...

[smoothdeveloper]

@dsyme I've seen https://github.com/fsprojects/IfSharp/blob/master/src/IfSharp.Kernel/NuGetManager.fs#L212

Could we somehow make a single extensible way of parsing #r that would call to registered custom handlers if the reference doesn't resolve?

It doesn't feel right to bake this Nuget v3 support right into fsi.exe (also listing the dependencies, in correct order for correct platform out of a nuget package is not trivial) while if fsi.exe had custom and extensible --add-reference-handler:myhandler.dll arguments, I'm sure the community would provide a well maintained set of handlers.

C# interactive as far as I know doesn't do anything with nuget packages.

[smoothdeveloper]

Bonus points if people responsible for C# interactive would collaborate on single API for handlers implementation.

[dsyme]

Could we somehow make a single extensible way of parsing #r that would call to registered custom handlers if the reference doesn't resolve?

The main problem is that this must be available to the Langauge Service (FCS/VisualStudio/...) tooling as well or else you won't get intellisense etc. So the references need to be in-script, such as

#r "references:nuget-handler.dll"  // specially attributed DLL
#r "SomeNugetPackage"

This makes these components much like type provider components (run at design-time).

[smoothdeveloper]

It is not a problem then : #r handler:"myhandler.dll" 😄

[smoothdeveloper]

the #r protocol:"uri" convention might be a good idea

[forki]

I heard rumors that the packages folder might come back.
On May 19, 2016 12:49 AM, "Gauthier Segay" notifications@github.com wrote:

the #r protocol:"uri" convention might be a good idea

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1177 (comment)

[smoothdeveloper]

@forki, the idea of handlers with the protocol scheme that @dsyme mentioned would be great (and maybe a default one for nuget shipped with the whole ecosystem), although it is always a problem to get the right handlers in place where we can reference them.

I've heard other rumours about dotnet cli which might using paket as the defacto nuget client in the future 😄 joking of course...

[forki]

I assume the final dotnetcli product will still have something like the current project.lock.json file. So if that's the case then we would need to read that. But we have to wait a bit longer. Currently everything is rumors. Or maybe even less than rumors.

[smoothdeveloper]

I think this feature is blocked by #1311 which might uncover some technical debt or at least some technical issues with reference resolution (in the context of tooling for the issue, but I think this still applies).

@dsyme what do you think? should we add Blocked label to this issue?

[gulshan]

Related- dotnet/roslyn#5654

[aaronpalmer]

Has there been any movement on this issue? I have a team that would like to have a common set of fsx scripts referencing a common set of packages that will be on each of our machines at the location of %userprofile%\.nuget\
We currently have to either alter the #r paths to be specific to our profile, or we have to move the packages to a share - both options are not ideal. It would certainly make life easier to have the ability to use the environment variable in #r.

[dsyme]

No movement

@cartermp What do you think of this feature?

[aaronpalmer]

Another option that would be nice is to provide a way to directly access nuget packages via a configurable package manager. Config could be in the fsi.exe.config, and would provide nuget repository configuration. Then a new directive (#p for package) could be used that would allow you to specify a nuget package id and optional version to pull that package directly from the configured nuget repository.

Perhaps:
#p "My.Nuget.Package"
// gets latest version

#p "My.Nuget.Package" "1.0.1"
// specifically gets version 1.0.1 of My.Nuget.Package

[baronfel]

@aaronpalmer funny you should mention that: #5850

[cartermp]

I expect package references will take care of the need here

[aaronpalmer]

@cartermp I agree, and actually prefer the package reference option to the environment variable option.

For my purposes, it would need to be able to resolve nuget package references whether run from an fsx in Visual Studio or in VS Code. So ideally the package management configuration would be available from fsi itself.

[KevinRansom]

Thanks for this suggestion,

#r "nuget: " is in development (preview). We are not likely to want to add parameterized dll references, as it makes it harder to reason what is happening from just the source code.

Thanks

Kevin