Enterprise Paket: Build speed and target framework?

[Thorium]

My current question is about converting an enterprise application to use Paket:

• Will Paket affect to the build speed? I have over 1000 csproj-files. I can measure if you don't know... But when I build in Visual Studio, Output-window says Paket is holding lock to some files and retry and then success...what is that?
• And target frameworks: it seems that paket adds many conditions to the .csproj-files even if csproj-files already have a specific targetframework. I didn't have NuGet in use in the current enterprise application (but the packages-folder where there), so I created a script that creates all the packages.configs (based on dll-refetences HintPaths) that paket's convert-from-nuget -parameter needs: https://gist.github.com/Thorium/c155e8404dedc7b5610b
  But does paket use targetframework-attributes of the package.config file?

[forki]

But when I build in Visual Studio, Output-window says Paket is holding lock to some files and retry and then success...what is that?

VS tries to build in parallel. If you have VS restore enabled then one step of that build is to restore your packages. But we make sure that only 1 paket.exe is active at all times, since they compete to write into packages folder. Unfortunately there is no VS event which is called before all projects build.
The only way around this is a pre-script (we use FAKE) which calls paket restore.

But does paket use targetframework-attributes of the package.config file?

AFAIK: no. /cc @theimowski

If you want to reduce the number of frameworks, then you currently have to edit the paket.dependencies file manually.

[theimowski]

nope, convert-from-nuget reads only the packaged id and version:
https://github.com/fsprojects/Paket/blob/master/src/Paket.Core/NugetConvert.fs#L48-L52

[theimowski]

#609 is related

[Thorium]

Some initial testing (with Core-i7/2.7GHz/16GB):
About 150 solutions having total about 1100 projects, and a bit over 80 external packages.
Packages are found from local hard drive (already restored).
Build-script is just msbuild calling to build those solutions.
Original build time (NuGet): 7-8 min
After running Paket convert-from-nuget, everything was ok.
But running the same build as earlier, new build time: about 13-14 min

I can't live with it, can I speed up building solutions somehow?

[forki]

Original build time (NuGet): 7-8 min
But running the same build as earlier, new build time: about 13-14 min

but what are you doing? Why is paket called at all? you could disable restore during MSBuild.

[Thorium]

I'll try to disable those next. I just hope it is not about msbuild parsing XML speed. There are some extra stuff in csproj-files:

<Import Project="..\..\..\..\.paket\paket.targets" />
<Choose>
    <When Condition="($(TargetFrameworkIdentifier) == 'WindowsPhoneApp') Or ($(TargetFrameworkIdentifier) == '.NETCore') Or ($(TargetFrameworkIdentifier) == '.NETFramework' And ($(TargetFrameworkVersion) == 'v4.0' Or $(TargetFrameworkVersion) == 'v4.5' Or $(TargetFrameworkVersion) == 'v4.5.1' Or $(TargetFrameworkVersion) == 'v4.5.2' Or $(TargetFrameworkVersion) == 'v4.5.3' Or $(TargetFrameworkVersion) == 'v4.6')) Or ($(TargetFrameworkIdentifier) == 'Silverlight' And $(TargetFrameworkVersion) == 'v5.0') Or ($(TargetFrameworkIdentifier) == 'WindowsPhone' And ($(TargetFrameworkVersion) == 'v8.0' Or $(TargetFrameworkVersion) == 'v8.1')) Or ($(TargetFrameworkIdentifier) == 'MonoAndroid') Or ($(TargetFrameworkIdentifier) == 'MonoTouch') Or ($(TargetFrameworkProfile) == 'Profile5') Or ($(TargetFrameworkProfile) == 'Profile6') Or ($(TargetFrameworkProfile) == 'Profile7') Or ($(TargetFrameworkProfile) == 'Profile14') Or ($(TargetFrameworkProfile) == 'Profile19') Or ($(TargetFrameworkProfile) == 'Profile24') Or ($(TargetFrameworkProfile) == 'Profile31') Or ($(TargetFrameworkProfile) == 'Profile32') Or ($(TargetFrameworkProfile) == 'Profile37') Or ($(TargetFrameworkProfile) == 'Profile42') Or ($(TargetFrameworkProfile) == 'Profile44') Or ($(TargetFrameworkProfile) == 'Profile47') Or ($(TargetFrameworkProfile) == 'Profile49') Or ($(TargetFrameworkProfile) == 'Profile78') Or ($(TargetFrameworkProfile) == 'Profile84') Or ($(TargetFrameworkProfile) == 'Profile92') Or ($(TargetFrameworkProfile) == 'Profile102') Or ($(TargetFrameworkProfile) == 'Profile111') Or ($(TargetFrameworkProfile) == 'Profile136') Or ($(TargetFrameworkProfile) == 'Profile147') Or ($(TargetFrameworkProfile) == 'Profile151') Or ($(TargetFrameworkProfile) == 'Profile157') Or ($(TargetFrameworkProfile) == 'Profile158') Or ($(TargetFrameworkProfile) == 'Profile225') Or ($(TargetFrameworkProfile) == 'Profile240') Or ($(TargetFrameworkProfile) == 'Profile255') Or ($(TargetFrameworkProfile) == 'Profile259') Or ($(TargetFrameworkProfile) == 'Profile328') Or ($(TargetFrameworkProfile) == 'Profile336') Or ($(TargetFrameworkProfile) == 'Profile344')">

[Thorium]

Yes, the "/property:RestorePackages=false;DownloadPaket=false" for MsBuild.exe did help for the build speed. Thanks!

[Thorium]

Now that I converted 1000 csprojs to use Paket, I have all the paket.references that converted from NuGet.

• How do I add a reference to existing package? Let's say my project X want to take Casle.Core into use and I already have a project Y using Castle.Core, so it exists already. If I just add reference from the Visual Studio IDE to the paket's package-folder, then the X.csproj-file reference/condition-structure is different... And do I have to manually update paket.reference -file for X?

I could make a script that parses HintPaths to paket.references. But that doesn't answer to the csproj-structure.

So now the Paket FAQ section has answers "what are these files" and "why NuGet sucks", but not "how do I maintain a project using Paket".

[forki]

Now that I converted 1000 csprojs to use Paket

How do I add a reference to existing package?

A)

• go to the project's paket.references and add the package.
• run paket install

B)

• use http://fsprojects.github.io/Paket/paket-add.html#Adding-to-a-single-project

that said: for such big use cases we should invest in making https://github.com/hmemcpy/Paket.VisualStudio a thing.