c# – 将.NET Core项目发布到Nuget – 要使用哪个框架版本？

2022-11-09 10:01:41

TL; DR版本

我正在构建一个.NET Core lib,目标是project.json中的框架netstandard1.6 dnxcore50.我的二进制文件内置在具有匹配名称的文件夹中. MSDN’s Nuget naming convention说dnxcore50是一个“已弃用的”框架 – 所以我应该将我的文件夹重命名为netcore50还是应该完全定位另一个框架？

我正在使用VS 2015社区和DotNetCore.1.0.1 SDK.

长版

我维护了一个名为FluentFTP的FTP库.我已经使用VS 2015社区成功编译了.NET核心版本.我的project.json看起来像这样：

{
  "dependencies": {
    "NETStandard.Library": "1.6.0",
    "System.IO": "4.3.0.0",
    "System.Net.NameResolution": "4.3.0.0",
    "System.Net.Sockets": "4.3.0.0",
    "System.Net.Security": "4.3.0.0"
  },
  "frameworks": {
    "netstandard1.6": {
      "imports": "dnxcore50"
    },
    "dnxcore50": {
    }
  }
}

我复制了另一个项目的框架部分,因为我不知道使用什么格式.正如您所看到的,我的目标是.NET Core 5.0(显然)和.NET Standard 1.6.我可以成功构建,所以我假设我已经构建了.NET Standard 1.6和.NET Core 5.0版本(我是对的吗？).当我构建时,我得到一个目录结构,如：

> dnxcore50
> netstandard1.6
> net20
> net40

为了将多框架库发布到nuget,MSDN表示你需要遵循某个naming convention.

遗憾的是,dnxcore50在naming convention文章中被标记为“弃用的框架”.这是否意味着：

>我正在构建错误/过时的框架类型？
>我只需要将文件夹dnxcore50重命名为netcore50并发布它？

解决方法:

恐怕这只不过是我的观点(实际上是哲学问题),尽管我觉得它可以被认为是对这个问题的一个相关答案：

一般来说,你应该要求你实际使用的东西,而不是更多.这意味着框架的最旧版本以及您使用其功能的语言.提供与较新版本完全兼容(理想情况下,您应该在所有较新的框架版本上定期测试您的代码).如果它不是,但你仍然想要支持它(因为你和/或其他人落入你的目标受众可能仍然在遗留代码支持中使用它)你应该考虑为不同的平台构建单独的版本,有时甚至可能意味着维护代码某些部分的并行版本.

我并不是说你应该故意限制自己使用的功能只是为了支持旧的框架和/或语言(这是一个单独的,非常主观和依赖于上下文的问题).我的意思就像在Windows XP机器上用C#3.0编写整个项目一样,然后他的公司用Windows 10和Visual Studio 2017购买新的闪亮的笔记本电脑,他开始单独使用.NET Framework 4.6.2构建只因为他可以,虽然他甚至不知道在这个框架中添加了一个新功能.

我认为上述哲学的一个合理的例外是框架的预发布(alpha,beta,ctp,rc等)版本 – 正如我所理解的那样.发布后,开发人员应尽快切换到它(但不会很快).

但是,无论何种理由和灵活性与试图达到实际(或稍微更高)程度的逻辑形式主义(为了更有效的决策),异常的异常都会出现,在这种情况下,这些是：

>在支持广泛使用的任何内容之前,请三思而后行.在现实世界中,当旧版本/预发行版本的采用范围比新版本/发行版本广泛得多时,会出现这种情况,并且客观上阻碍升级过程的版本之间可能存在重大变化.这可能恰好也是你的情况,我真的不知道有多严重(升级现有代码需要多少工作)这种情况下的变化是,现在有多少人使用旧框架版本,如何重要的是您在库新版本中引入的修改(例如,如果它包含严重的错误修复或实际上非常有用的新功能和/或更容易迁移到新框架).
>如果这不需要花费任何大量的时间,精力,*(例如使用你想要的新框架/语言功能)以及你的其他资源,只要至少有些人选择保留,就会继续支持过时的东西使用它.如果您觉得自己开始没有得到支持,那么向其余用户发送支持终止通知信和/或将其发布在您的博客,推特等中可能会很友好.

码农公寓

相关文章