在此前的文章中详细介绍了使用.NET Core的基本知识，如果还没有看，可以先去了解“拥抱.NET Core，学习.NET Core的基础知识补遗”，以便接下来的阅读。
有一部分代码只是用来调试使用，不期望在发布的时候执行。也有一些代码只是用来测试性能，也不期望在其他时候使用。在做源代码包的时候，我需要对不同的平台使用不同的代码。此时就可以用到条件编译符，在不同的条件下编译不同的代码
在写项目文件的时候，需要根据不同的条件定义或执行不同的代码，有一些比较常使用的判断，本文收藏起来，方便大家找
项目文件中的已知属性（知道了这些，就不会随便在 csproj 中写死常量啦） - walterlv
在.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 样式项目中的目标框架来支持一套代码同时输出多版本类库。
发布于 2018-01-15 16:04 更新于 2018-09-07 04:40
在使用新的项目格式，可以使用 Target 添加项目，但是有一些项目需要在合适的时候添加，如果添加早了，那么会让用户看到这些文件，如果添加的时间是在引用编译之后，那么文件将无法进行编译。
在使用 sdk style 的 csproj 项目格式，会发现右击引用找不到程序集，此时有一些命名空间没有找到。本文收集一些命名空间所在的引用
本篇主要讨论.NET Core应用程序项目结构的主题，重点探索.NET Core应用程序的多平台编译问题，这里指的多平台是指.NET Framework、.NET Core App、.NET Standard、Mono、UWP等多平台的条件编译、项目（包）引用、编译符号等问题。
本文主要是关于.NET Standard 代码 在多框架 和 多平台 支持自己实践过程中遇到的一些问题和解决办法，希望给遇到这些问题的同学一点参考和思路。问题基本上都是提在 博问 和 Stackoverflow 中，不乏很多大佬都提供了解决问题的思路。接下来则是正文。
在nuget中下载ServiceStack.Redis，但是运行之后会出现一个问题:
.NET Standard 引用程序集的主要分发载体是 NuGet 包。 实现会以适用于每个 .NET 实现的各种方式提供。
去年年中，Rafy 框架的源码就已经支持了 Net Standard 2.0 版本。其开源代码也已经上传到 Github 中：https://github.com/zgynhqf/rafy/tree/NetStandard2.0 。但是这都只是在源码层面支持 NS2.0，并没有发布其正式的 Nuget 包。要使用这个版本的开发者，不得不自己下载源码进行编译。
去年中我曾考虑将我的控件库项目Kino.Toolkit.Wpf升级到.NET Core，不过很快放弃了，因为当时.NET Core是预览版，编译WPF还需要使用最新的Visual Studio 2019，这样作为一个教学项目不够友好。到了今天.NET Core 3.1都出来了，已经正式支持WPF和Winform，Visual Studio 2019也已经普及，我觉得应该是时候将我的控件库升级到.NET Core。那么现在是WPF正式迁移到.NET Core的好时机吗？我认为还不是，把一个成熟的WPF程序迁移到.NET Core风险任然较大，而且不见得有多少好处。但对各种WPF类库/控件库来说情况又不一样了，为了可以满足更多的用户，让控件库可以同时支持.NET Framework和.NET Core十分重要；而且通常类库对其它组件的依赖较少，升级的风险没那么大。所以要玩.NET Core的WPF，从类库/控件库开始是一个好的选择。
FreeSql 经过半年的开发和坚持维护，在 0.6.x 版本中完成了几大重要事件：
以前的项目格式使用的是 csproj 的格式，但是 .net core 支持使用 project.json 格式的项目文件，后来还是决定不使用这个格式。 VS2017 的项目格式更好读、更简单而且减少了 git 冲突。 本文来告诉大家如何从 VS2015 和以前的项目格式修改为 VS2017 项目格式。
本文是 手把手教你写 Roslyn 修改编译 的文章，在阅读本文之前，希望已经知道了大多数关于 msbuild 的知识
在 sdk style 的项目格式支持使用多框架开发，此时需要在代码里面通过宏判断，在编译的时候执行不同的代码。本文告诉大家在框架里面对应的预定义的条件编译符有哪些
在前一篇博客《.NET Standard中配置TargetFrameworks输出多版本类库》中详细介绍了如何创建、配置、条件编译、引用本地程序集、NuGet方式引用程序集、XML文档输出、编码与DEBUG 调试、自动生成内部版本号、文件复制等功能。但是Visual Studio中也存在一些使用不方便的地方，本文介绍一些开发中的小技巧。
packages.config <?xml version="1.0" encoding="utf-8"?> <packages> <package id="Microsoft.AspNet.W
发布于 2018-01-21 03:28 更新于 2018-08-31 09:56
实际报错如图： 如果你跟我一样是在折腾Asp.Net WebApi 2.x时遇到这个问题，请参看如下办法： 删除现有System.Net.Http.Formatting引用（如果引用了的话） 重新引用
今天是 2020.11.13 我在 CI 服务器上更新 dotnet 到 dotnet 5 以及 VS 到 16.8.1 最新版本，但是我在刚刚不得不回滚了环境…… 因为构建不通过
在使用 using 等新语法时，在 VisualStudio 2019 会自动判断框架版本，如在 net 45 就不会自动使用最新版本的语法，需要修改项目文件
内网搭建NuGet服务器，实现像Maven管理jar包一样，管理dll，搭建公司内部的dll管理平台，避免不同版本到处拷贝引起的版本冲突和dll更新混乱的问题
很多情况下，我们编写了一些工具库之后，往往在某些框架版本中会出现一些问题，比如本人最近写的一个导入导出的工具库Magicodes.IE（GitHub：https://github.com/xin-lai/Magicodes.IE）就出现了以下问题：
当 A 项目引用 B 项目，那么使用 Visual Studio 或者 MSBuild 编译 A 项目之前就会确保 B 项目已经编译完毕。通常我们指定这种引用是因为 A 项目确实在运行期间需要 B 项目生成的程序集。
本文介绍如何使用 .NET CLI 编写 .NET 的库。 CLI 提供可跨任何支持的 OS 工作的高效低级别体验。 仍可使用 Visual Studio 生成库，如果你首选这种体验，请参阅 Visual Studio 指南。
本文告诉大家如果在 Nuget 引用源代码的方式引用源代码，在 VisualStudio 的智能提示和 Resharper 的智能提示都能找到对应的类，但是在 VisualStudio 编译或使用命令行 msbuild 编译时提示找不到类
在写预编译框架，因为安装项目会基于多个平台，也就是对应的 Target 会执行多次，而我需要的只是执行一次就可以
在项目编译成 dll 之前，如何分析项目的所有依赖呢？可以在在项目的 Target 中去收集项目的依赖。
PanuonUI.Silver是国内优秀的WPF开源控件库，Panuon.UI的优化版本。一个漂亮的、使用样式与附加属性的WPF UI控件库，值得向大家推荐使用与学习。
本文带大家走进SourceYard开发之旅 在项目开发中，将一个大的项目拆为多个小项目解耦，减少模块之间的耦合。因为如果将代码放在一起，即使有团队的约束，但只要能写出的代码就会有小伙伴写出，很快就发现各个模块耦合的代码很多。但是对一个项目的拆分会让拆分出来的每一个项目都编译出一个 dll 增加运行文件的启动时间。 在开发中，常常会用到很多工具类，这些小轮子很多的功能基本就只有一个类，如何对这些小轮子进行管理？通过复制代码还是通过 Nuget 管理？
当一个单体软件产品体量达到一定程序，都会想到拆分为不同的模块（当今这么流行微服务）。拆分后一定会存在进程之间的交互（简称：PRC），那么thrift就是facebook推出一款开源的rpc框架，且还跨语言。此文章就是来打开thrift的打开（当然这次还是基于.net）。 示例代码下载：https://gitee.com/samtest-project/thrift-test.git
正常如果你想写一个 .NET 的 NuGet 包，直接打包就好了，你的引用程序集会出现在 NuGet 包内的 lib 文件夹内。然而，如果我们的 NuGet 包包含本机依赖的话怎么办呢？
作为团队里面挖掘机出身的我，怎么能不多挖一些坑好将小伙伴们都埋进去呢。本文来告诉大家一个有趣且简单的方法，此方法可以将本机的 WCF 玩坏，不敢说真的搞炸本机所有 WCF 应用，但搞炸大部分基于 WCF 的软件还是没有问题的。阅读本文，你可以不仅可以了解到有这样的逗比方法，更重要的是在你的 WCF 模块炸掉的时候，你知道要甩锅给谁
由于ASP.NET Web API具有与ASP.NET MVC类似的编程方式，再加上目前市面上专门介绍ASP.NET Web API 的书籍少之又少（我们看到的相关内容往往是某本介绍ASP.NET MVC的书籍“额外奉送”的），以至于很多人会觉得ASP.NET Web API仅仅是ASP.NET MVC的一个小小的扩展而已，自身并没有太多“大书特书”的地方。而真实的情况下是：ASP.NET Web API不仅仅具有一个完全独立的消息处理管道，而且这个管道比为ASP.NET MVC设计的管道更为复杂，功能也更
本文告诉大家如何使用 msbuild 的 ProduceOnlyReferenceAssembly 功能，将某个程序集里面仅导出其中的公开成员定义，而不包含具体的实现的方法
在 Resharper 更改全部命名空间之后，在 xx.g.cs 文件里面的 using 用了一个之前的命名空间，但是代码里面没有地方使用，此时构建不通过，原因是 xaml 里面存在引用
很多情况下，我们编写了一些工具库之后，往往在某些框架版本中会出现一些问题，比如本人最近写的一个导入导出的工具库Magicodes.IE就出现了以下问题：
NewLife.XCode是一个有15年历史的开源数据中间件，支持netcore/net45/net40，由新生命团队(2002~2020)开发完成并维护至今，以下简称XCode。
发布于 2018-09-11 13:28 更新于 2018-09-13 03:24
本文记录 WPF 在 .NET Framework 4.5 和 .NET Core 3.0 或更高版本对使用 Binding 下的 TwoWay 双向绑定模式绑定到非公开的 set 属性上的行为变更
本文告诉大家如何在控制台使用 SharpDx 创建窗口，这是一个底层的博客，我会用很多博客告诉大家如何从控制台创建一个高性能渲染程序
.NET Core的新特性之一就是跨平台，但由于对之前框架的兼容导致编写一个.NET Core类库变得相当复杂，主要体现为相当多的框架目标和支持平台，今天我们就对.NET Core的跨平台特性进行一次梳理。
咱造了一个轮子，咱可以非常方便将这个轮子库作为 NuGet 发布出去，造福其他开发者，或者毒害其他开发者。为什么说是毒害呢？因为有时候这个库存在坑，此时使用这个库的开发者就受到了伤害。为了安抚脆弱的开发者们，咱可以提高一下开发者们的调试效率，例如让开发者们可以调试到库里面的源代码 本文来告诉大家如何在项目文件里面添加上 EmbedAllSources 属性，将自己的代码嵌入到 PDB 符号文件里面，让开发者们在调试的时候，可以看到库的源代码
微服务和消息队列的基础都是RPC框架，比较有名的有WCF、gRPC、Dubbo等，我们的NewLife.ApiServer建立在网络库NewLife.Net之上，支持.Net Core，追求轻量级和高性能，只有最简单的远程调用功能。 现在是网络系列文章的第五篇，前面四篇快速过了一遍网络库基本用法，也做了压力测试并给出数字 2266万tps。 本章正式进入应用层面，并且采用.Net Core作为例程，说明我们一开始就支持.Net Core，也算是回答了很多支持者的疑问。 老规矩，先上代码：https://gi
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
