Change NuGetPack call signature to avoid "kempejada"

[ilkerde]

This set of changes streamline NuGetHelper functions, in particular the usage of NuGetPack towards the usage of NuGet. A rudimentary approach to intergration testing of NugetHelper is provided as well.

Problem

Creating nuget packages is a fairly common task. FAKE provides nice helpers to do this, in particular the NuGet function, which sort of is a "all in" function to create and publish the package in one go. However, if one were to provide two separate targets for creating and publishing the package, the NuGet function needs to be called twice. Obviously with the Publish property being set to false in first call and true on the second call.

Interestingly, FAKE NuGetHelpers provide two additional functions: NuGetPack and NuGetPush. As the names already say it, NuGetPack creates the package, while NuGetPush publishes it.

Given the user would like to use NuGetPack and NuGetPush for separate targets instead of NuGet, a specific API divergence bubbles up to the public surface: NuGet expects a nuspec template to be passed and processes it by replacing the NugetParams accordingly. In constrast, NuGetPack has the same call signature as NuGet, but expects a complete and valid nuspec file as opposed to a nuspec template file. This kempejada forces the user to use NuGet twice instead of (intuitively) use NuGetPack and NuGetPush for separate targets.

Note: This "API divergence" is called kempejada here (just out of fun).

Solution

NuGetPack now performs the same package creation process as NuGet does. For a minimum level of verification, an integration is provided. For the integration test some helper functions were needed for function conversion (CSharpHelper.fs). I don't like that I've put them right into FakeLib, but I didn't knew a better place to tuck it in.

This change preserves compatibility to any prior NuGetPack usage since a complete (non-templated) nuspec file is just processed and passed along to the pack function.

Windows and Mono builds / tests pass. Please review thoroughly. Feedback and comments appreciated.

[ilkerde]

I wonder how this worked all the time since I really needed it to get the package creation working on Linux/Mono. The windows build didn't complain about it though.

[forki]

If you omit the files section. NuGet just takes all files in the current structure. This is what we used for FAKE's own build. So I'm reverting this little change. Other builds use the explicit file section.

[forki]

I think I found your issue. The implicit version seems to bug on mono. Thanks nuget....

[ilkerde]

I was wondering why omitting it would work because I explicitly tested it with FAKEs own nuspec on mono and it didn't work out.

[forki]

[forki]

Now the build fails on Travis. Ideas?

[ilkerde]

I'll have a look at the build, but seems it is related to files collection anyways: Invalid start element: http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd:files