Paket: <Private>True</Private> is Visual Studio-specific

[haf]

When making a change with Paket, it automatically adds the <Private>True</Private> element to each dependency reference in the xxproj files.

I would rather it did not. After making a change to a project file in Xamarin Studio, this is the result:

It means that all project files receive a lot of churn, and it's an annoyance to manually fiddle with a project in XS before committing every time paket has been used.

If it's the opposite case for Visual Studio, and it requires the Private-element-flag, or otherwise adds it itself, then perhaps a nice heuristic would be to check whether paket is running on mono, and then not add the flag?

[forki]

mhm. actually I always wondered what that Private thingy is doing.
We copied it from what NuGet did.
Any pointers?

[cdrnet]

IIRC this is the "Copy Local" property, i.e. the assemblies are to be copied to the bin directory.

[forki]

If this is correct then it's very strange that XS is silently removing it. Also how can XS and VS could work on same solution if this is correct.

[cdrnet]

https://msdn.microsoft.com/en-us/library/bb629388.aspx

According to this, "true" is actually not a valid value.

[haf]

It works fine to compile in both VS and XS without it. We got CI with Suave to verify that.

[forki]

Strange. In referenced docs we find:

Private - Optional string. Determines whether to copy the file to the output directory. Values are:
  - Never
  - Always
  - PreserveNewest

According to this true is not even a valid value.

[cdrnet]

Does XS also drop it if it is set to Always instead of true?

[tpetricek]

The "FsLab Journal" template uses this (see the code) - though in a slightly hacky way.

By setting <Private>False</Private> on most DLLs, it makes sure that VS will not copy the DLLs to the output folder and so they are loaded from elsewhere (using <probing> element in config file). In FsLab, this actually matters to make sure that the runner loads the DLLs from the same place as the scripts it evaluates (and so there is just one copy of every type loaded).

But I have not seen this used in other places...

[jeroldhaas]

@tpetricek how does setting <Private> to False differ from Never?

[forki]

just to clarify: Paket only adds True and the question is: will it hurt if we omit this?

[jeroldhaas]

Docs say the value is optional, however default behaviour for referenced items may differ between XS and VS (and others) if this is omitted.

If the value is currently being set to True, at this point it seems a simple matter of deciding between Always and PreserveNewest.

[tpetricek]

@jeroldhaas No idea. I always thought True and False are the only valid options!

[forki]

Lol. We're are a really funny crowd...

[Stift]

Please recognize: It depends what version you are looking at. For VS2013 it is correct that True/False are not even valid. But for VS2012 we have something different, because boolean values are allowed. (https://msdn.microsoft.com/en-us/library/bb629388%28v=vs.110%29.aspx)

[forki]

It's becoming an epic thread. ;-)

Let me rephrase: if we omit this snippet, who would be really sad about it?

[Stift]

If we omit the value then we assume the default behaviour. This is 'true' for Visual Studio and fine enough.

BTW: I always wondered why paket added this value specifically.

Fun Fact: Also when VS2013 MsBuild spec tells something about Never/Always/PreserveNewest it only sets True/False.

[forki]

Ok that's finally a statement about default values. Yes paket is only generating TRUE values. We did this because nuget did it and we had no idea about it.

Now I will just remove that part and wait for your bug reports. ;-)

[haf]

+1

[matthid]

Note that just had some issues with this and set it to Never and while that worked fine for xbuild msbuild (VS2013) will spit out:

1>C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): error MSB3095: Invalid argument. Item "FSharp.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" has attribute "Private" with value "Never" that could not be converted to "bool". [c:\Projects\Yaaf.FSharp.Scripting\src\source\Yaaf.FSharp.Scripting\Yaaf.FSharp.Scripting.fsproj]

So if you need a cross platform solution you can either leave it out or use:

    <Reference Include="FSharp.Core, Version=$(TargetFSharpCoreVersion), Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
      <Private Condition=" '$(OS)' == 'Unix' ">Never</Private>
      <Private Condition=" '$(OS)' != 'Unix' ">false</Private>
    </Reference>

(With Always and true in this case)
I'm not sure how Xamarin Studio will handle it, maybe somebody can test this?

[forki]

Ok I released it in 0.25.0-alpha001 and unfortunately it's breaking.
In particular it breaks Paket itself. The default behaviour seems to be different from what we have thought.

For the FSharp.Core (reference via NuGet package) we get:

for all other referenced packages we get:

So what do we do now?

[haf]

I googled a bit and as expected found an existing thread in bugzilla about this... https://bugzilla.xamarin.com/show_bug.cgi?id=17106

Their screencast seems to have timed out. But I think they'd be able to understand the issue after reading this thread. The solution might be to change XS.

[forki]

ok I reverted it. :disappointed:

[Stift]

I can confirm the problem with the Fsharp.Core package. Other packages are fine with default CopyLocal <- true. Does anyone have clue?
I have found this (a little bit older, but may apply): https://msdn.microsoft.com/en-us/library/aa984582%28VS.71%29.aspx

The project-assigned value of CopyLocal is determined in the following order:

1. If the reference is another project, called a project-to-project reference, then the value is true.
2. If the assembly is found in the global assembly cache, the value is false.
3. As a special case, the value for the mscorlib.dll reference is false.
4. If the assembly is found in the Framework SDK folder, then the value is false.
5. Otherwise, the value is true.

This could explain it as Fsharp.Core is in my GAC

[forki]

Yep I think it's GAC related

[tpetricek]

Is there any chance that Paket could preserve hand-made changes to the project files? This would help FsLab Journal: https://github.com/tpetricek/FsLab/issues/66#issuecomment-71388475

That said, it's not a big deal - the way FsLab Journal handles this is a complete hack and it should be done in some better way (if I could only figure out how...).

[haf]

It wasn't fixed in XS 5.7 https://bugzilla.xamarin.com/show_bug.cgi?id=17106 despite them saying it... :-*

[haf]

I created a new bug report https://bugzilla.xamarin.com/show_bug.cgi?id=31372 because this is still annoying me. =)

[BrainSlugs83]

@forki on the linked page, for the "Reference" element's "Private" attribute it says:

Optional boolean. Specifies whether the reference should be copied to the output folder. This attribute matches the Copy Local property of the reference that's in the Visual Studio IDE.

The only place where "Always", "Never" and "PreserveNewest" are mentioned is on the "CopyToOutputDirectory" attribute.

Further, I can confirm that "True" and "False" are what Visual Studio 2015 places in that value. According to the MSDN documentation, "True" and "False" are the only valid values.