关键文件和目录结构 按照asp.net core WEB应用程序向导,创建一个工程之后 你会发现如下几个目录和文件 wwwroot:放置网站的静态文件的目录 Pages:放置razor页面的目录 appsettings.json:是应用的配置文件 bower.json:静态资源包管理的配置文件 Program.cs:这个程序负责承载ASP.NET Core应用 Startup.cs:初始化service的配置,初始化请求管道 下面我们单独说一下Pages目录 _Layout.cshtml 是整个网站的母板文
由于asp.net 处理进程在machine.config配置文件中的配置为<processModel autoConfig="true" />,这意味着你的asp.net 应用程序使用的性能参数依赖于machine.config的配置。 下面几个参数是自动配置的: maxWorkerThreads 和 maxIoThreads minFreeThreads 和 minLocalRequestFreeThreads minWorkerThreads maxconnection executionT
异常处理汇总-后端系列 http://www.cnblogs.com/dunitian/p/4523006.html 这篇没啥技术含量,用来小记一番 错误信息 “System.InvalidOperationException”类型的异常在 System.Web.dll 中发生,但未在用户代码中进行处理 其他信息: 现在无法开始异步操作。异步操作只能在异步处理程序或模块中开始,或在页生存期中的特定事件过程中开始。如果此异常在执行 Page 时发生,请确保 Page 标记为 <%@ Page Async="t
DbContextPool 是 ASP.NET Core 2.1 引入的新特性,可以节省创建 DbContext 实例的开销,但没有想到其中藏着一个小坑。
1、官网地址 https://docs.microsoft.com/zh-cn/ef/core/cli/powershell#scaffold-dbcontext 2.命令说明 Scaffold-DbContext 为 DbContext 数据库的和实体类型生成代码。 为了使 Scaffold-DbContext 生成实体类型,数据库表必须具有主键。 参数: SCAFFOLD-DBCONTEXT 参数 说明 -连接 <String> 用于连接到数据库的连接字符串。 对于 ASP.NET Co
本文介绍了EF Core 2.0的新特性和改进,包括实体、表、查询、性能提升和查询方面的内容。
最近在把自己的一个老项目从Framework迁移到.Net Core 3.0,数据访问这块选择的是EFCore+Mysql。使用EF的话不可避免要和DbContext打交道,在Core中的常规用法一般是:创建一个XXXContext类继承自DbContext,实现一个拥有DbContextOptions参数的构造器,在启动类StartUp中的ConfigureServices方法里调用IServiceCollection的扩展方法AddDbContext,把上下文注入到DI容器中,然后在使用的地方通过构造函数的参数获取实例。OK,没任何毛病,官方示例也都是这么来用的。但是,通过构造函数这种方式来获取上下文实例其实很不方便,比如在Attribute或者静态类中,又或者是系统启动时初始化一些数据,更多的是如下一种场景:
今天在发布Asp.net Core应用到Azure的时候出现错误InvalidOperationException: Cannot find compilation library location for package ‘Microsoft.Win32.Registry’ 具体信息如下 2018-04-01 12:44:37.141 +00:00 [Fatal] Hosting startup assembly exception System.InvalidOperationException: S
微软的Entity Framework 受到越来越多人的关注和使用,Entity Framework7.0版本也即将发行。虽然已经开源,可遗憾的是,国内没有关于它的书籍,更不用说好书了,可能是因为EF版本更新太快,没人愿意去花时间翻译国外关于EF的书籍。使用Entity Framework开发已经有3年多了,但用得很肤浅,最近想深入学习,只好找来英文书《Entity Framework 6 Recipes》第二版,慢慢啃。首先需要说明的是,我英文不好,只是为了学习EF。把学习的过程写成博客,一是督促自己,二是希望能帮助有需要的朋友。EF是微软极力推荐的新一代数据库访问技术,它已经成熟,做为一名.NET开发人员,如果你还没有使用它的话,那感紧开始吧,特别是DDD(领域驱动设计)的爱好者,更应该学习它,因为它是领域模型的绝佳搭档!另外,本书也是一本关于EF的佳作(其实,英文的关于EF的书也就那么几本,中文的目前还没有,只有一些零星的资料,这会让初学者会感觉到混乱,特别是什么EDMX文件、Code First、Model First、Database First、表拆分,实体拆分,TPT,TPH,TPC,CodeFirst和DDD的配合等等),就从本系列开始对EF进行一个系统的学习吧,老鸟也可以从中了解不少的知识点。文中肯定有很多翻译不当的地方,恳请你指正,以免误导大家。谢谢!由于书中的代码只贴出核心部分,如果你想运行示例代码,可以加入QQ群下载,因为太大,超过博客园的限制,所以这里提供不了下载。要说的就这么多,下面就开始这一段学习过程吧。
对于MVC的编程,主要应该先了解M(模型)-V(视图)-C(控制器)的相关概念,并进而理解相关的框架类别及操作方法.
笔者在项目中做做了一个从Excel表格中导入数据的模块、大体上asp.net项目中导入Excel大体分成三类:
该文章介绍了.NET中的HttpSessionStateBase类,它提供了存储会话状态的方法,并提供了从会话状态中检索数据的公共方法。此外,该类还提供了同步访问会话状态的方法,以确保线程安全。
开篇:上一篇我们了解了一个ASP.Net页面请求的核心处理入口,它经历了三个重要的入口,分别是:ISAPIRuntime.ProcessRequest()、HttpRuntime.ProcessRequest()以及HttpApplication.Init()。其中,在HttpApplication的Init()方法中触发了请求处理管道事件的执行,本篇我们就来看看所谓的请求处理管道。
我们前面已经讨论过了如何在一个网站中集成最基本的Membership功能,然后深入学习了Membership的架构设计。正所谓从实践从来,到实践从去,在我们把Membership的结构吃透之后,我们要完善它,改造它,这样我们才能真正学以致用。今天我们将以用户信息为主线,从SqlMembershipProvider出发,到ASP.NET Simple Membership最后再到MV5中引入的ASP.NET Identity,来看看微软是如何一步一步的改造这套框架的。 引入 - 用户信息是如何存在数据库
本文主要介绍了ASP.NET Web API的背景、使用方法和核心对象,包括HttpRequestMessage、HttpResponseMessage、HttpClient等,并分析了如何使用这些对象来处理HTTP请求和响应。
在项目开发中,我们会使用到很多的描述性文字,比如验证消息、错误消息和确认消息等,让这些文本消息具有可维护性具有重要的意义。虽然我们可以将它们存储于资源文件中,并且ASP.NET的ValidationAttribute也对这种方式提供了原生的支持。但是资源文件的每个条目仅仅是简单的键-值对,只能存储消息的文本值而已,在我们的项目开发中使用的是专门的一个维护消息的组件。在这篇文章中将会通过扩展现有的ValidationAttribute特性让ASP.NET MVC应用可以使用我们的消息组件来获取验证消息。[源代
在本文中,我将展示如何使用DfaGraphWriter服务在ASP.NET Core 3.0应用程序中可视化你的终结点路由。上面文章我向您演示了如何生成一个有向图(如我上篇文章中所示),可以使用GraphVizOnline将其可视化。最后,我描述了应用程序生命周期中可以检索图形数据的点。
上篇文章《在.NET Core 3.0中的WPF中使用IOC图文教程》中,我们尝试在WPF中应用.NET Core内置的IOC进行编程,在解析MainWindow的时候我用了GetRequiredService<T>()方法,当时就在想这个GetRequiredService<T>()方法跟GetService<T>()到底有什么区别呢,于是乎,谷歌了一把,就发现了一篇文章来介绍他们区别的,然后尝试翻译了一把,希望对大家有所帮助。文章最后会给出原文链接,以下就是翻译内容:
上篇文章《在.NET Core 3.0中的WPF中使用IOC图文教程》中,我们尝试在WPF中应用.NET Core内置的IOC进行编程,在解析MainWindow的时候我用了GetRequiredService<T>()方法,当时就在想这个GetRequiredService<T>()方法跟GetService<T>()到底有什么区别呢,于是乎,谷歌了一把,就发现了一篇文章来介绍他们区别的,于是乎尝试翻译一把,希望对大家有所帮助。文章最后会给出原文链接,以下就是翻译内容:
首先我们知道http是一种无状态的请求,他的生命周期就是从客户端浏览器发出请求开始,到得到响应结束。那么MVC应用程序从发出请求到获得响应,都做了些什么呢?
Build 2018 主旨演讲的主题是 Azure 云和 AI、物联网、AR等技术,以及开发者相关内容的宣布。在今天的Build大会上,微软宣布目前已有超过7亿台设备运行Windows 10系统。去年
首先我们知道http是一种无状态的请求,他的生命周期就是从客户端浏览器发出请求开始,到得到响应结束。那么MVC应用程序从发出请求到获得响应,都做了些什么呢? 本文我们会详细讨论MVC应用程序一个请求的生命周期,从一个控件到另一个控件是怎样被处理的。我们还会详细介绍一下整个请求的生命周期中,用到的相关组件。因为在平常的开发过程中,我们可能知道怎样去使用MVC框架来处理相关的请求,大部分的时候我们只是在controller和action方法之间做相关的处理,对于真正内在的运行机制可能不是很了解。
很多人可能对ASP.NET Core框架自身记录的诊断日志并不关心,其实这些日志对纠错排错和性能监控提供了很有用的信息。如果需要创建一个APM(Application Performance Management)系统来监控ASP.NET Core应用处理请求的性能及出现的异常,我们完全可以将HostingApplication对象记录的日志作为收集的原始数据。实际上,目前很多APM(如OpenTelemetry.NET 、Elastic APM和SkyWalking APM等)针对都是利用这种方式收集分布式跟踪日志的。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》)
1、EF等ORM解决方案出现的原因 因为软件开发中分析和解决问题的方法已经接近成熟,然后关系型数据库却没有,很多年来,数据依然是保存在表行列这样的模式里,所以,在面相对象和高度标准化的数据库中产生了一个失配(不匹配、阻抗失配,微软的安德斯.海尔斯伯格<C#之父>可能会这样叫它),为了解决这个失配,大多数项目中都会引入"数据处理层"来转换应用程序实体层的数据到数据库的行和列中,随着"数据处理层"的不断进化,最后ORM就诞生了。 2、集成查询语言LINQ LINQ和EF都出自于微软,都能帮助我们解决失配的问题.
本文通过一个维修工与工具库的例子形象的描述一下为什么要用依赖注入、它的工作原理是什么样的, 然后根据这个类比一下ASP.NET Core 中的依赖注入, 从而深刻了解它的使用方法、注意事项以及回收机制等. ASP.NET Core 系列目录 本文主要内容: 1.为什么要用依赖注入(DI) 2.容器的构建和规则 3.ASP.NET Core 2.0中的依赖注入 4.使用方法及需要注意的问题 5.服务的Dispose 6.我想换个容器 1.为什么要用依赖注入(DI) 什么是依赖注入就不说了, 为什么
1、int? 关键字说明 (1)、int? 表示一个int类型,且该int类型可空,如果不加?的话,那么int类型的默认值为0,不能赋null值,代码如下: int aa = null; (2)
中间件(Middleware)是ASP.NET Core中的一个重要特性。所谓中间件就是嵌入到应用管道中用于处理请求和响应的一段代码。ASP.NET Core Middleware可以分为两种类型:
中间件(Middleware)是ASP.NET Core中的一个重要特性。**所谓中间件就是嵌入到应用管道中用于处理请求和响应的一段代码**。ASP.NET Core Middleware可以分为两种类型:
本文通过一个维修工与工具库的例子形象的描述一下为什么要用依赖注入、它的工作原理是什么样的, 然后根据这个类比一下ASP.NET Core 中的依赖注入, 从而深刻了解它的使用方法、注意事项以及回收机制
本文首发于 码友网 -- 《基于ASP.NET Core 3.x的端点路由(Endpoint Routing)实现控制器(Controller)和操作(Action)分离的接口服务》
今天在写CzarCms的UnitOfWork的使用使用到了这个TransactionScope事务,因此对它进行了相关资料的查阅并记录如下,希望对大伙在.NET Core中使用有所帮助。
https://www.cnblogs.com/easywebfactory/p/18289178
《上篇》主要介绍如何通过DataBinder实现批量的数据绑定,以及如何解决常见的数据绑定问题,比如数据的格式化。接下来,我们主要来谈谈DataBinder的设计,看看它是如何做到将作为数据源实体的属性值绑定到界面对应的控件上的。此外,需要特别说明一点:《上篇》中提供了DataBinder最初版本的下载,但已经和本篇文章介绍的已经大不一样了。最新版本的主要解决两个主要问题:通过Expression Tree的方式进行属性操作(属性赋值和取值),添加了“数据捕捉”(Data Capture)的功能,以实现将控
开发.NET Core应用,直接映入眼帘的就是Startup类和Program类,它们是.NET Core应用程序的起点。通过使用Startup,可以配置化处理所有向应用程序所做的请求的管道,同时也可以减少.NET应用程序对单一服务器的依赖性,使我们在更大程度上专注于面向多服务器为中心的开发模式。
近半年以来,一直忙于我的第一本WCF专著《WCF技术剖析》的写作,一直无暇管理自己的Blog。到目前为止《WCF技术剖析(卷1)》的写作暂告一段落,初步预计于下个月由武汉博文视点出版。在《WCF技术剖析》写作期间,对WCF又有了新的感悟,为此以书名开始本人的第三个WCF系列。本系列的目的在于对《WCF技术剖析》的补充,会对书中的一些内容进行展开讲述,同时会囊括很多由于篇幅的原因忍痛割弃的内容。 1、通过一个ASP.NET程序模拟WCF基础架构 本系列的第一篇,我将会对WCF的基本架构作一个大致的讲解。不过,
上一章讲了系统如何将客户端提交的请求数据格式化处理成我们想要的格式并绑定到对应的参数,本章讲一下它的“逆过程”,如何将请求结果按照客户端想要的格式返回去。(ASP.NET Core 系列目录)
本文为官方文档译文 ASP.NET Core是从根本上设计来支持和利用依赖注入。 ASP.NET Core应用程序可以通过将其注入到Startup类中的方法中来利用内置的框架服务,并且应用程序服务也可以配置为注入。 ASP.NET Core提供的默认服务容器提供了一个最小的功能集,而不是替换其他容器。 什么是依赖注入? 依赖注入,英文是Dependency Injection一般简称DI,是实现对象与其协作者或依赖关系之间松散耦合的技术。为了执行其操作,类所需的对象不是直接实例化协作者或使用静态引用,
包含服务注册信息的IServiceCollection集合最终被用来创建作为依赖注入容器的IServiceProvider对象。当需要消费某个服务实例的时候,我们只需要指定服务类型调用IServiceProvider的GetService方法即可,IServiceProvider对象就会根据对应的服务注册提供所需的服务实例。
默认情况下,项目下 的 launchSettings.json 配置文件的优先级最高,appsettings.Development.json 优先级次之,appsettings.json 配置文件优先级最后。 注意的是,在appsettings.json 下可以更具需求建立多个settings.json ,如development.json ,productionsetting.json 等json 配置文件,每个不同json 文件可以进行专门不同的配置信息,不仅可以使针对开发环境进行独立配置,在较为复杂的业务场景下还可以专门将一部分配置抽离出来,比如connectionsetting.json 专门进行各类连接的配置。
CoreData是一个专门用来管理数据的框架,其在性能与书写方便上都有很大的优势,在数据库管理方面,apple强烈推荐开发者使用CoreData框架,在apple的官方文档中称,使用CoreData框架可以减少开发者50%——70%的代码量,这虽然有些夸张,但由此可见,CoreData的确十分强大。
本篇文章来源于几天前一个朋友向我咨询的问题。问题是这样的,他说他采用ASP.NET应用程序的方式对定义的WCF服务进行寄宿(Hosting),并使用配置的方式对服务的BaseAddress进行了设置,但是在创建ServiceHost的时候却抛出InvalidOperationException,并提示相应Address Scheme的BaseAddress找不到。我意识到这可能和WCF中用于判断服务寄宿方式的逻辑有关,于是我让这位朋友将相同的服务寄宿代码和配置迁移到GUI程序或者Console应用中,看看是
ASP.NET Core的请求处理管道由一个服务器和一组中间件构成,但对于面向传输层的服务器来说,它其实没有中间件的概念。当服务器接收到请求之后,会将该请求分发给一个处理器进行处理,对服务器而言,这个处理器就是一个HTTP应用,此应用通过IHttpApplication<TContext>接口来表示。由于服务器是通过IServer接口表示的,所以可以将ASP.NET Core框架的核心视为由IServer和IHttpApplication<TContext>对象组成的管道。[本文节选自《ASP.NET Core 3框架揭秘》第13章, 更多关于ASP.NET Core的文章请点这里]
SynchronizationContext是对“调度程序(scheduler)”的通用抽象。个别框架会有自己的抽象调度程序,比如System.Threading.Tasks。当Tasks通过委托的形式进行排队和执行时,会用到System.Threading.Tasks.TaskScheduler。和SynchronizationContext提供了一个virtual Post方法用于将委托排队调用一样(稍后,我们会通过典型的委托调用机制来调用委托),TaskScheduler也提供了一个abstract QueueTask方法(稍后,我们会通过ExecuteTask方法来调用该Task)。
1. 引言 上两节我们通过简单的demo学习了docker的基本操作。这一节我们来一个进阶学习,完成ASP.NET Core + MySql + Nginx的容器化部署。 本文是基于CentOS 7.4环境进行演示,示例项目可以访问Docker.NetCore.MySql进行下载。 2. Hello MySQL 同样我们还是以循序渐进的方式来展开。首先来基于Docker来试玩一下MySQL。 2.1. 创建MySql实例 下面我们直接在容器中连接到我们刚刚创建的mysql数据库: 2.2. 挂载数据卷
ASP.NET Core的请求处理管道由一个服务器和一组中间件组成,位于 “龙头” 的服务器负责请求的监听、接收、分发和最终的响应,针对请求的处理由后续的中间件来完成。中间件最终体现为一个Func<RequestDelegate, RequestDelegate>委托,但是我们具有不同的定义和注册方式。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》)
领取专属 10元无门槛券
手把手带您无忧上云