I want my library to work with a range of versions of a NuGet package with breaking changes in API between the changes. I haven\'t investigated it furt
If you insist on extern aliases - you can add multiple version references directly, as dll file, not as nuget package.
Suppose I want to take a dependency on Newtonsoft.Json package version 10.0.3+.
However if user has version 11 installed - I want to use generic JsonConverter class available only in this version (11). Then my csproj might look like this:
netstandard2.0
1.0.4
Newtonsoft.Json.v11.dll
js11
true
Then I have proxy interface:
public interface ISerializer {
string Serialize(T obj);
}
And two implementations, v10 (uses global, non-aliased namespace):
using System;
using global::Newtonsoft.Json;
namespace NugetRefMain {
internal class Js10Serializer : ISerializer
{
public string Serialize(T obj)
{
Console.WriteLine(typeof(JsonConvert));
return JsonConvert.SerializeObject(obj);
}
}
}
And v11
extern alias js11;
using System;
using js11::Newtonsoft.Json;
namespace NugetRefMain {
internal class Js11Serializer : ISerializer {
public string Serialize(T obj) {
// using JsonConverter, only available in v11
Console.WriteLine(typeof(JsonConverter));
return JsonConvert.SerializeObject(obj);
}
}
}
And finally factory which creates serializer depending on current available json.net version:
public static class Serializers {
public static ISerializer Create() {
var version = typeof(JsonConvert).Assembly.GetName().Version;
if (version.Major == 10)
return new Js10Serializer();
return new Js11Serializer();
}
}
Now if I pack this as nuget - it will have single dependency on Newtonsoft.Json version 10.0.3 and that's all. However, if user installs Newtonsoft.Json of version 11 - it will use capabilities available in this version.
Drawbacks:
Visual Studio \ Resharper intellisense doesn't like this approach sometimes and shows intellisense errors when in reality everything compiles just fine.
You might have "version conflict" warnings on compilation.