Source items in NuGets, e.g. bootstrap, jquery etc. not handled yet?

[bartelink]

I'm using the F# MVC 5 template addin to wizard up a WebApi app (targetting FW 4.5.1).

The bootstrap (v3.2) package (and I think jquery which it depends on too) seems not to be extracting files when listed in the Paket.references.

The bootstrap NuGet has source files 2 levels nested (a fonts folder, some Scripts and some Content) and install seems to ignore them. So I let it and jquery be managed by NuGet (which croaks with a nullref every 2 seconds).

[forki]

Yes Scripts and Content folders are not handled yet. Would you volunteer?

[bartelink]

I'd love to but I can't spread myself too thin right now - I have a backlog of OS and CS work at the minute.

I will continue to beta test Paket in the context of the CS work but there's just too much yakshavery infrastructure stuff (which will go into FunDomain).

But watch this space :D

[theimowski]

Are we also gonna make use of PowerShell? Nuget uses it when installing/uninstalling packages: http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#Automatically_Running_PowerShell_Scripts_During_Package_Installation_and_Removal

[agross]

@theimowski I think it's not possible. NuGet command line doesn't run install.ps1 and probably for a good reason: you don't have access to the VS environment that you can query/modify in the script.

[forki]

No. I don't want to go this route.

FYI: FAKE.deploy can run FAKE scripts (fsx) in nuget packages. ;-)
On Sep 10, 2014 5:08 PM, "Alexander Groß" notifications@github.com wrote:

@theimowski https://github.com/theimowski I think it's not possible.
NuGet command line doesn't run install.ps1 and probably for a good
reason: you don't have access to the VS environment that you can
query/modify in the script.

—
Reply to this email directly or view it on GitHub
#65 (comment).

[bartelink]

@agross Yes, there's not much meaningful out of a .ps1 file without the banana pulling the VS rainforest with it.

One potential thing though is token replacement and/or source file substitutions which should be considered part of this (i.e. its pretty common for source projects to have $projectNamespace$ tokens and then the upgrade needs to see whether the file has any changes (other than the replacement of these tokens) and maybe require a --force to do the replace to align with NuGet non-destructive behaviour (though obv one would hope that people wouldnt edit source files and/or would be regularly committing to source control and be able to diff/revert as necessary)

[ilkerde]

Please don't do any pre/post-execution using anything that is provided in packages. This is one of the worst features of nuget. It was only invented for VS conveniences and causes a lot of troubles and misuses.

Apart of that, Powershell would break the x-plat promise. Please, I urge you to not do anything with scripts in packages.

[forki]

no we won't run code from the package - but we should try to repect all the declarative information that we find

[theimowski]

then, for now, the task here would be to copy stuff from Content dir to project dir and add appropriate entries to proj file?

[forki]

exactly. flagging this as up-for-grabs

[theimowski]

I will give it a try

[bartelink]

@theimowski As alluded to in the comment above, note that part of the standard NuGet functionality in this area is that the old files get removed as the old package is 'uninstalled' except if there have been changes, it issues a warning and leaves them there. IIRC then installing the new version warns again about not replacing it.

Examples of stuff using this is Ninject.Web, which has a 'template' file that sets up initialization order wiring, and then in the comments says "put your stuff here". Now, arguably partial methods are the best way for package authors to remove the need for this, but lots of this exists so I think naively overwriting is def a bad idea and I'm not sure where a nice half way house would be.

Of course, having said that, I'd like a half baked impl to blast in new boostrap/jquery as it happens (though I'll get annoyed if I end up chasing problems due to orphaned files!).

