最近使用 .NET Core 遇到的一些坑

 

 

最近.NET Core升级到2.0后开始慢慢捣鼓的多了起来，但遇到了很多坑,因此特来记录下。

第一个坑  条件编译符

　　咱们在编写一些方法的时候一般会为Debug模式增长一些输出日志等以便咱们检查，也会为Release模式增长或修改一些特定的参数，但今天我在写这些的时候就遇到了这个坑
#if !DEBUG  #endif 中间的代码 不能我怎么更改配置环境 始终是灰色，这让我开始怀疑，难道VS 2017 的.NET Core 不支持条件编译符了？ 

因而新建了个控制台程序测试了如下，但又发现仍是起做用了的以下：

这里就能够 看到 我明明不是Debug环境啊，但是 #if DEBUG的仍是正常色，！DEBUG的仍是灰色，直接F5运行后 发现结果出乎我意外

结果竟然是正常的，如何我又怀疑是我vs 更新后出问题了，因而我又用.net framework 旧格式建立一个了一个项目发现旧的又是好的

第二个坑  .NET Core MVC下的部分文件没法下载

　　 使用.NET Core MVC建立了一个站点，原本使用的还蛮好的，但后来配备了app 因而就直接把apk 文件放到 网站的wwwroot目录下了，改了个名字就叫app.apk，而后访问： http://127.0.0.1/app.apk 返回给我一个404 not find 

 

由于搞iis 仍是比较多，因而立刻想到一个是天天添加 mime致使，因而去iis站点里面增长，发现以及存在了

瞬间就懵逼了，因而就从到请求筛选里面去找找是否是在那被禁止了 但发现也没用，因而又把文件改为app.apk.zip试了下,发现zip是能够下载的

 

 

 

 

------------

21号中午更新，

这个问题感谢@蜗牛往前走的指点，因此才记原由为iis只是一个代理了，因此本身捣鼓了一个解决方案，就是在appsettings.json配置里面配置

以下

在到设置Startup.cs的添加代码

 public void ConfigureServices(IServiceCollection services)
        {
            services.Configure<Dictionary<string,string>>(Configuration.GetSection("Mime"));
            services.AddMvc();
            services.AddDbContext<ApplicationDataContext>(options => options.UseSqlServer(Configuration.GetConnectionString("SqlServerConnection")));
        }

 public void Configure(IApplicationBuilder app, IHostingEnvironment env, IOptions<Dictionary<string, string>> option)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
                app.UseBrowserLink();
            }
            else
            {
                app.UseExceptionHandler("/Home/Error");
            }
            // app.UseStaticFiles()  //使用新的配置文件方式使用
            var provider = new FileExtensionContentTypeProvider();
            foreach(string key in option.Value.Keys)
            {
                provider.Mappings.Add(key, option.Value[key]);
            }
            app.UseStaticFiles(new StaticFileOptions() { ContentTypeProvider = provider });
            app.UseMvc(routes =>
            {
                routes.MapRoute(
                    name: "default",
                    template: "{controller=Home}/{action=Index}/{id?}");
            });
        }

 

 由于FileExtensionContentTypeProvider默认的构造函数mime基本已经定死了 而。NET core的网站 不少是不采起iis设置的
FileExtensionContentTypeProvider代码地址 你们能够去看看https://github.com/aspnet/StaticFiles/blob/dev/src/Microsoft.AspNetCore.StaticFiles/FileExtensionContentTypeProvider.cs

 

第三个坑  .NET Core  2.0 MVC 的试图文件

        从2.0开始貌似试图文件被直接打包成了dll文件，不在像传统的mvc同样发布后仍是shtml文件，而是被编译成了dll文件 命名规则是 项目名称.PrecompiledViews.dll

 

 第四个坑  .NET Core  引用DLL问题

        咱们之前开发老是把一些经常使用的某些功能性的单独作成一个类库 编译成dll 后供项目使用，但这样作好像在.NET Core的项目中行不通

起初我写了一个公共的类库，在解决方案里面又新增了一个类库，去引用公共类库的项目，这样作的时候并无什么异常，但当我启动另一个vs建立一个新的解决方案添加项目在去引用公共类库的dll后 在vs里面写代码都很正常，代码提示也都有

可是一按F5 调试就出来坑了，报未能找到类型或命名空间

 

解决方案是把公共类库打包 生成NuGet包

 

而后经过管理NuGet包添加引用，但不少状况下 一些类库我并不想都放到nuget.org上面，能够把生成的nuget包放置Microsoft Visual Studio Offline Packages 离线包里面

放到Microsoft Visual Studio Offline Packages对应的目录便可