admin 为什么.Net程序员不用Linux服务器？是单纯得不喜欢吗？
通常，在服务器上部署的程序有两种，第一种就是Web服务，第二种就是应用程序服务。Web服务就不说了，目前.Net Core可以一个命令在Linux服务器上启动Web服务。
因此，导致.Net程序员不喜欢使用Linux服务器的原因，其实是应用程序服务！
.Net项目多数以C/S项目为主
一般来说，典型的应用程序框架应该由一个远程服务（WindowsService）加上程序客户端组成，也就是我们常说的C/S模式。
这里特别说下，广义的C/S模式，其实讲得是Client+Service（客户端+服务端）模式，符合这种模式的基本都可以定义为C/S项目。但为了区分Web程序和PC程序，Web程序虽然也符合Client+Service这个特征，但是我们通常称之为B/S模式。
因为C/S模式下，服务端通常以服务形式存在，而.Net服务目前只支持使用.Net Framework编写，因此，.Net的C/S软件服务就只能安装在Windows服务器下了。
但是，我查了下相关资料，据说有办法将WindowsService部署在Linux服务器下，并且像WindowsService那样运行。但是，我没亲自试验过，也不知道好不好用，可行不可行。
如果单说WindowsServics，可能很多人都会说可以使用WebApi替代WindowsService！是的，的确可以这样去做，并且也不会出现任何问题。
但是，一些使用.Net作为技术栈公司即使使用WebApi，也不会使用Linux作为服务器，这是为什么呢？这主要是.Net历史问题导致的！
为了照顾旧项目
第一个版本的.Net Core没记错的话，应该是2016年推出的，即使有使用.Net作为技术栈的公司从2016年就开始使用.Net Core，到如今连十年都不到。更何况，第一个版本的.Net Core推出以后，其实基本上很少有公司愿意“第一个吃螃蟹”。据我了解，大部分使用.Net作为技术栈的公司，基本上都是从.Net Core3.1开始重视并使用.Net Core这个可以跨平台的框架作为新的.Net技术栈的。.Net Core开始在.Net圈子普及，也只能说从.Net5开始，而.Net5则是2023年发布的。
在此之前，.Net的C/S项目后端服务要么是以传统的WindowsService形式存在，要么就是以WebApi形式存在，当使用.Net作为技术栈的公司开始切换到.Net Core以后，以前的项目如果切换成.Net Core的话，需要花费的代价是很高的。所以，只能让以前的项目继续在.Net Framework框架下运行，新项目则使用.Net Core。
这样的话，虽然.Net和.Net Core都是以CSharp作为主要编程语言的，但是实际上已经是两套技术框架了。
于是，就出现了一个问题，如果新项目即.Net Core的项目部署在Linux上，那么就必须购买独立的Linux服务器，尤其是有些服务如果上云的话，这对于公司来说是一笔不小的开支。而且，因为一般使用.Net作为技术栈的公司，基本上不是互联网公司，软件服务基本不上云，都是给客户独立部署的，因此，服务器这块的支出是需要客户自己解决的。如果搞两套服务器，无疑就会增加客户成本了。而维护两套不同的服务器，也是需要额外支出精力的！
如果把新项目的服务直接部署在原有旧项目的服务器上呢？问题是不是就迎刃而解了？
前面说了那么一大堆铺垫，其实道理就是那么简单，总结下就是使用.Net作为技术栈的公司，因为过去.Net不开源、不跨平台，因此大部分.Net项目都是基于.Net Framework做的。当.Net Core发布以后，虽然开源了、跨平台了，但是因为旧项目只能运行在Windows服务器下，因此为了节省开支、维护方便，所以，使用.Net作为技术栈的公司更愿意将.Net项目部署在Windows服务器下面，而不使用Linux服务器。
结语
目前都在拥抱Linux，.Net程序员目前的这种状况未来可能会在.Net全面转向.Net Core的时候改变。
但话又说回来了，不管使用Linux服务器还是Windows服务器，其实都是一种选择，没必要因为别人都说Linux服务器好而放弃使用Windows服务器，适合自己的才是最好的。这就像目前大多数.Net Core WebApi仍然部署在IIS上一样。
特别
