- NetCore Vue IIS 开发流程参考 解决vue-route无法路由的问题
- 部署流程
- 步骤1. 搭建项目
- swagger配置
- 配置静态首页index.html 和 自定义静态文件目录
- 步骤2. 发布项目到指定目录
- 步骤3. 安装IIS的NetCore Hosting Runtime
- 步骤4. 安装IIS的Url重写功能（重要）
- 安装的原因
- 使用建议
- 步骤5. 在IIS中新建网站，并指向第2步创建的目录
- 步骤6. 配置网站的Web.Config文件（重中之重）
- config配置参考
- 配置详解
- 第一个：staticContent
- 第二个：rewrite
- 第三个：handlers
- 第四个：aspNetCore
- 步骤7. 测试站点
今天将vue-admin前端项目，以及netcore webapi，集合在一起放到IIS上进行部署，发现遇到了一大堆的问题，最主要的问题是刷新浏览器时页面会报404错误。
以下作为我的一些开发心得，在这里记录一下，日后防止遗忘以备用。
如果有开发经验且遇到相同问题的hxd，可以直接看步骤4和步骤6，我相信你会回来感谢我的提供的重大帮助的。
另外本人vue初学者，还望各位看客多多指点一二
部署流程项目主要包含swagger UI，EFCore，日志用的是NLog，vue单页面程序放到wwwroot下面，并且设置有静态文件和默认首页，默认首页指向wwwroot根目录（自动查找到index.html）
目录如下：
我的项目是基于NetCore2.1写的，更高版本的NetCore项目开发的同学，可以进行一定程度的参考，主要流程如下：
1). 先简单写一份以netcore空项目搭建的webapi项目，添加swagger支持；
2). 发布项目到指定目录；
3). 安装iis对应的netcore2.1 hosting runtime；
4). 安装IIS的Url重写功能；
5). 在iis中新建网站，并指向第2步创建的目录；
6). 修改web.config中的内容；
7). 测试程序；
搭建netcore webapi或mvc项目，这个就没啥好说的了，因为不是本文讨论重点。
swagger配置我这里丢一份我的swagger配置上来，仅作参考，写在Startup里面的ConfigureServices，作为中间件的配置。
（我不建议在Program.cs上面写配置，在那里写很难看，而且很难整理，建议中间件的配置全写ConfigureServices里面）
#region swagger配置
services.AddSwaggerGen(c =>
{
c.SwaggerDoc("v1", new OpenApiInfo
{
Version = "v1.0.0",
Title = "后台管理系统接口文档"
});
// 为 Swagger JSON and UI设置xml文档注释路径
//获取应用程序所在目录（绝对，不受工作目录影响，建议采用此方法获取路径）
var xmlFile = $"{Assembly.GetExecutingAssembly().GetName().Name}.xml";
var xmlPath = Path.Combine(System.AppContext.BaseDirectory, xmlFile);
c.IncludeXmlComments(xmlPath);
});
#endregion
然后在Startup的Configure中启用swagger中间件
app.UseSwagger().UseSwaggerUI(c =>
{
c.SwaggerEndpoint("/swagger/v1/swagger.json", "1.0.1");
});
配置静态首页index.html 和 自定义静态文件目录
关于静态首页指向到wwwroot目录，并配置一个自定义的静态文件目录，你可以参考如下的写法
#region 使用自定义静态文件：在StaticFiles文件夹下放置自己的文件
var provider = new FileExtensionContentTypeProvider();
foreach (string key in option.Value.Keys)
{
provider.Mappings.Add(key, option.Value[key]);
}
app.UseStaticFiles(new StaticFileOptions
{
FileProvider = new PhysicalFileProvider(
Path.Combine(env.ContentRootPath, "StaticFiles")),
RequestPath = "/StaticFiles",
ContentTypeProvider = provider
});
#endregion
#region 设置默认首页：wwwroot中识别index.html
app.UseDefaultFiles();
app.UseStaticFiles();
#endregion
步骤2. 发布项目到指定目录
发布程序这个只有一个我认为需要注意的点，就是发布前删除原文件夹下文件。
如果你是发布到已经部署到IIS的站点文件夹的话，可能会提示你发布失败之类乱七八糟的东西，你直接在IIS里面把已部署的网站停掉，再重新发布，就不报错了，具体发布整个操作怎么弄建议百度，这个超简单的，全是鼠标点点点，傻瓜式操作。
发布的时候建议删除发布目录的所有文件，免得搞一堆遗留文件在那里，如果你是想着备份或者别的什么，那可以发布前自行备份一下。
（前一版本和当前发布版本的文件不要混在一起，血的教训）
https://dotnet.microsoft.com/download/dotnet/2.1
微软提供的hosting runtime 去下载，不知道下哪一个的看下面的图
下这个hosting bundle，直接安装就完事了。
你可能会问，啊我的netcore是3.1的怎么办？你说怎么办，去搜3.1的hosting啊。只需要装这个最新版的就行，不需要和你的开发netcore的版本完全一致，但是一定要大于你的visual studio开发时候的netcore sdk版本，建议直接新版本就完事了。
安装的原因https://www.iis.net/downloads/microsoft/url-rewrite
这是微软官方提供的url重写工具地址，可能网址打开有点慢，但是肯定能打开，慢慢等就完事了
打开后点击页面上的唯一的绿色图标即可下载（整个页面就一个绿色的，写着 Install this extension 的图标，我就不截图了）
为什么要装这个重写功能组件？因为我们的Vue-Admin项目，配置的vue-router，默认是从根页面index.html请求的，并且从这里作为登录入口或者网站首页入口。
我的前端项目的话，也就是下图的path:’/’ 时，需要重定向到login.vue页面进行登录。
如果我们的web项目设置了默认首页，并开启了静态内容，而默认首页却指向到login.vue的话，是肯定打不开vue-admin单页面前端的，因为vue-admin是单页面的，就只有一个根入口index.html(其实也必须设置成指向index.html的目录)，其他的页面都是基于vue-admin封装的vue-router实现的浏览器本地路由。
这个和往常的前端不一样，这也是为什么需要url重写工具。它可以让页面指向配置的index.html路径，可以保证刷新网页后仍保留在原来的单页面上。
routes: [
{
name: 'login',
path: '/login',
component: () => import( '../components/page/Login.vue'),
meta: { title: '登录' }
},
{
path: '/',
redirect: '/login'
},
····(后面的路由省略了，懂我意思就行)
使用建议
安装好Url Rewirte的IIS组件后，网上很多教程是说在IIS管理器的url重写配置功能里去手写配置方案。
但是我这在里并不建议大家直接在IIS管理器里配置，我建议把配置写到web.config下面。
原因是，首先，是让你更容易懂得url重写是干嘛的，另一方面是方便发布和本地测试。
毕竟如果线上配置错了，你很难去排查，你是没办法把配置注释掉，然后debug的，只能把配置删了重新配，所以说纯ui界面也是有其缺陷的，只是说方便了一部分运维人员。
步骤5. 在IIS中新建网站，并指向第2步创建的目录稍微讲一下注意事项吧，其他的请百度搜 “NetCore如何发布到IIS上” ，这个主题应该很多人写了相关的文章了。
- 需要注意的是配置应用池的时候一定要选无托管代码
- 并且需要设置发布目录的文件夹权限，为可以同时读写文件夹的本地计算机账户，因为用户可能会通过IIS远程上传文件
具体的看图
设置好后可以点击上图中央的测试设置，看看是否正常。
重头戏来了，先上Config配置参考
配置详解
我们可以看到配置文件在system.webServer层级中，分了四个模块，分别是
staticContent、rewrite、handlers、aspNetCore
这个在代码块中有注释，实际上就是先尝试把IIS中的MIME对应格式取消注册，再重新注册一遍，写在配置里就可以一劳永逸，换任何一台电脑只要装好IIS就可以用。
第二个：rewrite这块的逻辑主要是增加了rules（规则），也就是url重写的规则。
规则的写法是：
- name 指的是：规则名称。
rule需要自定义一个你喜欢的规则名字，可以随便取，尽量简单点望文生义最好
- stopProcessing 指的是：停止后续重写规则的处理。
我这里是把stopProcessing设为true。意思是，本规则执行完就不执行后续的规则了，也就是停止后续的url重写规则处理
（我这里故意这样写出来，因为可能有自己加规则的需求，写出来大家遇到这东西也就好理解了，因为默认这个stopProcessing可以不加到参数中，默认是false关闭的）
- match 指得是：需要对此处匹配到的url进行当前规则判断。
我这里给的match规则是所有url都要判断，注意这个match匹配的是你源请求的url所有部分。
- conditions 指的是：规则条件。
条件可以设置多条，我这里设置了五条规则条件，并且写有注释
- input 指的是：IIS服务器解析url输入。
它可以帮你初步过滤请求的信息成你想要的部分，具体的有下方写的这么多类型，是IIS内置的，不可以自定义。如果需要自定义匹配请往后看
条件中input可选的参数主要有：
“CACHE_URL”
“DOCUMENT_ROOT”
“HTTP_URL”
“HTTP_HOST”
“PATH_INFO”
“PATH_TRANSLATED”
“QUERY_STRING”
“REQUEST_FILENAME”
“REQUEST_URI”
“SCRIPT_FILENAME”
“SCRIPT_NAME”
“SCRIPT_TRANSLATED”
“UNENCODED_URL”
“URL”
“URL_PATH_INFO”
"“APP_POOL_ID”
“APPL_MD_PATH”
“APPL_PHYSICAL_PATH”
“GATEWAY_INTERFACE”
“SERVER_SOFTWARE”
“SSI_EXEC_DISABLED”
最常用的主要是我用的那俩个，如果你有兴趣，想要知道每个参数都是什么意思，可以去IIS服务器变量自行查询，我在本小节最后给了几个最常用的匹配方式列表，供参考。
- matchType 指的是：匹配方式。
也是服务器内置的方式，好像只有两种：是否是文件IsFile和是否是文件夹IsDirectory。如果需要自定义匹配请往后看
- pattern 指的是：自定义匹配方式。
主要是字符串匹配或’正则表达式’匹配，IIS会自动识别出来，正则测试可以自行找在线测试网站自己试正则表达式，我这里就不赘述了
(我这里写的第三个条件就是对第一个第二个条件的补充，因为我实在懒得一个一个类型往上加，我直接来个只要结尾是字母+数字，并且前面带.号，我都认为他是请求的是资源文件)
- negate 指的是：将当前条件匹配的规则取反。
也就是“不”匹配的时候，默认为flase，我这里给的是true
- action 指的是：如何进行url重写。
我这里直接给他返回到了网站的根目录。也就是index.html所在的位置
- 所以整个规则理解出来就是如我注释写的那个意思，请自行消化理解一下
一个完整的url的规则应该是这样的：http(s) : // [host] (:[port]) / [path] ? [querystring]
假如有一个url是：http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3
那么对应的常见input参数匹配的输入结果如下：
| 参数 | 匹配值 |
|---|---|
| QUERY_STRING | tabid=2&subtabid=3 |
| HTTP_HOST | www.mysite.com |
| SERVER_PORT | 80 |
| SERVER_PORT_SECURE | 0 （https则为off） |
| REQUEST_URI | /content/default.aspx?tabid=2&subtabid=3 |
| PATH_INFO | /content/default.aspx |
里面是IIS中对此网站需要需要应用的模块进行注册，没啥好说的，照抄就完事了。
这里应用的模块就是我们在第三步中安装的NetCore Hosting Runtime模块，说点题外话，这个模块目前是微软开源的开发状态，有兴趣的可以自行了解一下，netcore项目就是借助这个模块实现了和IIS的解耦合。
自然是指出handlers中配置的aspNetCore模块进行网站启动了，后面的stdoutLogEnable="true"是指打开IIS的日志记录功能，stdoutLogFile=".logsstdout"自然是指日志输出目录了。
步骤7. 测试站点测就完事了，这时候网站的swagger UI，api接口，还有vue的单页面的实现，应该都彻底正常工作了
这次项目发布最大的收获就是把web.config里面很多东西重新整理了一边，更加懂得了配置的具体含义。
希望本文能对你有所帮助。
