很多应用程序运行时会出现“若要运行此应用程序,您必须首先安装.NET Framework的以下版本之一”的解决方法

问题重现:

解决方法:

在360软件管家里面下载一个,或者其他地方

  • 4
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
这几天看了很多关于脱离框架运行C#程序的文章,千篇一律,都是讲飞信方案的,此方案涉及一些法律问题,只能自己研究一下,后来用google美国网站搜了一把,看了些文章,无意中发现mono,又用mono关键字到google中国搜了一把,已经有人实现控制台程序脱离.net框架了。 其实就是换mono的公共语言运行来使用。这样做的好处是体积小,发布免安装。首先,您需要下载mono的最新版。 http://ftp.novell.com/pub/mono/archive/1.9.1/windows-installer/2/mono- 1.9.1-gtksharp-2.10.4-win32-2.exe,安装后,就可以继续进行了。 1、用Visual Studio创建一个Windows应用程序,假设叫做WinApp,并添加一个按钮。 2、编译此项目,得到一个WinApp.exe文件。 3、自己建立一个文件夹WinApp,其中再建立bin和lib这两个文件夹 4、将mono安装文件夹中的bin和lib子文件夹中需要的文件拷贝至刚才建立的那两个文件夹。mono的默认安装位置是:C:\Program Files\Mono-1.9.1 5、将需要运行的exe文件放入WinApp文件夹。 6、调用,可以使用bat批处理来调用,bin\mono.exe WinApp.exe。(其实写个VC++的小程序调用最好,可以我很菜) 好了,发个代码上来,有兴趣的朋友可以研究一下,7zip打包后仅3.26MB,却实现了免安装微软庞大的框架。此测试项目我在纯净的虚拟机和本机均测试过,但有个bug,mono对中文路径支持不好,如若有中文路径,则无法运行。我后来又试了用C:\Program Files\Mono-1.9.1\bin\mono.exe来执行,则没有中文路径问题。我觉得缺少了哪个文件,一个一个试着拷贝到WinApp文件夹中,再用批处理来执行,还是错误。后来干脆将整个安装目录的文件全搬到WinApp目录中,执行批处理还是失败,可是用C:\Program Files\Mono-1.9.1\bin\mono.exe来执行就是能成功,百思不得其解啊!究竟少了什么东西呢? 注意:例子中的dll文件已经为最精简,一个都不能缺少,我是用最笨的办法,删除到回收站,运行,重复此过程来确定需要保留哪些dll的。如果你机子上装有.net框架,你当然可以直接运行程序,或者用bat来运行也可以,效果是不一样的。
第4章 ASP.NET的网页代码模型及生命周期 从本章开始,就进入了ASP.NET应用程序开发的世界。在了解了C#的结构,以及面向对象的概念后,就可以从面向对象的思想开发ASP.NET应用程序。在ASP.NET中,能够使用面向对象的思想和软件开发中的一些思想,例如封装、派生、继承以及高级的设计模式等。本章首先介绍ASP.NET中最重要的概念---网页代码模型。 4.1 ASP.NET的网页代码模型 在ASP.NET应用程序开发中,微软提供了大量的控件,这些控件能够方便用户的开发以及维护。这些控件具有很强的扩展能力,在开发过程中无需自己手动编写。不仅如此,用户还能够创建自定义控件进行应用程序开发以扩展现有的服务器控件的功能。 4.1.1 创建ASP.NET网站 在ASP.NET中,可以创建ASP.NET网站和ASP.NET应用程序,ASP.NET网站的网页元素包含可视元素和页面逻辑元素,并不包含designer.cs文件。而ASP.NET应用程序包含designer.cs文件。创建ASP.NET网站,首先需要创建网站,单击【文件】按钮,在下拉菜单中选择【新建网站】选项,单击后弹出对话框用于ASP.NET网站的创建,如图4-1所示。 图4-1 新建ASP.NET网站 在【位置】选项中,旁边的【下拉菜单】可以按照开发的需求来写,一般选择文件系统,地址为本机的本地地址。语言为.NET网站中使用的语言,如果选择Visual C#,则默认的开发语言为C#,否则为Visual Basic。创建了ASP.NET网站后,系统自动创建一个代码隐藏页模型页面Default.aspx。ASP.NET网页一般由三部分组成,这三个部分如下所示。 q 可视元素:包括HTML,标记,服务器空间。 q 页面逻辑元素:包括事件处理程序和代码。 q designer.cs页文件:用来为页面的控件做初始化工作,一般只有ASP.NET应用程序(Web Application)才有。 ASP.NET页面中包含两种代码模型,一种是单文件页模型,另一种是代码隐藏页模型。这两个模型的功能完全一样,都支持控件的拖拽,以及智能的代码生成。 4.1.2 单文件页模型 单文件页模型中的所有代码,包括控件代码、事物处理代码以及HTML代码全都包含在.aspx文件中。编程代码在script标签,并使用runat=“server”属性标记。创建一个单文件页模型,在【文件】按钮中选择【新建文件】选项,在弹出对话框中选择【Web窗体】或在右击当前项目,在下拉菜单中选择【添加新建项】选项即可创建一个.aspx页面,如图4-2所示。 图4-2 创建单文件页模型 在创建,去掉【将代码放在单独的文件中】复选框的选择即可创建单文件页模型的ASP.NET文件。创建后文件自动创建相应的HTML代码以便页面的初始化,示例代码如下所示。 <%@ Page Language=“C#” %> <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”> <script runat=“server”> </script> <html xmlns=“http://www.w3.org/1999/xhtml”> <head runat=“server”> <title>无标题页</title> </head> <body> <form id=“form1” runat=“server”> <div> </div> </form> </body> </html> 编译并运行,即可看到一个空白的页面被运行了。ASP.NET单文件页模型在创建并生成,开发人员编写的类将编译成程序集,并将该程序集加载到应用程序域,并对该页的类进行实例化后输出到浏览器。可以说,.aspx页面的代码也即将生成一个类,并包含内部逻辑。在浏览器浏览该页面,.aspx页面的类实例化并输出到浏览器,反馈给浏览者。ASP.NET单文件页模型运行示例图如图4-3所示。 图4-3 单文件页模型 4.1.3 代码隐藏页模型 代码隐藏页模型与单文件页模型不同的是,代码隐藏页模型将事物处理代码都存放在cs文件中,当ASP.NET网页运行候,ASP.NET类生成先处理cs文件中的代码,再处理.aspx页面中的代码。这种过程被成为代码分离。 代码分离有一种好处,就是在.aspx页面中,开发人员可以将页面直接作为样式来设计,即美工人员也可以设计.aspx页面,而.cs文件由程序员来完成事务处理。同,将ASP.NET中的页面样式代码和逻辑处理代码分离能够让维护变得简单,同代码看上去也非常的优雅。在.aspx页面中,代码隐藏页模型的.aspx页面代码基本上和单文件页模型的代码相同,不同的是在script标记中的单文件页模型的代码默认被放在了同名的.cs文件中,.aspx文件示例代码如下所示。 <%@ Page Language=“C#” AutoEventWireup=“true” CodeFile=“Default.aspx.cs” Inherits=“_Default” %> <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”> <html xmlns=“http://www.w3.org/1999/xhtml”> <head runat=“server”> <title>无标题页</title> </head> <body> <form id=“form1” runat=“server”> <div> </div> </form> </body> </html> 从上述代码中可以看出,在头部声明的候,单文件页模型只包含Language=“C#”,而代码隐藏页模型包含了CodeFile=“Default.aspx.cs”,说明被分离出去处理事物的代码被定义在Default.aspx.cs中,示例代码如下所示。 using System.Linq; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.HtmlControls; //使用HtmlControls using System.Web.UI.WebControls; //使用WebControls using System.Web.UI.WebControls.WebParts; //使用WebParts public partial class _Default : System.Web.UI.Page //继承自System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } } 上述代码为Default.apx.cs页面代码。从上述代码可以看出,其格式与类库、编写类的格式相同,这也说明了.aspx页面允许使用面向对象的特性,如多态、继承等。但是ASP.NET代码隐藏页模型的运行过程比单文件页模型要复杂,运行示例图如图4-4所示。 图4-4 代码隐藏页模型 上述描述了代码隐藏类模型的页面生成模型。当页面被呈现之前,ASP.NET应用程序解释并编译相应的cs文件中的代码,与此同,ASP.NET应用程序将.aspx页面进行编译并生成.aspx页面对应的类。生成.aspx页面对应的类后将该类与cs文件中的类进行协调生成新的类,该类通过IIS在用户浏览页面呈现在用户的浏览器中。 4.1.4 创建ASP.NET Web Application ASP.NET网站有一种好处,就是在编译后,编译器将整个网站编译成一个DLL(动态链接库),在更新的候,只需要更新编译后的DLL(动态链接库)文件即可。但是ASP.NET网站却有一个缺点,编译速度慢,并且类的检查不彻底。 相比之下,ASP.NET Web Application不仅加快了速度,只生成一个程序集,而且可以拆分成多个项目进行管理。创建Application,首先需要新建项目用于开发Web Application,单击菜单栏上的【文件】按钮,在下拉菜单中选择【新建项目】选项,在弹出窗口中选择【ASP.NET应用程序】选项,如图4-5所示。 图4-5 创建ASP.NET应用程序 在创建了ASP.NET应用程序后,系统同样默认创建一个Default.aspx页面,不同的是,多出了一个Default.aspx.designer.cs,用来初始化页面控件,一般不需要修改。 4.1.5 ASP.NET网站和ASP.NET应用程序的区别 在ASP.NET中,可以创建ASP.NET网站和ASP.NET应用程序,但是ASP.NET网站和ASP.NET应用程序开发过程和编译过程是有区别的。ASP.NET应用程序主要有以下特点: q 可以将ASP.NET应用程序拆分成多个项目以方便开发,管理和维护。 q 可以从项目中和源代码管理中排除一个文件或项目。 q 支持VSTS的Team Build方便每日构建。 q 可以对编译前后的名称,程序集等进行自定义。 q 对App_GlobalResources 的Resource强类支持。 ASP.NET WebSite编程模型具有以下特点: q 动态编译该页面,而不用编译整个站点。 q 当一部分页面出现错误不影响到其他的页面或功能。 q 不需要项目文件,可以把一个目录当作一个Web应用来处理。 总体来说,ASP.NET网站适用于较小的网站开发,因为其动态编译的特点,无需整站编译。而ASP.NET应用程序适应大型的网站开发、维护等。 4.2 代码隐藏页模型的解释过程 在ASP.NET的代码隐藏页模型中,一个完整的.aspx页面包含两个页面,分别是以.aspx和.cs文件为后缀的文件,这两个文件在形成了整个Web窗体。在编译的过程中都被编译成由项目生成的动态链接库(.DLL),同,.aspx页面同样也编译。但是与.cs页面编译过程不同的是,当浏览者第一次浏览到.aspx页面,ASP.NET自动生成该页的.NET类文件,并将其编译成另一个.DLL文件。 当浏览者再一次浏览该页面的候,生成的.DLL就在服务器上运行,并响应用户在该页面上的请求或响应,ASP.NET应用程序的解释过程图如4-6所示。 图4-6 代码隐藏页模型页面的执行过程 在客户端浏览器访问该页面,浏览器给IIS发送请求消息,IIS则开始执行ASP.NET编译过程,如果不存在编译过后的DLL文件,则加载编译的类并创建对象。当创建对象完成,生成创建对象后的代码并生成一个ASPX页面代码,该页面代码反馈给IIS,IIS再反馈成HTML页面的形式给客户端。 4.3 代码隐藏页模型的事件驱动处理 在传统的ASP开发中,ASP的事件都是按照网页的顺序来处理的,一般情况下,ASP页面的事件都是从上到下处理事件,可以说ASP的开发是一个线性的处理模型。在用户的浏览操作中,每一次用户的操作都导致页面重新被发送到服务器。因此,重复的操作必然导致客户端和服务器的往返过程,服务器必须重新创建页面,当创建页面后,服务器再按照原来的从上到下的顺序进行事件处理。 在ASP.NET中,通过使用模拟事件驱动模型的行为代替了ASP的线性处理模型。ASP.NET页框架模型隐式的为用户建立了事件和事件处理程序的关联。ASP.NET让用户可以为从浏览器传递的事件在服务器代码中设置相应的处理程序。假设某个用户正在浏览网站并与页面之间产生了某种交互,用户的操作就引发事件,事件通过HTTP被传输到服务器。在服务器中,ASP.NET框架解释信息,并触发事件与之对应的处理程序。该程序可以是.aspx页面中的处理程序,也可以是开发者自定义的类库,或者COM组件等。事件驱动处理如图4-7所示。 图4-7 页面框架的事件驱动处理模型 上图则说明了当一个浏览者通过浏览器触发ASPX页面,浏览器、服务器和服务器返回页的过程。 4.4 ASP.NET客户端状态 Web开发不像软件开发,Web应用实际上是没有状态的,这就说明Web应用程序不自动指示序列中的请求是否来自相同的浏览器或客户端,也无法判断浏览器是否一直在浏览一个页面或者一个站点,也无法判断用户执行了哪个操作并统计用户的喜好。 4.4.1 视图状态 从上面的章节中可以知道,当服务器每次的往返过程,都将销毁页面并重新创建新的页面。如果一个页面中的信息超出了页面的生命周期,那么这个页面中的相关信息就不存在了。如果注销了页面的信息,那么用户的一些信息可能就不存在了。 在ASP.NET中,网页包含视图状态来保存用户的信息,视图状态在页面发回到自身,跨页过程存储和用户自己的页面的特定值,视图状态的优点如下所示。 q 不需要任何服务器资源。 q 在默认情况下,对控件启用状态的数据进行维护,不被破坏。 q 视图状态的值经过哈希运算和压缩保护,安全性更高。 视图状态同样有一些缺点,缺点如下所示。 q 视图状态影响性能,如果页面存储较大较多的值,则性能有较大的影响。 q 在手机,移动终端上,可能无法保存视图状态中使用的值。 q 视图状态虽然安全性较高,但是还是有风险,如果直接查看页面代码,可以看到相应代码。 4.4.2 控件状态 ASP.NET中还提供了控件状态属性作为在服务器往返过程中存储自定义控件中的数据的方法。在页面控件中,如果有多个自定义控件使用多个不同的控件来显示不同的数据结构,为了让这些页面控件能够在在页面上协调的工作,则需要使用控件状态来保护控件,同,控件状态是不能被关闭的。同样,控件状态也有它的优点,优点如下所示。 q 与视图状态相同的是,不需要任何服务器资源。 q 控件状态是不能被关闭的,提供了控件管理的更加可靠的方法。 q 控件状态具有通用性。 4.4.3 隐藏域 在ASP中,通常使用隐藏域保存页面的信息。在ASP.NET中,同样具有隐藏域来保存页面的信息,作为维护页面状态的一种形式,但是隐藏域的安全性并不高,最好不要在隐藏域保存过多的信息。隐藏域具有以下优点。 q 不需要任何服务器资源。 q 支持广泛,任何客户端都支持隐藏域。 q 实现简单,隐藏域属于HTML控件,无需像服务器控件那样有需要编程知识。 而隐藏域具有一些不足,如下所示。 q 具有较高的安全隐患。 q 存储结构简单。 q 同样,如果存储了较多的较大的值,则导致性能问题。 q 如果隐藏域过多,则在某些客户端中被禁止。 q 隐藏域将数据存储在服务器上,而不存储在客户端。 注意:如果开发中,页面的隐藏域过多,这些隐藏域被存储在服务器。当客户端浏览页面的候,有一些防火墙扫描页面,以保证操作系统的安全,如果页面的隐藏域过多,那么这些防火墙可能禁止页面的某些功能。 4.4.4 Cookie Cookie在客户端用户保存网站的少量的用户信息,服务器可以通过编程的方法获取用户信息,Cookie信息和页面请求通常一起发送到服务器,服务器对客户端传递过来的Cookie信息做处理。通常Cookie保存用户的登录状态、用户名等基本信息等等,在后面的章节详细介绍使用ASP.NET操作Cookies。 4.4.5 客户端状态维护 虽然使用某些客户端状态并不使用服务器资源,但是这些状态都具有潜在的安全隐患,如Cookie。非法用户可以使用Cookie欺骗来攻击网站进行用户信息的获取,不过使用客户端状态能够使用客户端的资源从而提高服务器性能。使用客户端状态,虽然有安全隐患,但是具有良好的编程能力,以及基本的安全知识,能够较好的解决安全问题,同也能够提高服务器性能。下面小结了一些客户端状态的优缺点。 q 视图状态:推荐当存储少量挥发到自身的页面的信息使用。 q 控件状态:不需要任何服务器资源,控件状态是不能被关闭的,提供了控件管理的更加可靠和更通用的方法。 q 隐藏域:实现简单,但是在应用程序造成一些安全隐患。 q Cookie:实现简单,同样也能够简单的获取用户的信息,但是Cookie有大小的限制,不适宜存储大量的代码。 4.5 ASP.NET页面生命周期 ASP.NET页面运行,也同类的对象一样,有自己的生命周期。ASP.NET页面运行,ASP.NET页面将经历一个生命周期,在生命周期内,该页面将执行一系列的步骤,包括控件的初始化,控件的实例化,还原状态和维护状态等,以及通过IIS反馈给用户呈现成HTML。 ASP.NET页面生命周期是ASP.NET中非常重要的概念,了解ASP.NET页面的生命周期,就能够在合适的生命周期内编写代码,执行事务。同样,熟练掌握ASP.NET页面的生命周期,可以开发高效的自定义控件。ASP.NET生命周期通常情况下需要经历几个阶段,这几个阶段如下所示。 q 页请求:页请求发生在页生命周期开始之前。当用户请求一个页面,ASP.NET将确定是否需要分析或者编译该页面,或者是否可以在不运行页的情况下直接请求缓存响应客户端。 q 开始:发生了请求后,页面就进入了开始阶段。在该阶段,页面将确定请求是发回请求还是新的客户端请求,并设置IsPostBack属性。 q 初始化:在页面开始后,进入了初始化阶段。初始化期间,页面可以使用服务器控件,并为每个服务器控件进行初始化。 q 加载:页面加载控件。 q 验证:调用所有的验证程序控件的Vailidate方法,来设置各个验证程序控件和页的属性。 q 回发事件:如果是回发请求,则调用所有事件处理的程序。 q 呈现:在呈现期间,视图状态被保存并呈现到页。 q 卸载:完全呈现页面后,将页面发送到客户端并准备丢弃,将调用卸载。 4.6 ASP.NET生命周期中的事件 在页面周期的每个阶段,页面将引发可运行用户代码进行处理事件。对于控件产生的事件,通过声明的方式执行代码,并将事件处理程序绑定到事件。不仅如此,事件还支持自动事件连接,最常用的就是Page_Load事件了,除了Page_Load事件以外,还有Page_Init等其他事件,本节将介绍此类事件。 4.6.1 页面加载事件(Page_PreInit) 每当页面被发送到服务器,页面就重新被加载,启动Page_PreInit事件,执行Page_PreInit事件代码块。当需要对页面中的控件进行初始化,则需要使用此类事件,示例代码如下所示。 protected void Page_PreInit(object sender, EventArgs e) //Page_PreInit事件 { Label1.Text = “OK”; //标签赋值 } 在上述代码中,当触发了Page_PreInit事件,就执行该事件的代码,上述代码将Lable1的初始文本值设置为“OK”。Page_PreInit事件能够让用户在页面处理中,能够让服务器加载只执行一次而当网页被返回给客户端不被执行。在Page_PreInit中可以使用IsPostBack来实现,当网页第一次加载IsPostBack属性为false,当页面再次被加载,IsPostBack属性将被设置为true。IsPostBack属性的使用能够影响到应用程序的性能。 4.6.2 页面加载事件(Page_Init) Page_Init事件与Page_PreInit事件基本相同,区别在于Page_Init并不能保证完全加载各个控件。虽然在Page_Init事件中,依旧可以访问页面中的各个空间,但是当页面回送,Page_Init依然执行所有的代码并且不能通过IsPostBack来执行某些代码,示例代码如下所示。 protected void Page_Init(object sender, EventArgs e) //Page_Init事件 { if (!IsPostBack) //判断是否第一次加载 { Label1.Text = “OK”; //将成功信息赋值给标签 } else { Label1.Text = “IsPostBack”; //将回传的值赋值给标签 } } 4.6.3 页面载入事件(Page_Load) 大多数初学者认为Page_Load事件是当页面第一次访问触发的事件,其实不然,在ASP.NET页生命周期内,Page_Load远远不是第一次触发的事件,通常情况下,ASP.NET事件顺序如下所示。 q 1. Page_Init()。 q 2. Load ViewState。 q 3. Load Postback data。 q 4. Page_Load()。 q 5. Handle control events。 q 6. Page_PreRender()。 q 7. Page_Render()。 q 8. Unload event。 q 9. Dispose method called。 Page_Load事件是在网页加载的候一定被执行的事件。在Page_Load事件中,一般都需要使用IsPostBack来判断用户是否进行了操作,因为IsPostBack指示该页是否正为响应客户端回发而加载,或者它是否正被首次加载和访问,示例代码如下所示。 protected void Page_Load(object sender, EventArgs e) //Page_Load事件 { if (!IsPostBack) { Label1.Text = “OK”; //第一次执行的代码块 } else { Label1.Text = “IsPostBack”; //如果用户提交表单等 } } 上述代码使用了Page_Load事件,在页面被创建,系统自动在代码隐藏页模型的页面中增加此方法。当用户执行了操作,页面响应了客户端回发,则IsPostBack为true,于是执行else中的操作。 4.6.4 页面卸载事件(Page_Unload) 在页面被执行完毕后,可以通过Page_Unload事件用来执行页面卸载的清除工作,当页面被卸载,执行此事件。以下情况触发Page_Unload事件。 q 页面被关闭。 q 数据库连接被关闭。 q 对象被关闭。 q 完成日志记录或者其他的程序请求。 4.6.5 页面指令 页面指令用来通知编译器在编译页面做出的特殊处理。当编译器处理ASP.NET应用程序,可以通过这些特殊指令要求编译器做特殊处理,例如缓存、使用命名空间等。当需要执行页面指令,通常的做法是将页面指令包括在文件的头部,示例代码如下所示。 <%@ Page Language=“C#” AutoEventWireup=“true” CodeBehind=“Default.aspx.cs” Inherits=“MyWeb._Default” %> <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”> 上述代码中,就使用了@Page页面指令来定义ASP.NET页面分析器和编译器使用的特定页的属性。当代码隐藏页模型的页面被创建,系统自动增加@Page页面指令。 ASP.NET页面支持多个页面指令,常用的页面指令如下所示。 q @ Page:定义ASP.NET页分析器和编译器使用的页特定(.aspx文件)属性,可以编写为<%@ Page attribute=“value” [attribute=“value”…]%>。 q @ Control:定义ASP.NET页分析器和编译器使用的用户控件(.ascx文件)特定的属性。该指令只能为用户控件配置。可以编写为<%@ Control attribute=“value” [attribute=“value”…]%>。 q @ Import:将命名空间显示导入到页中,使所导入的命名空间的所有类和接口可用户该页。导入的命名空间可以是.NET Framework类库或用户定义的命名空间的一部分。可以编写为<%@ Import namespace=“value” %>。 q @ Implements:提示当前页或用户控件实现制定的.NET Framework接口。可以编写为<%@ Implements interface=“ValidInterfaceName” %>。 q @ Reference:以声明的方式指示,应该根据在其中声明此指令的页对另一个用户控件或页源文件进行动态编译和链接。可以编写为<%@ Reference page | control=“pathtofile” %>。 q @ Output Cache:以声明的方式空间ASP.NET页或页中包含的用户控件的输出缓存策略。可以编写为<%@ Output Cache Duration=“#ofseconds” Location=“Any | Client | Downstream | Server | None” Shared=“True |False” VaryByControl=“controlname” VaryByCustom=“browser | customstring” VaryByHeader=“headers” VaryByParam=“parametername” %> q @ Assembly:在编译过程中将程序集链接到当前页,以使程序集的所有类和接口都可用在该页上。可以编写为<%@ Assembly Name=“assemblyname” %>或<%@ Assembly Src=“pathname” %>的方式。 q @ Register:将别名与命名空间以及类名关联起来,以便在自定义服务器控件语法中使用简明的表示法。可以编写为<%@ Register tagprefix=“ tagprefix” Namespace=“namepace” Assembly=“assembly” %>或<%@ Register tagprefix=“ tagprefix” Tagname=“tagname” Src=“pathname” %>的方式。 4.7 ASP.NET网站文件类型 在ASP.NET中包含诸多的文件类型,这些类型的文件由ASP.NET支持和管理,而除了这些文件以外,其他的文件都由IIS托管。使用VS2008能够创建大部分可以使用ASP.NET托管运行程序。同,使用应用程序映射可以将文件类型映射到应用程序。当需要伪静态,很可能需要将.html后缀托管到IIS中的应用扩展,因为默认情况下ASP.NET处理HTML的操作。 技巧:现在的网站构架中,生成静态是一种降低网站压力的一种很好的解决方案。在某些情况下,服务器可能需要伪静态支持,就是将.aspx页面后缀显式成.html后缀,让搜索引擎能够更好的搜录。 1.ASP.NET管理的文件类型 ASP.NET管理的文件类型能够在ASP.NET应用程序中被ASP.NET应用程序的不同模块进行访问和调用,这些文件可能是用户能够直接访问的,也有可能是用户无法直接访问的。ASP.NET管理的文件类型如表4-1所示。 表4-1 ASP.NET管理的文件类型 文件类型 保存位置 描述 .asax 根目录。 Global.asax 文件。包含 HttpApplication 对象的派生代码,用于重新展示 Application 对象。 .ascx 根目录或子目录。 可重用的自定义 Web 控件。 .ashx 根目录或子目录。 处理器文件。包含实现 IHttpHandler 接口的代码,用于处理输入请求。 .asmx 根目录或子目录。 XML Web Services 文件。包含由 SOAP 提供给其他 Web 应用的类对象和功能。 .aspx 根目录或子目录。 ASP.NET Web 窗体。包含 Web 控件和其他业务逻辑。 .axd 根目录。 跟踪视图文件。通常是 Trace.axd。 .browser App_Browsers 目录。 浏览器定义文件。用于识别客户端浏览器的可用特征。 .cd 根目录或子目录。 类图文件。 .compile Bin 目录。 定位于适当汇编集中的预编译文件。可执行文件(.aspx,.ascx,.master,theme)预编译后放在 Bin 目录。 .config 根目录或子目录。 Web.config 配置文件。包含用于配置 ASP.NET 若干特征的 XML 元素集。 .cs,.jsl,vb App_Code 目录。有些是 ASP.NET 的代码分离文件,位于与 Web 页面相同的目录。 运行被编译的类对象源代码。类对象可以是 HTTP 模块,HTTP 处理器,或 ASP.NET 页面的代码分离文件。 .csproj,vbproj,vjsproj Visual Studio 工程目录。 Visual Studio 客户工程文件。 .disco,.vsdisco App_WebReferences 目录。 XML Web Services Discovery 文件。用于定位可用 Web Services。 .dsdgm,dsprototype 根目录或子目录。 分布式服务图表(DSD)文件。可添加到 Visual Studio 方案中,为反向引擎提供消耗 Web Services 的交互性图表。 .dll Bin 目录。 已编译类库文件。作为替代,可将类对象源代码保存到 App_Code 目录。 .licx,.webinfo 根目录或子目录。 许可协议文件。许可协议有助于保护控件开发者的知识产权,并对控件用户的使用权进行验证。 .master 根目录或子目录。 模板文件定义 Web 页面的统一布局,并在其他页面中得到引用。 .mdb,.ldb App_Data 目录。 Access 数据库文件。 .mdf App_Data 目录。 SQLServer 数据库文件。 .msgx,.svc 根目录或子目录。 Indigo Messaging Framework(MFx)服务文件。 .rem 根目录或子目录。 远程处理器文件。 .resources App_GlobalResources 或 App_LocalResources 目录。 资源文件。包含图像,本地化文本,或其他数据的资源引用串。 .resx App_GlobalResources 或 App_LocalResources 目录。 资源文件。包含图像,本地化文本,或其他数据的资源引用串。 .sdm,.sdmDocument 根目录或子目录。 系统定义模型(SDM)文件。 .sitemap 根目录。 网站地图文件。包含网站的结构。ASP.NET 通过默认的网站地图提供者,简化导航控件对网站地图文件的使用。 .skin App_Themes 目录。 皮肤定义文件。用于确定显示格式。 .sln Visual Web Developer 工程目录。 Visual Web Developer 工程的项目文件。 .soap 根目录或子目录。 SOAP 扩展文件。 注意:ASP.NET 管理的文件类型映射到 IIS 的 Aspnet_isapi.dll。 2.IIS 管理的文件类型 在ASP.NET应用程序中,有些动态的文件如asp文件就不被ASP.NET应用程序框架管理,这些文件由IIS进行管理,由IIS管理的文件类型如表4-2所示。 表4-2 IIS管理的文件类型 文件类型 保存位置 描述 .asa 根目录。 Global.asa 文件。包含 ASP 话对象或应用程序对象生命周期中的各种事件处理。 .asp 根目录或子目录. ASP Web 页面。包含 @ 指令和使用 ASP 内建对象的脚本代码。 .cdx App_Data 目录. Visual FoxPro 的混合索引文件。 .cer 根目录或子目录。 证明文件。用于对网站的授权。 .idc 根目录或子目录。 Internet Database Connector(IDC)文件。被映射到 httpodbc.dll。 注意:由于无法为数据库连接提供足够的安全性,IDC 将不再被继续使用。IIS 6.0 是最后一个支持 IDC 的版本。 .shtm,.shtml,.stm 根目录或子目录。 包含文件。被映射到 ssinc.dll。 注意:IIS管理的文件类型被映射到IIS的asp.dll 3.静态文件类型 IIS仅提供已注册MIME类型的静态文件服务,注册信息保存在Mime Map IIS元数据库中。如果某种文件类型已经映射到指定应用程序,在不需要作为静态文件的情况之下,无需再在MIME类型列表中进行包含。默认的静态文件类型如表4-3所示。 表4-3 静态文件类型 文件类型 保存位置 描述 .css 根目录或子目录,以及 App_Themes 目录。 样式表文件。用于确定 HTML 元素的显示格式。 .htm,.html 根目录或子目录。 静态网页文件。由 HTML 代码编写。 注意:虽然ASP.NET的代码页面也能够手动添加到MIME类型列表中,但是这样操作浏览者就能够看到页面源代码,从而暴露ASP.NET页面源代码,相对于服务器而言是非常不安全的。 4.8 小结 本章介绍了ASP.NET页面生命周期,以及ASP.NET页面的几种模型。ASP.NET页面生命周期是ASP.NET中非常重要的概念,熟练掌握ASP.NET生命周期能对ASP.NET开发,自定义控件开发起到促进作用。本章还介绍了: q 代码隐藏页模型的解释过程。 q 代码隐藏页模型的事件驱动处理。 q ASP.NET网页的客户端状态。 q ASP.NET页面生命周期。 q ASP.NET生命周期中的事件。 q ASP.NET 网站文件类型。 上面的章节都分开的讲解了ASP.NET运行中的一些基本机制,在了解了这些基本运行机制后,就能够在.NET框架下做ASP.NET开发了。虽然这些都是基本概念,但是在今后的开发中,起到非常重要的作用。
你真的了解Ioc与AOP吗? 收藏 你真的了解Ioc与AOP吗?我现在还不是很了解,而且越学习越发现自己了解的很少,Ioc与AOP中蕴涵了大量的能量等待我们去开发。在这个系列 中,我仅仅利用Sping.net这个框架向大家展示一下Ioc与AOP的强大功能(呵呵,其实写这段话的目的是因为“文章题目”牛皮吹得有点大了,给自 己个台阶下罢了)。 在这个系列中一共包含6个案例,从简单到复杂,也是对问题分解、思考和解决的一个过程,它们分别是: (1)类之间的依赖; 降低 (2)接口依赖; (3)基 于配置文件和Reflection的工厂模式; (4)使用Spring.net实现Ioc; (5)Romoting; (6)利用Ioc在不动一行代码的情 况下实现Remoting。为了更好的理解文中的内容,最好顺序阅读。 作为一个应用系统,代码复用至关重要。如果在你的设计中,类与类存在很强的相互关联,那么你发现在重用这些组件就存在很严重的问题。在 Step1到Step3-Reflection的例子中,我们试图 利用“针对接口编程”以及自己设计的Ioc对系统进行解耦。在Step3到Step5的例子中,我们将利用Spring.net提供的Ioc框架,轻松完 成解耦以及系统改造等工作。 一、类之间的依赖 我们的第一个例子主要用于说明程序的基本构造,并且作为一个反面典型,引出为什么要解耦,以及如何下手。在这个例子中,我们将创建三个程序集,分别是MainApp.exe、HelloGenerator.dll以及SayHello.dll。它们之间的关系如下图所示: HelloGenerator类根据提供的姓名产生一个问候字符串,代码如下: using System; namespace IocInCSharp { public class EnHelloGenerator { public string GetHelloString(string name) { return String.Format("Hello, {0}", name); } } } SayHello类持有一个对EnHelloGenerator的引用,并负责将生成出来的问候字符串打印出来。 using System; namespace IocInCSharp { public class SayHello { private EnHelloGenerator _helloGen; public EnHelloGenerator HelloGenerator { get { return _helloGen; } set { _helloGen = value; } } public void SayHelloTo(string name) { if(_helloGen != null) Console.WriteLine(_helloGen.GetHelloString(name)); else Console.WriteLine("Client.hello is not initialized"); } } } MainApp.exe负责完成对象的创建、组装以及调用工作: using System; namespace IocInCSharp { public class MainApp { public static void Main() { SayHello sayHello = new SayHello(); sayHello.HelloGenerator = new EnHelloGenerator(); sayHello.SayHelloTo("zhenyulu"); } } } 在这个设计中,组件与组件之间、类与类之间存在着紧密的耦合关系。SayHello类中的_helloGen字段类型为 EnHelloGenerator,这将导致我们很难给它赋予一个其它的HelloGenerator(例如CnHelloGenerator,用于生成 中文问候语)。另外MainApp也严重依赖于SayHello.dll以及HelloGenerator.dll,在程序中我们可以看到类似new SayHello();new EnHelloGenerator();的命令。 这种紧密的耦合关系导致组件的复用性降低。试想,如果想复用SayHello组件,那么我们不得不连同HelloGenerator一同拷贝过去, 因为SayHello.dll是依赖与HelloGenerator.dll的。解决这个问题的办法就是“针对抽象(接口)”编程 (依赖倒置原则)。这里的抽象既包括抽象类也包括接口。我不想过多的去谈抽象类和接口的区别,在后续的例子中我们将使用接口。由于接口在进行“动态代理” 仍能保持类型信息,而抽象类可能由于代理的原因导致继承关系的“截断”(如MixIn等)。除此之外,对于单继承的C#语言而言,使用接口可以拥有更大 的弹性。 二、接口依赖 既然类之间的依赖导致耦合过于紧密,按照《设计模式》的理论,我们要依赖于接口。但是人们往往发现,仅仅依赖于接口似乎并不能完全解决问题。我们从上面的例子中抽象出接口后,组件间的依赖关系可能变成如下图所示: 经过改造后,SayHello不再依赖于具体的HelloGenerator,而是依赖于IHelloGenerator接口,如此一来,我们可以 动态的将EnHelloGenerator或是CnHelloGenerator赋给SayHello,其打印行为也随之发生改变。接口的定义以及改造后 的SayHello代码如下(为了节省空间,将代码合并书写): using System; namespace IocInCSharp { public interface IHelloGenerator { string GetHelloString(string name); } public interface ISayHello { IHelloGenerator HelloGenerator{ get; set; } void SayHelloTo(string name); } public class SayHello : ISayHello { private IHelloGenerator _helloGen; public IHelloGenerator HelloGenerator { get { return _helloGen; } set { _helloGen = value; } } public void SayHelloTo(string name) { if(_helloGen != null) Console.WriteLine(_helloGen.GetHelloString(name)); else Console.WriteLine("Client.hello is not initialized"); } } } 但是我们的MainApp似乎并没有从接口抽象中得到什么好处,从图中看,MainApp居然依赖于三个组件:ICommon.dll、 HelloGenerator.dll以及SayHello.dll。这是由于MainApp在这里负责整体的“装配”工作。如果这三个组件中的任何一个 发生变化,都将导致MainApp.exe的重新编译和部署。从这个角度来看,似乎“针对接口编程”并没有为我们带来太多的好处。 如果能够将“组件装配”工作抽象出来,我们就可以将MainApp的复杂依赖关系加以简化,从而 进一步实现解耦。为此,我们引入“工厂”模式,并利用配置文件和反射技术,动态加载和装配相关组件。 三、基于配置文件和Reflection的工厂模式 为了消除MainApp对其它组件的依赖性,我们引入工厂模式,并且根据配置文件指定的装配规程,利用.net提供的反射技术完成对象的组装工作。 本部分代码仅仅提供一种功能演示,如果实际应用仍需进一步完善(建议使用一些成型的Ioc框架,例如Spring.net或Castle等)。经过改造后 的系统,组件间依赖关系如下图: 可以看出这次实现了真正的“针对接口编程”。所有的组件只依赖于接口。MainApp所需的对象是由工厂根据配置文件动态创建并组装起来的。当系统 需求发生变化,只需要修改一下配置文件就可以了。而且MainApp、SayHello和HelloGenerator之间不存在任何的依赖关系,实现 了松耦合。 这是如何实现的呢?我们首先要能够解析配置文件中的信息,然后建立包含相关信息的对象。最后根据这些信息利用反射机制完成对象的创建。首先我们看一下配置文件所包含的内容: 从中我们可以看出,我们实现了一个IocInCSharp.ConfigHandler类,用来处理配置文件中IocInCSharp\ objects结点中的内容。ConfigHandler类将根据该结点下的内容处理并创建一ConfigInfo对象(关于ConfigInfo、 ObjectInfo以及PropertyInfo的代码可自行查看源代码,这里就不再赘述)。ConfigHandler类的代码实现如下: using System; using System.Configuration; using System.Xml; namespace IocInCSharp { public class ConfigHandler:IConfigurationSectionHandler { public object Create(object parent, object configContext, System.Xml.XmlNode section) { ObjectInfo info; PropertyInfo propInfo; ConfigInfo cfgInfo = new ConfigInfo(); foreach(XmlNode node in section.ChildNodes) { info = new ObjectInfo(); info.name = node.Attributes["name"].Value; info.assemblyName = node.Attributes["assembly"].Value; info.typeName = node.Attributes["typeName"].Value; foreach(XmlNode prop in node) { propInfo = new PropertyInfo(); propInfo.propertyName = prop.Attributes["name"].Value; propInfo.assemblyName = prop.Attributes["assembly"].Value; propInfo.typeName = prop.Attributes["typeName"].Value; info.properties.Add(propInfo); } cfgInfo.Objects.Add(info); } return cfgInfo; } } } 通过ConfigHandler的解析,我们最终得到一个ConfigInfo实例,Factory就是根据这个实例中所包含的配置信息,利用反射技术对所需对象生成并组装的。SayHelloFactory的代码如下: using System; using System.IO; using System.Configuration; using System.Reflection; namespace IocInCSharp { public class SayHelloFactory { public static object Create(string name) { Assembly assembly; object o = null; object p; string rootPath = Path.GetDirectoryName(Assembly.GetEntryAssembly().Location) + Path.DirectorySeparatorChar; ConfigInfo cfgInfo = (ConfigInfo)ConfigurationSettings.GetConfig("IocInCSharp/objects"); ObjectInfo info = cfgInfo.FindByName(name); if(info != null) { assembly = Assembly.LoadFile(rootPath + info.assemblyName); o = assembly.CreateInstance(info.typeName); Type t = o.GetType(); for(int i=0; i<info.properties.Count; i++) { PropertyInfo prop = (PropertyInfo)info.properties[i]; assembly = Assembly.LoadFile(rootPath + prop.assemblyName); p = assembly.CreateInstance(prop.typeName); t.InvokeMember(prop.propertyName, BindingFlags.DeclaredOnly | BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.SetProperty, null, o, new Object[] {p}); } } return o; } } } 在上面这段代码中,重点注意三条命令的使用方法: assembly = Assembly.LoadFile(rootPath + prop.assemblyName); p = assembly.CreateInstance(prop.typeName); t.InvokeMember(prop.propertyName, BindingFlags.DeclaredOnly | BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.SetProperty, null, o, new Object[] {p}); Assembly.LoadFile()用于将外部文件装载进来;assembly.CreateInstance()根据装载进来的程序集创建一指定类型的对象;t.InvokeMember(prop.propertyName, ........BindingFlags.SetProperty, null, o, new Object[] {p})利用反射机制对创建出来的对象设置属性值。 我们的Factory就是利用这种方式根据配置文件动态加载程序集,动态创建对象并设置属性的。有了这个Factory,MainApp中的内容就很简单了: using System; namespace IocInCSharp { public class MainApp { public static void Main() { ISayHello sayHello = (ISayHello)SayHelloFactory.Create("SayHello"); if(sayHello != null) sayHello.SayHelloTo("zhenyulu"); else Console.WriteLine("Got an Error!"); } } } 现在,MainApp只依赖于接口,不再依赖于其它组件,实现了松耦合。在本例子中,大家可以尝试将配置文件中的IocInCSharp.CnHelloGenerator更改为IocInCSharp.EnHelloGenerator,看看是否输出内容由中文变为了英文。这便是“注入”的效果。 从上面这个例子我们可以看出,通过自定义配置文件和.net中的Reflection技术,我们自己就可以开发Ioc应用,根据配置文件的信息自行 组装相应的对象。但是Reflection编程的技术门槛还是比较高的,并且在实际应用中配置文件的格式、Handler的设计都不是象上面代码那样的简 单。不过幸好我们现在有很多的Ioc容器可供选择,它们都提供了完整的依赖注入方式,并且比自己写代码更加成熟、更加稳定。使用这些框架可以让程序员在三 两行代码里完成“注入”工作。在我们下一个案例中,我们将使用Spring.net实现依赖注入。我们发现仅仅添加几行代码并更改一下配置文件就可轻松 实现依赖注入。 四、使用Spring.net实现依赖注入 Spring在Java界可是响当当的名字,现在也有.net平台下的Spring框架了,那就是Spring.net。用户可以从http://www.springframework.net/下载到Spring.net的最新版本。本例子中使用的版本为“Spring Interim Build August 15, 2005 ”,并对Spring.Services组件中的Remoting部分做了微小调整,删除了代码中用于输出的部分命令。 Spring.net为我们提供了一种基于配置文件的注入方式,目前Spring.net允许将值注入到属性,也允许将一个工厂绑定到属性,工厂的 产品将注入属性;除此之外,Spring.net还允许将一个方法的返回结果绑定到属性;它还可以在绑定之前强制进行初始化。另外Spring.net还 专门针对.net提供了Remoting以及Windows Service的“注入”方式。Spring.AOP允许完成横切(不过目前是调用的是AopAlliance的代码)。 尽管我对基于配置文件的注入方式仍然有些偏见(我认为它很难Debug、难于理解、没有编译错误校验、编写效率比较低。另外它还存在安全隐患 ,恶意用户可以借助修改配置文件将恶意代码注入系统。因此,Spring.net在Web开发中应当更具优势),但这并不能掩盖Spring.net的光 芒(据说Castle比Spring.net要好,但目前我还没有尝试过使用Castle)。使用Spring.net,我们只需修改两三行代码,并提供 相应配置文件,就可以轻松实现Ioc。应用Spring.net后,我们的系统依赖关系如下图所示:   从图中可以看出,MainApp、SayHello、HelloGenerator之间并不存在任何依赖关系,它们都依赖于抽象出来的接口文件。除 此之外,MainApp还依赖于Spring.net,这使得MainApp可以借助Spring.net实现组件动态创建和组装。 对于原有代码,我们几乎不用作任何调整,唯一需要修改的就是MainApp中的调用方法,代码如下: using System; using System.Configuration; using Spring.Context; namespace IocInCSharp { public class MainApp { public static void Main() { try { IApplicationContext ctx = ConfigurationSettings.GetConfig("spring/context") as IApplicationContext; ISayHello sayHello = (ISayHello)ctx.GetObject("mySayHello"); sayHello.SayHelloTo("zhenyulu"); } catch (Exception e) { Console.WriteLine(e); } } } } 首先我们要添加对Spring.Context命名空间的引用,然后解析配置文件的"spring/context"结点,得到一 IApplicationContext对象(就好比在上一个例子中我们得到的ConfigInfo对象一样),剩下的事情就是向该Context索要相 关的对象了(ISayHello)ctx.GetObject("mySayHello"),其中"mySayHello"由配置文件指定生成方式和注入 方式。 配置文件的内容如下: 注意观察结点,就是由这里定义对象间相互依赖关系的。其中的结点定义了对什么属性执行注入,以及注入的内容是什么()。大家可以尝试将改为,看一看程序执行结果有什么变化来体Spring.net的Ioc功能。 如果读者读到这里仍然觉得Ioc没有什么的话,那让我们再来看一个更为复杂的例子。在当前例子中,MainApp通过依赖注入调用了 HelloGenerator的功能,但所有的调用都发生在本地。当前程序是一个地地道道的本地应用程序。现在如果要求在不更改一行代码的情况下,将 HelloGenerator.dll放到另外一台计算机上,MainApp通过远程调用(Remoting)来访问HelloGenerator的功 能。这似乎就有一定的难度了。 这么作并不是没有任何依据,其实Ioc除了可以实现依赖注入外,我们还应当看到它可以将我们从复杂的物理架构中解脱出来,专心于业务代码的开发。系 统开发中关键是逻辑分层。在一个系统不需要Remoting,开发的系统就是本地应用程序;当需要Remoting,不用修改任何代码就可以将系统移 植为分布式系统。Ioc使这一切成为可能。Rod Johnson在他的《J2EE without EJB》一书中有着详细的论述,很值得一读。据说该书的中文译本今年九月份出版(呵呵,就是这个月,不过我还没有看到市面上有卖的)。 为了能够更深入的分析在“Remoting”改造过程中我们可能遇到的麻烦,在后续两部分内容中,我们将分别介绍不使用Ioc的Remoting改造以及使用Ioc的改造,并比较两者之间的区别。 五、使用Remoting对原有系统进行改造 如果使用Remoting技术对HelloGenerator进行改造,使其具有分布式远程访问能力,那么在不使用Ioc技术的情况下,我们将作出如下调整: (1)让HelloGenerator继承自MarshalByRefObject类 如果要让某个对象具有分布式的功能,必须使其继承自MarshalByRefObject,这样才可以具有远程访问的能力。因此我们需要调整EnHelloGenerator和CnHelloGenerator的代码。这里以EnHelloGenerator为例: using System; namespace IocInCSharp { public class EnHelloGenerator : MarshalByRefObject, IHelloGenerator { public string GetHelloString(string name) { return String.Format("Hello, {0}", name); } } } (2)将修改后的HelloGenerator发布出去 在这一步中,我们创建了一个新的Console应用程序RemotingServer,并在其中注册了一个Channel,发布服务并进行监听。代码如下: using System; using System.Configuration; using System.Collections; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; using System.Runtime.Serialization.Formatters; namespace IocInCSharp { public class Server { public static void Main() { int port = Convert.ToInt32(ConfigurationSettings.AppSettings["LocalServerPort"]); try { BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider(); BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider(); serverProvider.TypeFilterLevel = TypeFilterLevel.Full; IDictionary props = new Hashtable(); props["port"] = port; props["timeout"] = 2000; HttpChannel channel = new HttpChannel(props, clientProvider, serverProvider); ChannelServices.RegisterChannel(channel); RemotingConfiguration.RegisterWellKnownServiceType( typeof(EnHelloGenerator), "HelloGenerator.soap", WellKnownObjectMode.Singleton); Console.WriteLine("Server started!\r\nPress ENTER key to stop the server..."); Console.ReadLine(); } catch { Console.WriteLine("Server Start Error!"); } } } } (3)全新的客户端调用代码 为了使得客户端MainApp能够调用到远程的对象,我们需要修改它的代码,注册相应的Channel并进行远程访问。修改后的MainApp代码如下: using System; using System.Configuration; using System.Collections; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; using System.Runtime.Serialization.Formatters; namespace IocInCSharp { public class MainApp { public static void Main() { //建立连接 BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider(); BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider(); serverProvider.TypeFilterLevel = TypeFilterLevel.Full; IDictionary props = new Hashtable(); props["port"] = System.Convert.ToInt32(ConfigurationSettings.AppSettings["ClientPort"]); HttpChannel channel = new HttpChannel(props, clientProvider, serverProvider); ChannelServices.RegisterChannel(channel ); //创建远程对象 ISayHello sayHello = new SayHello(); string RemoteServerUrl = ConfigurationSettings.AppSettings["RemoteServerUrl"]; sayHello.HelloGenerator = (IHelloGenerator)Activator.GetObject(typeof(IHelloGenerator), RemoteServerUrl); sayHello.SayHelloTo("zhenyulu"); } } } 在这段代码中,远程对象的创建是通过(IHelloGenerator)Activator.GetObject(typeof(IHelloGenerator), RemoteServerUrl)实现的。到此为止,我们就完成了对原有系统的Remoting改造。 经过调整后的系统,其组件间相互依赖关系如下图所示: 注意ICommon.dll文件在Client和Server端都有。 在整个调整过程中,我们修改了Server端的EnHelloGenerator以及CnHelloGenerator的代码,Client端的 MainApp也 作了修改,以加入了远程访问机制。那么能不能对原有代码不作任何修改就实现远程访问机制呢?当然可以!不过我们还要请出Sping.net帮助我们实现这 一切。 六、利用Ioc在不修改任何原有代码的情况下实现Remoting 上文我们提到,为了实现对HelloGenerator.dll的分布式调用,我们不得不修改了原有程序的多处代码。那么有没有可能在不动任何原有 代码的情况下,单纯靠添加组件、修改配置文件实现远程访问呢?当然可以。这次我们还是使用Spring.net完成这个工作。 经过调整后的系统组件构成如下图所示: 该方案没有修改“src\Step3”中的任何代码,仅仅通过修改配置文件和添加了若干个组件就实现了远程访问。修改方案如下: (1)使用Proxy模式代理原有HelloGenerator 如果要让某个对象具有分布式的功能,必须使其继承自MarshalByRefObject。但是由于不能修改任何原有代码,所以这次我们只能绕道而 行, 借助Proxy模式代理原有的HelloGenerator。在RemotingServer项目中,我们定义了一个新类 HelloGeneratorProxy继承自MarshalByRefObject,通过委派的方式对原有的HelloGenerator进行调用,代 码如下: using System; namespace IocInCSharp { public class HelloGeneratorProxy : MarshalByRefObject, IHelloGenerator { private IHelloGenerator _helloGen; public IHelloGenerator HelloGenerator { get { return _helloGen; } set { _helloGen = value; } } public string GetHelloString(string name) { if(_helloGen != null) return _helloGen.GetHelloString(name); return null; } } } 仔细观察,我们发现HelloGeneratorProxy持有一个对IHelloGenerator的引用,该属性是可以Set的,因此我们可 以借助Ioc的威力,通过调整Sping.net的配置文件动态决定远程服务器究竟发布EnHelloGenerator还是 CnHelloGenerator。 (2)发布HelloGeneratorProxy 通过RemotingServer.exe,我们将HelloGeneratorProxy发布出去,客户端实际上调用的是Proxy对象(不用担心,由于“针对接口编程”,客户端只知道它是IHelloGenerator类型对象)。服务器端代码如下: using System; using System.Configuration; using System.Collections; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; using System.Runtime.Serialization.Formatters; using Spring.Context; namespace IocInCSharp { public class Server { public static void Main() { int port = Convert.ToInt32(ConfigurationSettings.AppSettings["LocalServerPort"]); try { BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider(); BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider(); serverProvider.TypeFilterLevel = TypeFilterLevel.Full; IDictionary props = new Hashtable(); props["port"] = port; props["timeout"] = 2000; HttpChannel channel = new HttpChannel(props, clientProvider, serverProvider); ChannelServices.RegisterChannel(channel); IApplicationContext ctx = ConfigurationSettings.GetConfig("spring/context") as IApplicationContext; HelloGeneratorProxy proxy = (HelloGeneratorProxy)ctx.GetObject("myHelloGeneratorProxy"); RemotingServices.Marshal(proxy, "HelloGenerator.soap"); Console.WriteLine("Server started!\r\nPress ENTER key to stop the server..."); Console.ReadLine(); } catch { Console.WriteLine("Server Start Error!"); } } } } 注意其中的几条命令: IApplicationContext ctx = ConfigurationSettings.GetConfig("spring/context") as IApplicationContext; HelloGeneratorProxy proxy = (HelloGeneratorProxy)ctx.GetObject("myHelloGeneratorProxy"); RemotingServices.Marshal(proxy, "HelloGenerator.soap"); 我们使用Ioc向HelloGeneratorProxy注入具体的HelloGenerator对象,并通过 RemotingServices.Marshal(proxy, "HelloGenerator.soap")命令将该实例发布出去。服务器端的配置文件如下: 用户可以尝试将配置文件中更改为,重新启动服务后看看客户端调用结果是什么? (3)客户端实现技术-1 客户端实现起来要麻烦一些。由于不允许修改MainApp中的任何代码,我们必须能够在合适的机拦截代码运行并创建远程连接,同确保在Ioc注 入注入的是远程对象。所有这些工作Sping.net都考虑的很周到。它提供了depends-on属性,允许在执行某一操作前强制执行某段代码。在客 户端的配置文件中,我们可以看到如下的配置选项: ......... 这表示,当我们初始化mySayHello,要先去调用ForceInit.dll文件中ForceInit类的Init方法。ForceInit是一个新编写的类,其主要目的就是创建并注册一个用于远程通讯的Channel。代码实现如下: using System; using System.Collections; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; using System.Runtime.Serialization.Formatters; namespace IocInCSharp { public class ForceInit { public static void Init() { //建立连接 BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider(); BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider(); serverProvider.TypeFilterLevel = TypeFilterLevel.Full; IDictionary props = new Hashtable(); props["port"] = 8199; props["name"] = "myHttp"; HttpChannel channel = new HttpChannel(props, clientProvider, serverProvider); //获得当前已注册的通道; IChannel[] channels = ChannelServices.RegisteredChannels; //关闭指定名为MyHttp的通道; foreach (IChannel eachChannel in channels) if (eachChannel.ChannelName == "myHttp") ChannelServices.UnregisterChannel(eachChannel); ChannelServices.RegisterChannel(channel); } } } (4)客户端实现技术-2 剩下的工作就是为mySayHello的HelloGenerator注入远程对象。通常情况下我们需要使用 Activator.GetObject方法调用远程对象,不过Spring.net已经将其封装起来,我们只需修改一下配置文件,就可以确保调用到远程 对象。配置文件对应部分如下: ...... IocInCSharp.IHelloGenerator, ICommon http://127.0.0.1:8100/HelloGenerator.soap 借助Spring.Remoting.SaoFactoryObject,我们轻松实现了远程对象访问,不必书写一行代码。(目前SAO在 Spring.net的实现尚不完整,按照Spring.net帮助手册上的做法,通过配置文件只能实现客户端访问远程对象,还做不到服务器端发布远程对 象) (5)使用AOP拦截调用 Sping.net目前已经实现AOP功能,我们可以很容易的对方法进行拦截和调用。需要做的工作就是设计相应的Interceptor,然后修改 配置文件。目前Sping.net使用的AOP功能是AopAlliance的实现,因此代码编写命名空间引用让人感觉多少有些别扭,不是以Sping 开头。我编写的MethodInterceptor代码如下: using System; using AopAlliance.Intercept; namespace IocInCSharp { class MethodInterceptor : IMethodInterceptor { public object Invoke(IMethodInvocation invocation) { Console.WriteLine("Before Method Call..."); object returnValue = invocation.Proceed(); Console.WriteLine("After Method Call..."); return returnValue; } } } 在方法调用前打印"Before Method Call...",在方法调用后打印"After Method Call..."。剩下的工作就是修改配置文件,将其应用到相应的方法上。配置文件片断如下: ...... MethodAdvice 通过以上操作,我们在没有修改任何原有代码的情况下,让原有系统实现了远程分布式访问。 请大家访问示例代码的“bin\Step5"目录,下面有3个子目录:Server、Client、WithoutRemoting。首先运行 Server目录下的RemotingServer.exe,然后运行Client目录下的MainApp.exe进行远程调用。系统通过 Remoting完成远程调用。关闭所有程序后,进入到WithoutRemoting目录,里面有个Readme.txt文件,按照操作步骤将文件: ..\Server\HelloGenerator.dll ..\Client\MainApp.exe ..\Client\ICommon.dll ..\Client\SayHello.dll ..\Client\Spring.Core.dll ..\Client\log4net.dll   拷贝到该目录,再次运行MainApp.exe,你发现它是一个地地道道的本地应用程序!本地与远程唯一的区别就是配置文件的不同以及增加了几个其它的DLL。这正式我们这个示例的价值体现。 到此为止,我们完成了对Ioc应用的一系列模拟。Ioc写得多一些,AOP写得少了点。欢迎大家批评指正。
构建安全的 Microsoft® ASP.NET 应用程序:前言 更新日期: 2004年04月20日 本指南的目标 本指南不是介绍安全性,也不是 Microsoft .NET Framework 的安全性参考材料;如果您要了解这方面的内容,请查看 MSDN 中的 .NET Framework 软件开发工具包 (SDK)。本指南包含该文档中没有的内容,并通过具体方案提供一些建议和行之有效的技术。我们的目标是使本指南尽可能地贴近实际应用,因此,其中的事例、建议和最佳做法都来自现场操作、客户经验和 Microsoft 产品小组。 构建 .NET Web 应用程序的过程中使用了很多技术。为了构建有效的应用程序级别的身份验证和授权策略,您需要了解如何在每一种产品和技术领域内优化各种安全功能,以及如何使它们协同作用以提供纵深防御的有效安全策略。本指南的重点是分布式 ASP.NET 应用程序的安全性和各层之间的标识管理。 具体来说,我们选择将重点放在身份验证、授权和安全通信方面。安全性是一个广泛的话题。调查显示,在一开始就设计使用身份验证和授权功能可大大提高应用程序的安全性。安全通信是分布式应用程序保护工作中不可或缺的部分;保护分布式应用程序的目的是保护机密数据,这些数据包括传递到应用程序和从应用程序传出的凭据,以及在应用程序的各层之间传递的凭据。 返回页首 本指南的读者 如果您是规划构建方案的中间件开发人员或架构设计师,或者当前正在使用以下一项或多项技术构建 .NET Web 应用程序,则应该阅读本指南。 • ASP.NET • Web 服务 • 企业服务 • 远程处理 • ADO.NET 为了最有效地利用本指南来设计和构建安全的 .NET Web 应用程序,您应该已经了解并使用过 .NET 开发技巧和技术。您应该熟悉分布式应用程序体系结构;如果您已经实施过 .NET Web 应用程序解决方案,还应该了解您自己的应用程序的体系结构和部署模式。 返回页首 如何阅读本指南 本指南的内容分为几个相对独立的模块。这样您就可以随意选取要阅读的章节。例如,如果您对特定技术提供的纵深防御安全功能感兴趣,可以直接阅读本指南的第 III 部分(第 8 章到第 12 章),其中包含涉及 ASP.NET、企业服务、Web 服务、.NET Remoting 和数据访问的详细信息。 然而,我们建议您先阅读本指南的前几章(第 1 章到第 4 章),即第 I 部分,因为这些章节可帮助您了解安全模型并可帮助您自行确定核心技术和安全服务。应用程序架构设计师一定要阅读第 3 章,这一章提供了一些有关跨 Web 应用程序的不同层设计身份验证和授权策略的重要知识。第 I 部分提供了一些基本资料,这些资料可帮助您充分理解并应用本指南其他章节中的知识。 本指南第 II 部分中 Intranet、Extranet 和 Internet 这几章(第 5 章到第 7 章)说明如何保障特定应用方案的安全性。如果知道您的应用程序目前采用或将要采用的体系结构和部署模式,则可通过本指南的这一部分了解相关的安全问题,以及保障特定方案的安全性所需的基本配置步骤。 最后,本指南第 IV 部分的补充信息和参考材料可帮助您加深对特定技术领域的理解。这一部分还提供了基本知识文章集锦,可指导您在最短的间内开发出实用的安全解决方案。 返回页首 本指南的内容构成 本指南分为四部分。目标是按逻辑划分各组成部分,这样有助于您更容易地消化内容。 第 I 部分,安全模型 本指南的第 I 部分是其他部分的基础。熟悉第 I 部分介绍的概念、原则和技术,可以帮助您充分理解和应用本指南其他章节中的知识。第 I 部分包括以下各章: • 第 1 章,简介 • 第 2 章,ASP.NET 应用程序的安全模型 • 第 3 章,身份验证和授权 • 第 4 章,安全通信 第 II 部分,应用程序方案 大多数应用程序都可以归类为 Intranet 应用程序、Extranet 应用程序或 Internet 应用程序。本指南的这一部分介绍一组常见的应用程序方案,这些方案分别属于上述类别之一。其中首先介绍了每种方案的主要特征并分析了其潜在的安全威胁。 接着说明了如何为每种应用程序方案配置和实施最适合的身份验证、授权和安全通信策略。每种方案还包含若干小节,这些小节包括详细的分析、需要注意的常见隐患及常见问题 (FAQ)。第 II 部分包括以下各章: • 第 5 章,Intranet 安全性 • 第 6 章,Extranet 安全性 • 第 7 章,Internet 安全性 第 III 部分,保护各层的安全 本指南的这一部分提供了有关应用程序各层的详细信息,以及有关保护与 .NET 相关的 Web 应用程序的技术。第 III 部分包括以下各章: • 第 8 章,ASP.NET 安全性 • 第 9 章,企业服务安全性 • 第 10 章,Web 服务安全性 • 第 11 章,.NET Remoting 安全性 • 第 12 章,数据访问安全性 各章分别概述了适用于所讨论的特定技术的安全体系结构。针对每种技术,分别讨论了身份验证和授权策略、可配置的安全选项、编程安全选项,还提出了有关何使用特定策略的实用建议。 每一章都提供了一些指导和说明,您可根据这些信息为各种技术选择和实施最适合的身份验证、授权和安全通信选项。此外,每一章还针对每一特定技术提供了补充信息。最后,每一章都用一段简明扼要的建议作为结束语。 第 IV 部分,参考 本指南的这一参考部分提供一些补充信息,可帮助您加深对前面各章讲述的技术、策略和安全解决方案的理解。详尽的“基本知识”主题提供了循序渐进的步骤,从而帮助您实施特定的安全解决方案。这一部分包含以下各章: • 第 13 章,解决安全问题 • 基本知识 • 基本配置 • 配置存储和工具 • 参考中心 • 工作原理 • ASP.NET 标识矩阵 • 加密技术、密钥和证书 • 词汇表 返回页首 系统要求 本指南将帮助您使用 .NET Framework 针对 Windows 2000 设计和构建安全的 ASP.NET 应用程序。我们以 .NET Framework 版本 1 (service pack 2) 为目标,虽然使用的是下一版本的 .NET Framework 中的概念和代码。本指南介绍了将在下一个版本中提供的新的安全功能,以及将随 Windows .NET Server 2003(Microsoft 的下一代 Windows Server 操作系统)提供的其他功能。 要使用本指南,您至少需要一台运行 Windows XP Professional 或 Windows 2000 Server SP3 的计算机。此外,您还需要安装 Visual Studio .NET、.NET Framework SP2 和 SQL Server 2000 SP2。 要实现其中讨论的某些解决方案,您还需要第二台运行 Windows 2000 Server SP3、Windows 2000 Advanced Server SP3 或 Windows 2000 DataCenter Server SP3 的计算机。 返回页首 安装示例文件 您可以从本指南所在网址 http://www.microsoft.com/mspress/guides/6501.asp 下载示例文件。要下载示例文件,请单击该网页右侧的“More Information”(更多信息)菜单中的“Companion Content”(附带内容)链接。单击后将下载“Companion Content”(附带内容)页,其中包含下载示例文件的链接。
DirectX修复工具(DirectX Repair)是一款系统级工具软件,简便易用。本程序为绿色版,无需安装,可直接运行。 本程序的主要功能是检测当前系统的DirectX状态,如果发现异常则进行修复。程序主要针对0xc000007b问题设计,可以完美修复该问题。本程序中包含了最新版的DirectX redist(Jun2010),并且全部DX文件都有Microsoft的数字签名,安全放心。 本程序为了应对一般电脑用户的使用,采用了傻瓜式一键设计,只要点击主界面上的“检测并修复”按钮,程序自动完成校验、检测、下载、修复以及注册的全部功能,无需用户的介入,大大降低了使用难度。 本程序适用于多个操作系统,如Windows XP(需先安装.NET 2.0,详情请参阅“致Windows XP用户.txt”文件)、Windows Vista、Windows 7、Windows 8、Windows 8.1、Windows 8.1 Update、Windows 10,同兼容32位操作系统和64位操作系统。本程序根据系统的不同,自动调整任务模式,无需用户进行设置。 本程序的V3.3版分为标准版、增强版以及在线修复版。其中的标准版以及增强版都包含完整的DirectX组件。除此之外,增强版中还额外包含了c++ Redistributable Package,因此增强版不但能解决DirectX组件的问题,而且还能解决c++组件异常产生的问题。增强版适合无法自行解决c++相关问题的用户使用。在线修复版的功能与标准版相同,只是其所需的文件将通过Internet下载,因此大大减小了程序的体积。本程序的各个版本之间,主程序完全相同,只是配套使用的数据包不同。因此,当您使用标准版数据包程序将进行标准修复;当您使用增强版的数据包程序将进行增强修复;当数据包不全或没有数据包(即只有DirectX Repair.exe程序程序将进行在线修复。在线修复、离线修复可自由灵活组合,充分满足不同用户的需要。 本程序自V2.0版起采用全新的底层程序架构,使用了异步多线程编程技术,使得检测、下载、修复单独进行,互不干扰,快速如飞。新程序更改了自我校验方式,因此使用新版本程序出现自我校验失败的错误;但并非取消自我校验,因此程序安全性与之前版本相同,并未降低。 程序有自动更新c++功能。由于绝大多数软件运行需要c++的支持,并且c++的异常也导致0xc000007b错误,因此程序在检测修复的同,也根据需要更新系统中的c++组件。自V3.2版本开始使用了全新的c++扩展包,可以大幅提高工业软件修复成功的概率。修复c++的功能仅限于增强版,标准版及在线修复版在系统c++异常(非丢失提示用户使用增强版进行修复。 程序有两种窗口样式。正常模式即默认样式,适合绝大多数用户使用。另有一种简约模式,此窗口将只显示最基本的内容,修复自动进行,修复完成10秒钟后自动退出。该窗口样式可以使修复工作变得更加简单快速,同方便其他软件、游戏将本程序内嵌,即可进行无需人工参与的快速修复。开启简约模式的方法是:打开程序所在目录下的“Settings.ini”文件(如果没有可以自己创建),将其中的“FormStyle”一项的值改为“Simple”并保存即可。 程序有高级筛选功能,开启该功能后用户可以自主选择要修复的文件,避免了其他不必要的修复工作。同,也支持通过文件进行辅助筛选,只要在程序目录下建立“Filter.dat”文件,其中的每一行写一个需要修复文件的序号即可。该功能仅针对高级用户使用,并且必须在正常窗口模式下才有效(简约模式无效)。 本程序有自动记录日志功能,可以记录每一次检测修复结果,方便在出现问题,及分析和查找原因,以便找到解决办法。 程序的“选项”对话框中包含了4项高级功能。点击其中的“注册系统文件夹中所有dll文件”按钮可以自动注册系统文件夹下的所有dll文件。该项功能不仅能修复DirectX的问题,还可以修复系统中很多其他由于dll未注册而产生的问题,颇为实用。点击该按钮旁边的小箭头,还可以注册任意指定文件夹下的dll文件,方便用户对绿色版、硬盘版的程序组件进行注册。点击第二个按钮可以为dll文件的右键菜单添加“注册”和“卸载”项,方便对单独的dll文件进行注册。请注意,并不是所有的dll文件都可以通过这种方式注册。点击“DirectX版本”选项卡可以自行修改系统中DirectX的版本信息。点击“DirectX加速”选项卡可以控制系统中DirectX加速的开启与关闭。 新版程序集成了用户反馈程序,可以在用户允许的前提下发送检测修复结果。用户也可以在出现问题通过反馈程序和软件作者进行交流,共同查找问题。反馈是完全自愿和匿名(如果不填写E-mail地址)的。 本程序的通用版基于Microsoft .NET Framework 2.0开发,对于Windows 2000、Windows XP、Windows 2003的用户需要首先安装.NET Framework 2.0或更高版本方可运行程序。有关下载和安装的详细信息请参阅“致Windows XP用户.txt”文件。对于Windows Vista、Windows 7及后续用户,可以直接运行程序。 同鉴于Windows 8(Windows 8.1、Windows 8.1 Update)、Windows 10系统中默认未包含.NET Framework 2.0,因此新版的程序文件夹内将包含一个DirectX_Repair_win8的特别版程序,该程序功能与通用版相同,基于.NET Framework 4.0开发,可以在Windows8(Windows 8.1、Windows 8.1 Update)、Windows 10系统中直接运行(其他系统如果安装了.NET Framework 4.0也可以运行这个特别版的程序)。 本程序的官方博客地址为:http://blog.csdn.net/vbcom/article/details/6962388 所有的更新以及技术支持都可以到该博客上找到。
### 回答1: 要在Win11上安装.NET Framework 3.5,可以按照以下步骤操作: 1. 打开“控制面板”,选择“程序和功能”。 2. 点击“打开或关闭Windows功能”。 3. 在弹出的窗口中,勾选“.NET Framework 3.5(包括.NET 2.和3.)”选项。 4. 点击“确定”按钮,等待安装完成。 安装完成后,您就可以在Win11上使用.NET Framework 3.5了。 ### 回答2: Windows 11作为微软最新的操作系统,具有很多新功能和改进,但在安装某些旧软件和应用程序,可能需要先安装.NET Framework 3.5。在本文中,我们将介绍如何在Windows 11中安装.NET Framework 3.5。 首先,打开Windows 11的“设置”应用程序。可以通过点击“开始菜单”上的“设置”图标或使用快捷键“Win + I”打开这个应用程序。 接下来,点击左侧菜单中的“应用”,然后在右侧页面上选择“可选功能”。 在下一页中,单击“添加功能”,这将打开“添加功能”向导。 在“添加功能”向导中,找到“.NET Framework 3.5(包括.NET 2.0和3.0)”并将其选中。 单击“安装”按钮开始安装过程。系统需要下载并安装必要的文件,所以需要一些间。 在安装过程完成后,单击“完成”并重新启动你的计算机。 完成这些步骤后,你就已经成功地将.NET Framework 3.5安装到了Windows 11中。如果你有一些旧软件或应用程序需要这个框架来运行,现在它们应该可以正常工作了。 总之,通过Windows 11的“添加功能”向导,相对容易地安装了.NET Framework 3.5。需要注意的是,在安装这个框架之前,需要检查操作系统版本,因为只有特定版本的Windows 11才支持安装.NET Framework 3.5。 ### 回答3: Windows 11 是一款全新的操作系统,除了拥有更加美观的外观和更加强大的性能之外,它还针对 .NET Framework 进行了一些改进。然而,在某些情况下,用户可能需要安装 .NET Framework 3.5 才能运行一些旧版本软件或应用程序以下是如何安装 .NET Framework 3.5 的步骤: 第一步:在 Windows 11 中打开“设置”应用程序,并选择“应用程序”。 第二步:下拉到“相关设置”下方,并选择“应用程序和功能”。 第三步:在“应用程序和功能”页面中,选择“可选功能”。 第四步:在“可选功能”页面中,选择“添加一个功能”。 第五步:在“添加一个功能”页面中,找到“.NET Framework 3.5”并打钩选择它。 第六步:单击“安装”按钮,让 Windows 11 安装 .NET Framework 3.5。 第七步:等待安装完成,并单击“关闭”按钮。 以上就是如何在 Windows 11 中安装 .NET Framework 3.5 的详细步骤。在完成安装后,您的电脑将能够运行需要此框架的应用程序,同也能保证操作系统的稳定性和安全性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

黑色地带(崛起)

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值