在.NET Standard/.NET Core技术出现之前,编写一个类库项目(暂且称为基础通用类库PA)且需要支持不同 .NET Framework 版本,那么可行的办法就是创建多个不同版本的项目(暂且称为PB1、PB2、PB3 ... PBn)。PB1、PB2、PB3 ... PBn项目分别执行下面操作:【添加】--【现有项】--【添加为链接的方式】,将PA项目代码文件添加到各自项目中,如果代码不同,则需要使用#if #else #endif 等标签来判断 .NET Framework 版本。而在.NET Standard/.NET Core技术出现之后,可以通过配置SDK 样式项目中的目标框架来支持一套代码同时输出多版本类库。
本文主要是关于.NET Standard 代码 在多框架 和 多平台 支持自己实践过程中遇到的一些问题和解决办法,希望给遇到这些问题的同学一点参考和思路。问题基本上都是提在 博问 和 Stackoverflow 中,不乏很多大佬都提供了解决问题的思路。接下来则是正文。
作为微软向其跨平台.NET产品发展的一部分,他们大大简化了项目文件格式,并允许第三方代码生成器与.NET项目的紧密集成。我们一直倾听,现在很自豪地介绍从Grpc.Tools NuGet包的1.17版本开始,.NET C#项目中的Protocol Buffer和gRPC服务.proto文件的集成编译。1.17版本现在可以从Nuget.org获得。
我有一个强大的功能,这个功能就是在 Linux 下使用 GDI 转换 EMF 格式图片为 png 图片,但是有一些有趣的图片会让转换的进程炸掉。因此我就想让转换服务放在独立的进程,通过进程间调用,也就是命令行调用传入参数的方式,让另一个进程转换图片。而此时就会遇到一个问题,如何让这个进程也被构建,然后输出到输出路径
跨平台兼容性已成为 .NET 库作者的主流要求。 但是,如果没有针对这些包的验证工具,它们通常就不能正常工作。 这对于新兴平台来说尤其成问题,因为这些平台的使用率不够高,难以引起库作者的特别关注。
在前一篇博客《.NET Standard中配置TargetFrameworks输出多版本类库》中详细介绍了如何创建、配置、条件编译、引用本地程序集、NuGet方式引用程序集、XML文档输出、编码与DEBUG 调试、自动生成内部版本号、文件复制等功能。但是Visual Studio中也存在一些使用不方便的地方,本文介绍一些开发中的小技巧。
代码链接:scirem/EntityFrameworkLovesUWP (github.com)
很多库都会在 nuget.org 上发布预览版本,不过一般来说这个预览版本也是大多可用的。然而想要体验日构建版本,这个就没有了,毕竟要照顾绝大多数开发者嘛……
去年年中,Rafy 框架的源码就已经支持了 Net Standard 2.0 版本。其开源代码也已经上传到 Github 中:https://github.com/zgynhqf/rafy/tree/NetStandard2.0 。但是这都只是在源码层面支持 NS2.0,并没有发布其正式的 Nuget 包。要使用这个版本的开发者,不得不自己下载源码进行编译。
包含兼容框架的包需要确保针对某个框架编译的代码可以针对另一个框架运行。 兼容框架对的示例包括:
首先打开你的库项目,或者如果你希望从零开始也可以直接新建一个项目。这里为了博客阅读的简单,我创建一个全新的项目来演示。
.NET Standard是 .NET API 的正式规范,可用于多个 .NET 实现。.NET Standard 背后的动机是在 .NET 生态系统中建立更大的统一性。如果要在 .NET Framework 和任何其他 .NET 实现(例如 .NET Core)之间共享代码,则库应面向 .NET Standard 2.0。
使用 .NET,可以创建和部署可生成项目、文件甚至资源的模板。 本教程是系列教程的第三部分,介绍如何创建、安装和卸载用于 dotnet new 命令的模板。
我在给 dotnet 的 runtime 仓库提PR时,小伙伴告诉我可以使用 TryAdd 方法减少判断,但是我修改这个代码发现 100 个自动化测试都失败了,都告诉我没有找到这个方法
FreeSql 经过半年的开发和坚持维护,在 0.6.x 版本中完成了几大重要事件:
Source Link是一组软件包和一个规范, 它将一些元数据添加到PDB文件,以将本地文件重新映射到GitHub上的文件,因此Visual Studio可以在这需要时下载文件, 该项目的目的是可以为使用Nuget安装软件的用户提供源代码调试, Microsoft库(例如.NET Core和Roslyn)都已启用Source Link。
Ocelot是为.net core量身定做的,目前是基于 netstandard2.0进行构建的。
结合使用这两项操作能充分发挥源生成器的强大功能。 可以使用编译器在编译时构建的丰富元数据检查用户代码。 然后,生成器将 C# 代码发送回基于已分析数据的同一编译。 如果你熟悉 Roslyn 分析器,可以将源生成器视为可发出 C# 源代码的分析器。 源生成器作为编译阶段运行,如下所示:
.NET Standard 引用程序集的主要分发载体是 NuGet 包。 实现会以适用于每个 .NET 实现的各种方式提供。
不知你是否好奇,System.ValueTuple 是新框架(.NET Core 3.0)开始引入的类型,但可以通过 NuGet 包向旧框架提供这些类型的使用。并且,这些包即便安装到本来就有此类型的新框架上也能正常运行而不会出现多处类型定义的问题。
本文以 dotnetCampus.Ipc 项目为例,来说明如何为一个现成的 .NET 类库添加自动生成代码的功能。这是一个在本机内进行进程间通信的库,在你拥有一个 IPC 接口和对应的实现之后,本库还会自动帮你生成通过 IPC 代理访问的代码。由于项目加了 Roslyn 的 SourceGenerator 功能,所以当你安装了 dotnetCampus.Ipc NuGet 包 后,这些代码将自动生成,省去了手工编写的费神。
2018-06-24 11:43
当 A 项目引用 B 项目,那么使用 Visual Studio 或者 MSBuild 编译 A 项目之前就会确保 B 项目已经编译完毕。通常我们指定这种引用是因为 A 项目确实在运行期间需要 B 项目生成的程序集。
本文介绍如何使用 .NET CLI 编写 .NET 的库。 CLI 提供可跨任何支持的 OS 工作的高效低级别体验。 仍可使用 Visual Studio 生成库,如果你首选这种体验,请参阅 Visual Studio 指南。
发布于 2018-06-24 13:10 更新于 2018-09-01 00:02
很多情况下,我们编写了一些工具库之后,往往在某些框架版本中会出现一些问题,比如本人最近写的一个导入导出的工具库Magicodes.IE(GitHub:https://github.com/xin-lai/Magicodes.IE)就出现了以下问题:
以前的项目格式使用的是 csproj 的格式,但是 .net core 支持使用 project.json 格式的项目文件,后来还是决定不使用这个格式。 VS2017 的项目格式更好读、更简单而且减少了 git 冲突。 本文来告诉大家如何从 VS2015 和以前的项目格式修改为 VS2017 项目格式。
本文告诉大家如何使用 msbuild 的 ProduceOnlyReferenceAssembly 功能,将某个程序集里面仅导出其中的公开成员定义,而不包含具体的实现的方法
作为了解历史和演进过程,我们需要将 .Net Framwork 、.Net、 .Net Stander几个概念进行下理解。 .net 代表跨平台框架,从.net 5开始就统一叫.net,废弃原来的.net core 叫法。由于太多名字防止混淆,我们就不管.net core了。
时机决定一切,对于 .NET5 也是如此。实际上微软.NET团队在开始开发 .NET Core 时,对 .NET Framework 的全面重写是不可想象的。当时Microsoft 正在响应在 Linux、容器中和 PaaS 上显著增强 Azure 托管体验的需求。因此,公司专注于推出一些产品来满足客户和 Azure 产品团队的需求。
正常如果你想写一个 .NET 的 NuGet 包,直接打包就好了,你的引用程序集会出现在 NuGet 包内的 lib 文件夹内。然而,如果我们的 NuGet 包包含本机依赖的话怎么办呢?
2018-06-26 03:26
前面我们使用了IIncrementalGenerator来生成代码,接下来我们来详细了解下IIncrementalGenerator的核心部分IncrementalValueProvider。
一、本地dll如何打包,以及版本的更新 本小节主要介绍两种方式将本地dll打包为Nuget包, 1.1 利用nuget.exe进行打包(应用于.net framework) 1. 下载nuget.ex
在项目文件的相同文件夹可以放一个 nuspec 用来告诉 VisualStudio 如何打包
本文告诉大家 Directory.Build.props 是什么有什么优点?如何使用 Directory.Build.props 文件定义编译
我想目前每个.net开发人员都应该知道nuget.org和NuGet软件包吧。但是,您是否曾经尝试并创建过一个nuget包呢?Nuget软件包比较容易引入到类库中。因此,可以使用NuGet软件包管理器将nuget软件包添加到任何项目中。
本文告诉大家如何在使用 IIncrementalGenerator 进行增量的 Source Generator 生成代码时,如何判断两个程序集之间是否存在 InternalsVisibleTo 关系
它们直接与 C# 编译器集成(Roslyn)并在编译时运行,分析源代码并根据分析结果生成附加代码。
在 wenjq0911 建议下,添加了异常捕获,现 Natasha 的编译器已支持 Exception 字段,它将在整个编译周期中搜集异常。
从本质上讲,按照CLI规范设计的.NET从其出生的那一刻就具有跨平台的基因,这与Java别无二致。由于采用了统一的中间语言,微软只需要针对不同的平台设计不同的虚拟机(运行时)就能弥合不同操作系统与处理器架构之间的差异,但是“理想很丰满,现实很骨感”。在过去十多年中,微软将.NET引入到了各个不同的应用领域,表面上看起来似乎欣欣向荣,但是由于采用完全独立的多目标框架的设计思路,导致针对多目标框架的代码平台只能通过PCL(参考《.NET Core跨平台的奥秘[中篇]:复用之殇》)这种“妥协”的方式来解决。如果依
2018-06-20 01:22
在开始编写 dotnet 的 Roslyn 分析器项目时,会被 VisualStudio 通过 RS1036 要求在项目文件配置上 EnforceExtendedAnalyzerRules 属性,本文将和大家介绍 EnforceExtendedAnalyzerRules 属性的作用
在经过了两年的准备,以及迁移了几个应用项目积累了让我有信心的经验之后,我最近在开始将团队里面最大的一个项目,从 .NET Framework 4.5 迁移到 .NET 6 上。这是一个从 2016 时开始开发,最多有 50 多位开发者参与,代码的 MR 数量过万,而且整个团队没有一个人能说清楚项目里面的所有功能。此项目引用了团队内部的大量的基础库,有很多基础库长年不活跃。此应用项目当前也有近千万的用户量,迁移的过程也需要准备很多补救方法。如此复杂的一个项目,自然需要用到很多黑科技才能完成到 .NET 6 的落地。本文将告诉大家这个过程里,我踩到的坑,以及学到的知识,和为什么会如此做
因为 Visual Studio 有强大的包管理器插件,所以即便是不熟悉 NuGet 命令的小伙伴也能轻松安装和管理 NuGet 包。不过,对 Unity C# 项目来说,你并不能直接引用 dll,也不能直接使用自带的 NuGet 包管理器完成 NuGet 包安装。
.NET诞生以来,程序集的动态加载和卸载都是一个Hack的技术,之前的NetFx都是使用AppDomain的方式去加载程序集,然而AppDomain并没有提供直接卸载一个程序集的API,而是要卸载整个AppDomain才能卸载包含在其中的所有程序集。然而卸载整个CurrentAppDomain会使程序不能工作。可能有人另辟西经,创建别一个AppDomain来加载/卸载程序集,但是由于程序集之间是不能跨域访问的,也导致只能通过Remote Proxy的方式去访问,这样在类型创建和使用上带来了一定的难度也是类型的继承变得相当复杂。
Razor Page Library 是ASP.NET Core 2.1引入的新类库项目,属于新特性之一,用于创建通用页面公用类库。也就意味着可以将多个Web项目中通用的Web页面提取出来,封装成RPL,以进行代码重用。 官方文档Create reusable UI using the Razor Class Library project in ASP.NET Core中,仅简单介绍了如何创建RPL,但要想开发出一个独立通用的RPL远远没有那么简单,容我娓娓道来。
发布于 2018-04-12 13:03 更新于 2018-08-29 01:36
领取专属 10元无门槛券
手把手带您无忧上云