Version 2 pulls in many NuGet dependencies

[RobSmyth]

Hi,

On upgrade from 1.9 to the latest ver 2 I found that there were many NuGet dependencies. Question/issues:

• Should the NET Core dependencies be included in my installer? Pointer to guidelines?
• Can I avoid shipping these dependencies if I make NET Core a install a prerequisite (possibly a stupid question)
• I'm new to NET Core, I'm using NET Framwork ... any known issues using within a NET Framework 4.6.1 application?

Thanks

[nemec]

Hi, yeah it does install a few 'core' dependencies even on the full framework. It's unintentional and something that needs to be fixed.

In theory you should be able to delete those dependencies from your project manually and it should still work since we aren't using any new APIs in Core. Either way, it definitely works on 4.6.1 without issue (the Nuget is dual-targeted to Core and the Full Framework)

[RobSmyth]

Hi nemec,

Thanks, that helps me put it in perspective. For your FYI, for users like me, it would be much better to have separate Core/Framework packages as we do not, in production, reference NuGet web sites. So, in this case I had to download and install all of the Core packages into our local NuGet site. I also have to justify the extra NuGet references in code reviews.

So it was/is quite a burden that I have not through yet. I may need to revert if other reject the code as it adds Core packages.

Thx

Rob

[ericnewton76]

@RobSmyth hey rob, I dont think you need to include Core dependencies (better to use the term "netstandard" now) in your installer since I'm assuming you're project targets a desktop framework, ie, netframework 4.6.1+ then you should be okay. That also means you're not invoking your program via dotnet run.

Btw, we're not the only package that includes both netstandard/netframework dependencies, however depending on your nuget hosting situation, you may have had to download the netstandard dependencies just to make the package valid on your own nuget server. Based on the current direction of nuget and netcore, I think you'll find this to be the case for more libraries going forward.

Also, certain netframework versions support particular netstandard versions, check the netstandard support matrix on msdn for more info: https://github.com/dotnet/standard/blob/master/docs/versions.md

Our design is intended to be the lowest common denominator that we could use, which initially was netstandard1.5 which is also supported by netframework 4.6.1+

[okvalsralos]

@RobSmyth
In my humble opinion the NuGet package design is wrong and causes unnecessary confusions.
Properly created NuGet package should look like this:

As can bee seen on the picture the NuGet package has properly specified multiple dependencies.

CommandLineParser includes only dependencies for NET Standard and those are invalid prerelease.

Best regards

[ajtruckle]

Are you saying I do not need to deploy any other DLL files in my installer? At the moment I include all of them.

[Athari]

@okvalsralos @nemec @ericnewton76 .nuspec file is incorrect.

1. commandlineparser.2.2.1.nupkg includes net40, net45 and netstandard1.5 subdirs within lib dir, however CommandLineParser.nuspec declares support only for targetFramework=".NETStandard1.5".

   You need to add the following lines to <dependencies>:

   <group targetFramework=".NETFramework4.0"/>
   <group targetFramework=".NETFramework4.5"/>

   Otherwise the contents of lib dir are ignored, users are linked to netstandard1.5 version and have to see all unnecessary packages it depends on.

2. Release packages should not include prerelease dependencies. Currently .nuspec is full of dependencies like <dependency id="System.Collections" version="4.0.11-rc2-24027" />. These should be changed to 4.0.0/4.1.0 (which is preffered, as it's the lowest supported release version) or 4.3.0 (which is currently the most recent version). You should also make sure you actually need all these dependencies.

3. You should include explicit netstandard2.0 support which should have no dependencies as it includes everything itself.

[Athari]

@ericnewton76 @nemec I tried fixing .nuspec, but I'm confused about what's going on during build.

So, I ran build base. I got identical libraries release\base\net4x\CommandLine.dll and release\base\netstandard1.5\CommandLine.dll. Both of them are actually referencing good old .NET 4.0. Then, according to CommandLine.nuspec, net4x\CommandLine.dll is put into the package as both lib\net40\CommandLine.dll and lib\net45\CommandLine.dll. This doesn't make any sense to me.

What you should do instead is switch to new .csproj format with muti-targeting, set TargetFrameworks to something like net40;netstandard1.5;netstandard2.0, move nuspec metainformation into the project, remove all remnants of project.json.

You should also consider getting rid of Paket, which is pretty much redundant with Core MSBuild. You include files through it (3 files copied from gsscoder's GitHub), which NuGet doesn't support, but it's a very questionable practice, you should just copy the files into the repository.

(Related: #222)

[zoller27osu]

I think this was on track to being fixed, but then something happened to the .nuspec between https://github.com/commandlineparser/commandline/tree/5c5fc3322e9255f30a81c1b7163af3f8bd907e5f and https://github.com/commandlineparser/commandline/tree/6cc3cbd2f690880426cf66634482fdb4ed5509c9.

Maybe between d638310 and
6cc3cbd ?

[moh-hassan]

This problem is resolved in the release 2.5.0 which support net40,net45,net461 and netstandard2.0.
Now, no many files are pulled in the projects net4x. Only CommandLine.dll is included in the binaries.
No dependencies in net4x.
In the nuspec file the dependencies are empty group.

    <dependencies>
      <group targetFramework=".NETFramework4.0" />
      <group targetFramework=".NETFramework4.5" />
      <group targetFramework=".NETFramework4.6.1" />
      <group targetFramework=".NETStandard2.0" />
    </dependencies>