我即将使用现有的Serilog的SQL Server接收器,但我意识到最新的预发行版和稳定版不支持ASP.NET Core。
这个水槽有替代品吗?我应该做些什么?我应该写一个新的水槽吗?
答案 0 :(得分:2)
我不能告诉你你所谓的做了什么,但我可以描述几个选项。 GitHub上的Sql Server Serilog提供程序可以更好地询问他们打算要做什么。
Serilog确实在.Net核心列车上,正如许多其他主流.Net项目一样。你是对的,截至今天,SQL服务器接收器只是.Net 4.5。你可以:
继续开发ASP.Net Core项目,在项目json中定位.Net 4.5,仅构建和部署到Windows OS,但继续使用SQL Server sink。
许多公司正在迁移到.Net Core,但目标是.Net 4.x.x,以保持100%与现有软件包的兼容性,同时解决框架中的问题。这对我的大型项目来说是一个可行的解决方案。
目标.Net Core,编写自己的日志存储库层来管理自定义SQL和数据库日志转储代码。
如果你是核心,这比听起来容易,但需要有数据存储库和IoC的经验。任何需要将日志转储到数据库的代码都必须具有某种“ILoggingRepository”。但它会重复调用日志记录方法,除了偏离Microsoft.Logging.Abstractions中的ILoggerProvider接口 - 放弃日志级别的灵活性等,除非您决定重新设计自己的。这是一个有效的解决方案;我从来没有说过这是一个优雅的。
编写自己的Serilog接收器。
我没有这方面的经验,但我看过代码示例,描述了如何实现这一目标的细节。我之所以没有采用这个选项,是因为担心当我编写我的兽数据库时,开源社区会将Sql Server版本重新编写为完全符合核心且与数据库无关的版本。这将是最苛刻的解决方案,但也是最强大的解决方案。
.Net Core可能还有其他接收器可用,但如果您正在寻找一个专门的SQL服务器,那么您很可能正在使用阻止使用MongoDB接收器和文件提供程序等的约束。
答案 1 :(得分:2)
Serilog sink for SQL Server取决于.NET Core中尚未包含的某些类型。工作开始重构接收器并删除依赖项,但从那时起,所讨论的类型已添加到下一个.NET Core版本中:
https://github.com/dotnet/corefx/pull/12426
由于这个原因,Serilog SQL Server接收器很可能只保留.NET Framework,直到下一个.NET Core / .NET Standard版本发布,之后将很快添加支持。
在此期间,快速编写自己的print(total_strange_caps(["Five","FiVe","fIVE"]))
print(total_strange_caps(["fIVE"]))
print(count_strange_caps("fIVE"))
将是一种合理的解除阻止方法。
答案 2 :(得分:0)
我想这个问题不是技术问题,而是一个哲学问题,那么我不提出答案,而是考虑:
在我的拙见中,微软凭借其Silverlight杀戮,UWP定位和“逃到云端”,承认失败了其整个专有软件开发的概念,因此解放dotnet平台只不过是给开发者的告别礼物,被欺骗了在他们的希望中。
就其本身而言,dotnet生态系统非常有前途,但它的未来与之前的微软产品几乎没有关系。至少,我希望作为一名开发人员已经使用微软产品超过二十年。因此,专注于具体Microsoft产品的常见基础架构库(我的意思是当前情况下的MS SQL Server)现在正在消亡。
因此,结论是:如果你已经有一个与SQLServer紧密结合的长期项目,也许最好为你当前的日志解决方案改编做一些努力,否则最好寻找一些日志解决方案,而不是依赖于MSSQL。可能它应该通过适配器或类似的东西支持不同的存储。
尝试查看this,他们在下一个版本中声明Core支持,至少这是一个实时项目。