Another potential thing that native NuGet more than likely does not address is that updates to .fs files in packages should preserve the order in the file (and I'm thinking they should default to near the top of a file (in dependency order if looking to gold plate!) for that reason too).

Good writeup on authoring conventions (obv the impl needs to primarily concern itself with the nuget consumption side of things more than that)

[theimowski]

I created a PR with very simple strategy for the moment: Removing all content files that Paket resolved followed by reinstalling all defined

[forki]

Yes please test #84 and give us feedback. Thanks

[bartelink]

@forki @theimowski As noted over on #84, tested the PR in the context of this and main issue is that the insertion sequence triggers issues due to the order sensitivity of the VS .fsproj project system

@theimowski BTW most of this stuff should be v reproable with a vanilla [F# MVC 5](http://visualstudiogallery.msdn.microsoft.com/39ae8dec-d11a-4ac9-974e-be0fdadec71b project). (I chose Web Api 2, the non-empty one which has an index.html, site.css and main.js but nothing else of consequence)

[forki]

Ok there are a couple of half-baked solutions to this.

I would start with alphabetical order.
We could also implement other things like retrieving the order from a
projectfile in the package.

@forki https://github.com/forki @theimowski
https://github.com/theimowski As noted over on #84
#84, tested the PR in the context
of this and main issue is order sensitivity of VS .fsproj project system

—
Reply to this email directly or view it on GitHub
#65 (comment).

[bartelink]

@forki For F# projects, conceptually the dependency hierarchy should be considered, i.e. if source package A has a A.fs file in the root and depends on a package that puts b.fs in the root, then b.fs needs to be before A.fs.

The other constraint is (obviously) that the Paket insertions need to be injected [immediately] before the batch of user-added files in that same folder.

And (for avoidance of doubt, I'm sure you're considering this) for avoidance of eggregious diffs, it needs to guarantee idempotency via some predictable ordering after that.

We could also implement other things like retrieving the order from a
projectfile in the package.

Erwhaddyamean?

[vasily-kirichenko]

I examined packages we really use and the main useful thing ps1 scripts do is adding binding redirects to app configs:

param($rootPath, $toolsPath, $package, $project)

Add-BindingRedirect $project.Name

I'm not sure we can ignore this.
And practically all web packages do lots of magic in their ps1, especially MS ones.

[vasily-kirichenko]

So, what I should do with something FontAwesome.4.1.0 that contains the following script:

param($installPath, $toolsPath, $package, $project)

foreach ($fontFile in $project.ProjectItems.Item("fonts").ProjectItems)
{
    $fontFile.Properties.Item("BuildAction").Value = 2;
}

Do you suggest adding all those files by hand?

[forki]

No but that's something that should be declared not programmed.

I'm suggesting we (as a . NET community) start to fix this at the root.

[forki]

I mean this loop is broken on so many levels and only works from inside VS

[agross]

nuget.exe install FontAwesome doesn't run the script either.

If you need tooling to change the items to be always copied to the output directory, then yes, I think you should learn to do that yourself.

[forki]

@agross It seems it's hard to formulate this in a nice way. ;-)

Let me rephrase a bit: we do know that these problems exist. We don't think adding ps1 to paket would help. Actually we don't know of any way to get it working with our model since we don't live inside vs. But we are open for all other solutions to make the transition easier.

[ilkerde]

+111 @forki @agross It's a terrible mistake of nuget to pre/post-execute stuff - regardless of the language. Please let's be serious and strict about fixing this by simply not doing it at all!

[agross]

@vasily-kirichenko @forki OK, I think an apology is in order. I'm sorry my last statement came across as harsh.

Still, in my opinion, the discussion about the scripts shows how spoilt we all are w.r.t. our beloved VS tooling.

[bartelink]

@vasily-kirichenko @forki @agross .props and .targets in the build area of a package are generally the best solution here, as described in #101.

In my (production, diverse VS versions, diverse NuGet versions, closed source) experience, the mucking about in VS in the .ps1 is so unreliable / hard to get right in the face of package uninstall / reinstall that most packages of consequence will eventually migrate to them; the only potential blocker is the minimum NuGet version 2.5 bar (but again, there's so many bugfixes in there and targeting 2.5 gives a very clear error message that I believe projects should just demand it - we did)

[bartelink]

This is just a summary, all these items are covered elsewhere, but in terms of supporting the F# MVC template, the following things could be better. None are disasters so arguably these could be split out into individual issues:

1. paket convert-from-nuget (but really paket install) doesn't cope with fonts source folder in the boostrap package
2. paket install/update always wants to put fonts at the bottom of the .fsproj - I think it should be at the top for idempotency and correctness reasons
3. Source install is creating a lot of junk folders (e.g. PCL related stuff from web api)

It should also be pointed out that right now, NuGet cannot update from boostrap 3 / w/ jquery 1.9 to anything as it chokes due to the project system/VFPT not handling foldering sufficiently so this is quite an achievement - and a must have for this stuff to even work.

[bartelink]

Remaining bit is that because no binding redirects get added, when I use specify my deps as:

source "http://nuget.org/api/v2"

nuget Unquote >= 2
nuget xunit = 1.9.2
nuget bootstrap >= 3
nuget Microsoft.AspNet.WebApi >= 5
nuget hyprlinkr >= 1

nuget FsWebAddRegistryEntries >= 0
nuget Microsoft.AspNet.Mvc >= 5
nuget Microsoft.AspNet.Web.Optimization >= 1
nuget Modernizr >= 2.6
nuget Respond >= 1.3

OOTB Build output on a wizard MVC 5 + WebApi 2 app says:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly. In Visual Studio, double-click this warning (or select it and press Enter) to fix the conflicts; otherwise, add the following binding redirects to the "runtime" node in the application configuration file: <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"><dependentAssembly><assemblyIdentity name="WebGrease" culture="neutral" publicKeyToken="31bf3856ad364e35" /><bindingRedirect oldVersion="0.0.0.0-1.6.5135.21930" newVersion="1.6.5135.21930" /></dependentAssembly></assemblyBinding><assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"><dependentAssembly><assemblyIdentity name="Newtonsoft.Json" culture="neutral" publicKeyToken="30ad4fe6b2a6aeed" /><bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" /></dependentAssembly></assemblyBinding><assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"><dependentAssembly><assemblyIdentity name="Antlr3.Runtime" culture="neutral" publicKeyToken="eb42632606e9261f" /><bindingRedirect oldVersion="0.0.0.0-3.5.0.2" newVersion="3.5.0.2" /></dependentAssembly></assemblyBinding>

I can't figure out why I can't hit enter / why I should be able to hit enter (C#/web project system?) but if I put in what it says, it works.

UPDATE: Doing Add-BindingRedirect from Package Manager Console is not reliant on e.g. a packages.config (doc says it works from output dir). For Web Api, it added a redirect for System.Web.Http and my code appears happy. But the warning remains... Will post more,,,

[bartelink]

UPDATE: So the issues spawned by the F# MVC 5 template that are not yet in separate issues [and hence things I'd like to cover before this gets closed] are:

• paket install/update always wants to put fonts at the bottom of the .fsproj - I think it should be at the top for idempotency and correctness reasons
• (Source) install is creating a lot of junk folders (e.g. PCL related stuff from web api)
• define Paket's stance / what Paket can do do to manage binding redirects (probably nothing useful Paket can do without going very far into looking inside NuGet packages which I can't see a good reason to do)
• handling substitutions in source files (summarised well within jeffhandley.com/archive/2013/12/09/nuget-package-restore-misconceptions.aspx)
  • handling substitutions in source files - $projectnamespace
  • providing handling for files that are supposed to be edited - NB might benefit a lot from splitting update from sync/restore/add ref in Paket FizzBin / paket restore #176
    • not replacing by default if edited
    • providing a way to force replacing if edited
• add warning if package has PS elements - init.ps1/install.ps1/uninstall.ps1
• related: Handle NuGet Build .props .targets #101 build folder - .props / .targets support

Happy to expand and/or calve off issues for these one by one as desired