Paket.PowerShell

[ctaggart]

This is just a design proposal right now with stuff stubbed out. There are two main purposes:

1. be able to run paket commands from the Package Manager Console in Visual Studio
2. have Visual Studio automatically do Paket-Restore when the solution is opened so that we finally have a workable solution for paket.targets per package #417

This can be make possible by having a single NuGet package, Paket.PowerShell, installed in packages.config.

I stubbed out the commands and it looks quite doable:

To do development of this, you just need to build the project and import:

That warning is suppressible. I did so in init.ps1. I found it much easier to start everything with Paket-.

[forki]

This looks interesting.

I think we need detailed docs on how to install / use this.

[ctaggart]

I think it may be good just to add it to the Paket NuGet package:

You would install Paket from the Package Manager Console and then you would have access to all the Paket commands.

Checking out the project for the first time with Visual Studio, the built in NuGet restore would restore Paket and then Paket-Restore in init.ps1 would restore everything managed by Paket.

[forki]

mhm. that's interesting, but at the moment most people install paket via the bootstrapper (without ever using nuget at all). this would only be something for you?

I wonder if this should be something in https://github.com/fsprojects/Paket.VisualStudio

[ctaggart]

I think this would be used by a lot of developers who just want to stay in Visual Studio. The PowerShell integration also doesn't require Visual Studio and makes it easier to use from build.ps1 files and from PowerShell in general. It is a very small addition to the nupkg.

[forki]

I don't mind to add the small file. But I don't really think people will use it like that.

Also it will not really work from inside VS since we still have the file locking issues from VS. We worked around that in the paket.visualstudio project by unloading and reloading projects.

[ctaggart]

The translation from PowerShell args to UnionArgParser args looks pretty straight forward. I implemented a couple commands with my last commit. My plan for deployment isn't working quite yet:

I'm not sure if the .exe assembly format is causing issues, if I messed up the .psd1, if I need to use Add-Type instead, or if FSharp.Core.dll dependency is an issue:

I'm hoping there is a clean solution.

[ctaggart]

When I Import-Module the dll and try to run a command, I get:

This looks like an FSharp.Core redirect issue. :/ Like this one:
SuaveIO/suave#158

[forki]

I think I'll trust you on this (since I'm not a heavy PS user). Just let me know when you think this is ready for prime time.

[ctaggart]

It is functional now. Several enhancements can be made, but the basics are in place. I ended up not modifying the paket package at all. Instead, I'm having it create a Paket.PowerShell package. I learned a lot. It is blog worthy, but time for bed.

[forki]

@latkin @enricosada I hope we can solve this issue with private debug info in F# vNext...

[enricosada]

i really hope so, see dotnet/fsharp#496 , the PTVS has it.
We can import PTVS code or use a new common project system
Pls @forki add yours missing features and bugs to issue, i'll check if PTVS supports it already

[forki]

Nice trick, but it doesn't work on "most" machines (ok at least not on my machine ;-) ).

can we find a way to do this directly in FAKE without calling Powershell?

[latkin]

Powershell.exe should be invoked with exra args "-executionpolicy bypass" so that it works even for those nonbelievers like @forki who don't use powershell and still have default Restricted policy ;-)

[forki]

actually I have "remote-signed", but I wonder if we can get rid of that step.

[forki]

@latkin doesn't seem to work?!

[forki]

seems to work if I change the order of the params as described in https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/

🚮

[latkin]

Ya, same as FSI - flags before the script arg are flags for the script engine, flags after the script arg are flags for the script itself.

[forki]

Cool, that makes totally sense as explanation.

[forki]

this is released in 1.13 - but I think we need some docs

[ctaggart]

Good morning. Thank you @latkin!
I'll probably collect some thoughts in a blog and then see what should go in docs.