Combining type project and specifying files included in nuget package with different framework requirement #1221

theggelund · 2015-11-13T13:26:14Z

When using project type project in paket.template and specifying different files for different framework, the packages for 4.5.2 and 4.6 are correct but the package for 4.0 is replaced with the content of package for 4.6

paket.template

type project
id DIPS.Infrastructure
authors DIPS ASA
description Infrastructure libraries
files
    ..\..\..\..\bin\v4.6\AnyCPU\release\DIPS.Infrastructure.dll ==> lib/net46
    ..\..\..\..\bin\v4.6\AnyCPU\release\DIPS.Infrastructure.pdb ==> lib/net46
    ..\..\..\..\bin\v4.5.2\AnyCPU\release\DIPS.Infrastructure.dll ==> lib/net452
    ..\..\..\..\bin\v4.5.2\AnyCPU\release\DIPS.Infrastructure.pdb ==> lib/net452
    ..\..\..\..\bin\v4.0\AnyCPU\release\DIPS.Infrastructure.dll ==> lib/net40
    ..\..\..\..\bin\v4.0\AnyCPU\release\DIPS.Infrastructure.pdb ==> lib/net40

The text was updated successfully, but these errors were encountered:

forki · 2015-11-13T16:58:16Z

do you have this as a zip or git repo for me?

theggelund · 2015-11-13T17:00:14Z

I can create a git repo, give me a couple of hours

theggelund · 2015-11-13T19:03:31Z

Updated https://github.com/theggelund/paket_bug

I've created 2 project files in separate folder under MyClassLibrary ( They have the same dependencies but that doesn't matter.
They have each a paket.template file and a reference from DIPS.Infrastructure to DIPS.Infrastructure.Services.

I believe that the error occurs when one project references the other.

the bin folder contains separate files for v4.0, v4.5.2 and v4.6. These dll and pdb files are only text files with the version expected inside.

the out folder contains the nupkg files that has error, DIPS.Infrastructure has the error in v4.0\AnyCPU\release\DIPS.Infrastructure.dll

forki · 2015-11-13T19:23:48Z

I tried
paket install
paket pack output D:\code\paket_bug\out

on your solution but got:

something is fucky here

forki · 2015-11-13T19:27:23Z

it can't load the assemblies to retrieve meta data. can you try to reducethe repro to "type file"?

theggelund · 2015-11-13T19:40:18Z

Ah, it reads assemblies. I renamed text files and put them in bin folder instead of assemblies for easier verification

This reproduces the error and it appears to not read any assemblies

theggelund · 2015-11-13T20:28:34Z

So i've updated the repository with assemblies compiled agains correct version of .net

By running these commands

This is the result

Not using type file because i would like for paket to resolve all dependencies and metadata but not files, since I have specified them in the template. Am I asking for too much?

forki · 2015-11-13T20:38:43Z

Yes that's fine. I only thought I might be easier to use type file to
reproduce.
Not near a pc anymore but will try to look at it on Sunday
On Nov 13, 2015 9:28 PM, "Thomas Heggelund" notifications@github.com
wrote:

So i've updated the repository with assemblies compiled agains correct
version of .net
[image: skjermbilde 2015-11-13 kl 21 26 28]
https://cloud.githubusercontent.com/assets/648714/11156617/3d84c9d8-8a4d-11e5-8569-10b2ffafac1a.png

By running these commands
[image: skjermbilde 2015-11-13 kl 21 24 57]
https://cloud.githubusercontent.com/assets/648714/11156625/5068f646-8a4d-11e5-88a0-5f163a0dbe9d.png

This is the result
[image: skjermbilde 2015-11-13 kl 21 25 08]
https://cloud.githubusercontent.com/assets/648714/11156632/5a6b5da0-8a4d-11e5-874e-bf4c5e1a990c.png

Not using type file because i would like for paket to resolve all
dependencies and metadata but not files, since I have specified them in the
template. Am I asking for too much?

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

forki · 2015-11-15T09:31:26Z

I can reproduce

forki · 2015-11-15T09:50:43Z

Ok let's try to analyze MyClassLibrary2\manual_project\Dips.Infrastructure.csproj

the template files contains 6 additional files (according to the debugger Paket undestands that correctly).
the template file is of type project. this means paket tries to put the project out put into the package

Unfortunately we don't undestand this:

<TargetFrameworkVersion Condition="'$(TargetFrameworkVersion)' == ''">v4.6</TargetFrameworkVersion>
<TargetFrameworkProfile Condition="'$(TargetFrameworkVersion)' == 'v4.0'">Client</TargetFrameworkProfile>

So paket get's confused and thinks TargetFrameworkVersion is "Client" ==> v4,0 and put's project output (v4.6 binaries) into v4.0 folder. This overwrites the already copied v4.0 bins from the "additional files" section.

I guess the fix is to make Paket understand your conditions.

forki · 2015-11-15T09:55:54Z

@amazingant in #942 you introduced magic parsing in ProjectFile.GetOutputDirectory. This magic needs to be consistent with GetTargetProfile() (where it's basically missing). Are you interested in helping here and making GetTargetProfile as smart as GetOutputDirectory?

theggelund · 2015-11-15T12:05:17Z

Wouldn't it be possible to specify an override for template file, like when files are specified or some kind of magic constant is specified, then paket will not try to find any files to put in nupkg but rather use the files specified?

I guess my project is kind of special since I try to build for multiple platforms, and one of them are v4.0 client profile.

