Allow source to be a nuget package

[TheAngryByrd]

Description

I'd like to be able to use a previously published nuget package instead of having a dll locally. We could solve this one a few ways.

• specifying the nuget url
• another switch type with just a name of a package and version

Known workarounds

Download the nuget package outside the tool on to your local machine

Related information

• Operating system
• Branch
• .NET Runtime, CoreCLR or Mono Version
• Performance information, links to performance testing scripts

[baronfel]

One thing that will be harder is that for the diff/comparison, you'd need to tell SynVer which Target Framework inside the nuget package to use as the basis of comparison.

[TheAngryByrd]

Ah yes. Then maybe it would be good to compare two nuget packages? That way if the TFMs change you could introduce some semantics there as well.

Added a TFM -> Minor
Removed a TFM -> Breaking

[wallymathieu]

Yes, I think that it would be a good thing to have.

[baronfel]

Another caveat for comparison:

The current algorithm for comparing surface area treats public types as different if any of their full type name changes (which includes the version of the assembly), which is not that useful in the case where you're comparing to nuget packages for deltas. This is shown as a required major bump, when in reality it could be a patch bump with runtime-retargeting, IMO.

An example from using this library in FSharp.Compiler.Service:

   * FSharp.Compiler.SourceCodeServices.FSharpCheckFileResults
   
           - (Instance of FSharp.Compiler.SourceCodeServices.FSharpCheckFileResults).GetFormatSpecifierLocationsAndArity : 
                   System.Void
                   -> System.Tuple`2[[FSharp.Compiler.Range.range, FSharp.Compiler.Service, Version=34.1.0.0, Culture=neutral, PublicKeyToken=null],[System.Int32, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]][]
   
           + (Instance of FSharp.Compiler.SourceCodeServices.FSharpCheckFileResults).GetFormatSpecifierLocationsAndArity : 
                   System.Void
                   -> System.Tuple`2[[FSharp.Compiler.Range.range, FSharp.Compiler.Service, Version=34.1.1.0, Culture=neutral, PublicKeyToken=null],[System.Int32, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]][]
   
           - (Instance of FSharp.Compiler.SourceCodeServices.FSharpCheckFileResults).GetSemanticClassification : 
                   range:FSharpOption<FSharp.Compiler.Range.range>
                   -> System.ValueTuple`2[[FSharp.Compiler.Range.range, FSharp.Compiler.Service, Version=34.1.0.0, Culture=neutral, PublicKeyToken=null],[FSharp.Compiler.SourceCodeServices.SemanticClassificationType, FSharp.Compiler.Service, Version=34.1.0.0, Culture=neutral, PublicKeyToken=null]][]
   
           + (Instance of FSharp.Compiler.SourceCodeServices.FSharpCheckFileResults).GetSemanticClassification : 
                   range:FSharpOption<FSharp.Compiler.Range.range>
                   -> System.ValueTuple`2[[FSharp.Compiler.Range.range, FSharp.Compiler.Service, Version=34.1.1.0, Culture=neutral, PublicKeyToken=null],[FSharp.Compiler.SourceCodeServices.SemanticClassificationType, FSharp.Compiler.Service, Version=34.1.1.0, Culture=neutral, PublicKeyToken=null]][]

You can see that since the range type has the version in it, it looks like we have a breaking change.

[wallymathieu]

Yes, that sounds odd, so should probably be fixed

[wallymathieu]

I think the issue appears when you use reflection fullname, so a workaround could be to use --decompile instead in order to avoid getting names with assembly versions.

[wallymathieu]

I've done a fix for it (assembly version included in typename), there is a pull request @baronfel

[wallymathieu]

@TheAngryByrd or @baronfel any idea about how to implement this?

[TheAngryByrd]

I'll take a look at this soon and send an initial PR we can discuss on.