ASP.NET MVC

最近在使用ASP.NET Core的时候出现了一个奇怪的问题。在一个Controller上使用了一个ActionFilter之后经常出现EF报错。 InvalidOperationException: A second operation started on this context before a previous operation completed. Any instance members are not guaranteed to be thread safe. Microsoft.EntityFrameworkCore.Internal.ConcurrencyDetector.EnterCriticalSection() 这个异常说Context在完成前一个操作的时候第二个操作依据开始。这个错误还不是每次都会出现，只有在并发强的时候出现，基本可以判断跟多线程有关系。看一下代码： public static class ServiceCollectionExt { public static void AddAgileConfigDb(this IServiceCollection sc) { sc.AddScoped<ISqlContext, AgileConfigDbContext>(); } } [TypeFilter(typeof

mvc上传图片 [HttpPost] public JsonResult Upload() { if (Request.Files.Count > 0 ) { if (Request.Files.Count == 1 ) { HttpPostedFileBase file = Request.Files[ 0 ]; if (file.ContentLength > 0 ) { string title = string .Empty; title = DateTime.Now.ToString( " yyyyMMddHHmmss " ) + " _ " + Path.GetFileName(file.FileName); string path = " ../UploadFile/ " + title; path = System.Web.HttpContext.Current.Server.MapPath(path); file.SaveAs(path); return Json( new { status = true , url = path }); } } else { string [] urllist = new string [Request.Files.Count]; for ( int i = 0 ; i < Request.Files.Count; i++ )

《asp.net-mvc框架揭秘》一书中，有个示例，是使用unity容器来注入自定义的控制器工厂。代码示例可以自己去下载源码，在这里我就不说了。IOC容器的本质是解耦的实例化接口类，而如何做到解耦就是通过第三方容器来实例化，在这里是unity容器，而不是在项目中实例化接口类。实例化的方法无非就是反射，Emit，表达式树，委托等四个方法。Unity容器的IOC使用主要是三个个方法:Register,Resolver,Dispose。前者注册接口和接口类，后者将接口类的实例化转移到第三方容器中实现。而这里的Dispose却是有点文章了。如果单单是控制台的应用项目，就不必多说，如果是在mvc框架中的话，我们的接口类的资源释放应该放在什么地方合适呢？微软unity开发小组给我们做了很好的解释，原文: https://msdn.microsoft.com/en-us/library/dn178463(v=pandp.30).aspx 我们将Unity容器里面资源的释放与控制器的资源释放绑定在一起。如何用代码来表示？我们在基于Unity的控制器工厂中的GetControllerInstance中解析controllerType对象，而不是解析某个接口: (IController)this.UnityContainer.Resolve(controllerType);

ASP.NET Core是.与.Net Core FrameWork一起发布的ASP.NET 新版本，最初被称为ASP.NET vNext,有一系列的命名变化，ASP.NET 5.0,ASP.NET MVC CORE 6.0,最后才被命名为ASP.NET Core。 ASP.NET Core是对现有ASP.NET的彻底重写，与传统的ASP.NET框架相比，它采用了完全不同的开发方法。它是开源，并且独立于平台的。 ASP.NET Core的第一个版本是1.0，是和Visual Studio 2015 Update3一起发布的。 AspNet Core和Visual Studio项目模板经过了一系列的升级，最终的项目模板连同AspNet Core 1.1一起在Visual Studio 2017上发布（目前最新版本是AspNet Core 2.1）。 既然ASP.NET是一个全新实现的框架，那么了解传统的ASP.NET和ASP.NET Core就是十分必要的。 下面的表格展示了他们的区别： ASP.NET ASP.NET CORE 最新版本是ASP.NET 4.6 最新版本是AspNet Core 2.1 它在.NetFramework上运行，或者通常称为Full .NetFramework 它运行于.net core 和Full . NetFramework。

从 Asp.Net MVC 到 Web Form 这看起来有点奇怪，大家都研究如何从 Web Form 到 MVC 的时候，为什么会出现一个相反的声音？从研究的角度来说，对反向过程进行研究有助于理解正向过程。通过对 MVC 转 Web Form 的研究，可以推导出：如果想把一个 Web Form 应用转换为 MVC 应用，可能需要进行怎么样的准备，应该从哪些方面去考虑重构？ 当然研究不是我们最真实的目的，项目需要才是非常有力的理由——在我们用 MVC 框架已经初步完成项目第一阶段的时候准备试运行的时候，客户要求必须使用 Web Form——这不是客户的原因，只是我们前期调研得不够仔细。 产生这样的需求有很多历史原因，这不是今天要讨论的范围。我们要讨论的是如何快速的把 MVC 框架改回 Web Form 框架。要完成这个任务，需要做哪些事情？ 在 Web Form 中 渲染 Razor 模板……如果不行，就得按 Razor 重写 Aspx 所有 Ajax 调用的 Controller 都必须改用 Ashx 来实现 MVC 的路由配置得取消，URL 与原始的目录路径结构强相关 前端变化不大，但是要小心 Web Form 对元素 ID 和控件名称（name）的强制处理 Razor 框架 → Aspx 框架 很不幸，没找到现成的工具在 Web Form 框架中渲染 Razor 模板

Asp.Net MVC及Web API框架配置会碰到的几个问题及解决方案(转) 参考文章： （1）Asp.Net MVC及Web API框架配置会碰到的几个问题及解决方案(转) （2）https://www.cnblogs.com/nikyxxx/p/3356659.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4403110/blog/4777282

译文链接：https://www.infoworld.com/article/3434624/how-to-handle-null-values-in-aspnet-core-mvc.html 传统的 asp.net mvc 对应着 .netcore 中的 asp.net core mvc，可以利用 asp.net core mvc 去构建跨平台，可扩展，高性能的web应用和 api 接口。 程序员都有一些洁癖，很多时候我们都想很完美的包装一些错误信息，如一些返回空response的request请求，或者一些 action 中返回 null value 的情况，通常这些情况下，asp.net core mvc 都会返回 http status 204 （No Content），在本篇中，我准备修改一下这种从 action 返回 null value 的默认行为。 要想运行本篇的例子，你需要安装一下 Visual Studio 2019，如果没有安装，可以到官网安装一下：https://visualstudio.microsoft.com/downloads/ 在 Asp.NET Core 中新建 Controller 在解决方案窗口中的 Controller 文件夹上右键并选择 Add -> Controller 去新建Controller，指定这个 Controller

　 本文是本系列文章第一篇，主要通过建立一个默认ASP.NET MVC项目来引出与ASP.NET MVC相关的功能，由于ASP.NET MVC一个简单的模板就具备了数据库操作、身份验证、输入数据校验等功能，所以本系列文章将这些功能看作“魔法”来一一介绍。 　　本文从以下几个方面来进行讲诉： 　　● 为什么写这一系列文章 　　● 用VS2017创建一个ASP.NET MVC应用 　　● 项目的运行与效果展示 为什么写这一系列文章？ 　　本系列文章基于ASP.NET MVC，在ASP.NET Core已经发布2.0版本，微服务漫天的今天为什么还写ASP.NET？。 　　答：虽然现在已经有ASP.NET Core并且以微服务架构为主流，但是在生产上仍然存有很多用ASP.NET开发应用程序，所以对于维护来说ASP.NET也是很重要的，另外ASP.NET Core毕竟很多东西仍然是基于ASP.NET的思想的，理解ASP.NET再去学习Core会事半功倍，另外使用一项技术开发应用程序，并不是所有的业务都适合微服务架构，况且微服务不仅仅只是开发服务，它对开发和运维都有很大的要求，所以MVC这种单体程序仍旧有存在的意义(ASP.NET Core中也有MVC)。 　　网络中已经有很多很好的ASP.NET MVC的教程，为什么还要写？ 　　答：首先网络上的东西个人觉得比较零碎

C# 工作流管理平台 前言 经过三个月研发， Smartflow-Sharp 工作流管理平台已经越来越成熟。在研发期间，我将我所有业余时间和精力完全投入到 Smartflow-Sharp 工作流研发中，研发过程实属不易，因为耗时耗脑力，对工作流管理平台的代码不断的优化，以期望其更加小巧精致，有更好的维护性。 研发 Smartflow-Sharp 工作流初衷是基于我现在的项目的需要，所以趁此机会研发 Smartflow-Sharp 工作流管理平台，期望打造成符合中国特色工作流管理平台，造福更多开发人员和企业。后续我会持续对 Smartflow-Sharp 工作流管理平台进行完善。我不会藏私，我完全公开 Smartflow-Sharp 工作流研发成果，完全免费，允许商用。在使用的过程，如有疑问或需技术支持都可以与我联系。 我为什么不选择使用现成工作流，而是重头研发，主要是基于对目前市面上工作流管理平台都不太满意，收费的太贵、免费又不是很好用。所以，我也来凑热闹研发一款属于我的工作流产品，完全开源、免费，希望能发挥他最大的作用，体现其价值，而不是把他放在家里硬盘里静静躺着，这样将失去他的价值。当然，我刚开始研发 Smartflow-Sharp 工作流管理平台也是有寄于变现的想法，毫不掩饰我对钱的追求，不过现在我完全不会有这种想法，只期望能发挥更大的作用。

作为一款专注于 .NET 平台的报表控件，ActiveReports 不仅满足了WinForm、ASP.NET、.NET Core、WPF 等平台下的中国式复杂报表设计，还满足了HTML5、移动跨平台的报表开发需求，作为专业的报表工具为全球超过 300,000 名开发者提供全面的报表解决方案。 伴随着ActiveReports V14 的发布，其报表设计器UI得以全面增强，报表预览方式得以全面优化，报表设计能力得以大幅提升。 点击下载ActiveReports最新版本>> Office作为日常办公场景中高频使用的软件产品，培养了大量用户的使用习惯和思维，企业在向数字化和智能化转型的过程中，同样也希望延用熟悉的操作习惯和风格。因此，一款系统能否被大量推广使用，取决于其是否符合Office的办公标准，如表格数据能否与Excel兼容、文档报表能否与 Word 适配等。 在应用系统中，不论是HIS、MES、ERP，还是HRM、SCM系统都需要以报表展示数据，除了Excel外，Word作为另一种常见的报表模板类型，也有十分广泛的应用，如周报、检测报告、述职报告、质检报告和评测报告等。 因此，Word报表设计模块对于系统功能而言必不可少，系统往往需要根据当前实时的数据，动态生成一份完整的行业可行性分析报告，并满足实时修改、编辑、展示、打印、导出报告模板等功能。 常见的 Word报告类型