forki · 2015-11-15T12:16:27Z

I don't think we should introduce another option here. I'd really like to
see the underlying cause fixed. But if you need a (temporary) workaround
then you could just use "type file" for now.
On Nov 15, 2015 1:05 PM, "Thomas Heggelund" notifications@github.com
wrote:

Wouldn't it be possible to specify an override for template file, like
when files are specified or some kind of magic constant is specified, then
paket will not try to find any files to put in nupkg but rather use the
files specified?

I guess my project is kind of special since I try to build for multiple
platforms, and one of them are v4.0 client profile.

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

forki · 2015-11-15T12:20:48Z

That said: we could also change the copy order to make your use case work
On Nov 15, 2015 1:16 PM, sforkmann@gmail.com wrote:

I don't think we should introduce another option here. I'd really like to
see the underlying cause fixed. But if you need a (temporary) workaround
then you could just use "type file" for now.
On Nov 15, 2015 1:05 PM, "Thomas Heggelund" notifications@github.com
wrote:

Wouldn't it be possible to specify an override for template file, like
when files are specified or some kind of magic constant is specified, then
paket will not try to find any files to put in nupkg but rather use the
files specified?

I guess my project is kind of special since I try to build for multiple
platforms, and one of them are v4.0 client profile.

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

allykzam · 2015-11-15T12:54:58Z

If I'm understanding the comment chain here, I don't see why the parsing code I wrote couldn't be used for this too. I rather expected it would be useful again, as someone somewhere had to be doing insane things to their project files just like I do. 😁 But if it can be fixed easily elsewhere, I'll hold-off.

@forki: If you do want me to tackle this, I'd probably want to move my code farther up in the ProjectFile definition and wrap it up as member this.GetProperty propName defaultProps; that way it can be re-used later if needed, and won't be written twice. Does that sound okay? I should be able to start working on it tomorrow around 12pm GMT, but I'll re-familiarize myself with ProjectFile.fs in my free-time today.

forki · 2015-11-15T12:59:43Z

Yes that's what I hoped. Please reuse your code in gettargetprofile. Thx a
lot
On Nov 15, 2015 1:55 PM, "Anthony Perez" notifications@github.com wrote:

If I'm understanding the comment chain here, I don't see why the parsing
code I wrote couldn't be used for this too. I rather expected it would be
useful again, as someone somewhere had to be doing insane things to their
project files just like I do. [image: 😁] But if it can be fixed
easily elsewhere, I'll hold-off.

@forki https://github.com/forki: If you do want me to tackle this, I'd
probably want to move my code farther up in the ProjectFile definition and
wrap it up as member this.GetProperty propName defaultProps; that way it
can be re-used later if needed, and won't be written twice. Does that sound
okay? I should be able to start working on it tomorrow around 12pm GMT, but
I'll re-familiarize myself with ProjectFile.fs in my free-time today.

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

…#1221

forki · 2015-11-15T14:30:29Z

@theggelund not sure if my workaround worked, but could you please try 2.25.2?

theggelund · 2015-11-15T15:05:35Z

It works

forki · 2015-11-15T15:08:51Z

Cool. So we have no pressure for the real fix. But when it's in place I can
remove this workaround again.
On Nov 15, 2015 4:05 PM, "Thomas Heggelund" notifications@github.com
wrote:

It works

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

forki added the bug label Nov 15, 2015

forki added a commit that referenced this issue Nov 15, 2015

Use file order to work around duplicate files in template definition - …

dc80282

…#1221

allykzam mentioned this issue Nov 16, 2015

Update ProjectFile.GetTargetProfile to work with conditional nodes #1227

Merged

forki closed this as completed Nov 17, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Combining type project and specifying files included in nuget package with different framework requirement #1221

Combining type project and specifying files included in nuget package with different framework requirement #1221

theggelund commented Nov 13, 2015

forki commented Nov 13, 2015

theggelund commented Nov 13, 2015

theggelund commented Nov 13, 2015

forki commented Nov 13, 2015

forki commented Nov 13, 2015

theggelund commented Nov 13, 2015

theggelund commented Nov 13, 2015

forki commented Nov 13, 2015

forki commented Nov 15, 2015

forki commented Nov 15, 2015

forki commented Nov 15, 2015

theggelund commented Nov 15, 2015

forki commented Nov 15, 2015

forki commented Nov 15, 2015

allykzam commented Nov 15, 2015

forki commented Nov 15, 2015

forki commented Nov 15, 2015

theggelund commented Nov 15, 2015

forki commented Nov 15, 2015

Combining type project and specifying files included in nuget package with different framework requirement #1221

Combining type project and specifying files included in nuget package with different framework requirement #1221

Comments

theggelund commented Nov 13, 2015

forki commented Nov 13, 2015

theggelund commented Nov 13, 2015

theggelund commented Nov 13, 2015

forki commented Nov 13, 2015

forki commented Nov 13, 2015

theggelund commented Nov 13, 2015

theggelund commented Nov 13, 2015

forki commented Nov 13, 2015

forki commented Nov 15, 2015

forki commented Nov 15, 2015

forki commented Nov 15, 2015

theggelund commented Nov 15, 2015

forki commented Nov 15, 2015

forki commented Nov 15, 2015

allykzam commented Nov 15, 2015

forki commented Nov 15, 2015

forki commented Nov 15, 2015

theggelund commented Nov 15, 2015

forki commented Nov 15, 2015