16 个解决方案
#1
应该是这样的，要不然.net怎么知道编译那个.dll文件？我想这是无法修改的，从没听说能
对此进行配置。
对此进行配置。
#2
是的 这是缺省的
#3
可以放在站点根目录下的bin文件夹下~
比如一个解决方案下的所有应用程序的DLL文件都可以统一放在根目录下的bin下
而且各应用程序目录下只需要放wen.config Global.asax *.aspx等文件就好了, *.aspx.cs还有src文件都不用保留
比如一个解决方案下的所有应用程序的DLL文件都可以统一放在根目录下的bin下
而且各应用程序目录下只需要放wen.config Global.asax *.aspx等文件就好了, *.aspx.cs还有src文件都不用保留
#4
在项目属性里可以修改输出目录。
#5
我知道可以在项目属性里可以修改输出目录，但我现在想知道能否部署在我希望的目录上，如果光修改输出目录还是不能运行
#6
>>>asp.net应用程序编译后的dll文件一定要放在aspx文件所在目录的bin目录下吗？
no, if your dll is strong-named, you can install it to GAC, or modify your web.config, for example, from the documentation:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
no, if your dll is strong-named, you can install it to GAC, or modify your web.config, for example, from the documentation:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
#7
同意saucer(思归) 大侠的
#8
配制WEB.CONFIG文件
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
或在项目中改它的路径安装打包时会自动发布到相对应的目录
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
或在项目中改它的路径安装打包时会自动发布到相对应的目录
#9
无效
#10
ASP。NET（特别是CLR）不需要对组件进行注册，只要组件文件位于虚拟目录的bin目录中（不可以修改该目录的名称）就可以创建asp.net网页并使用这个组件了
ASP.NET 是使用 CLR 的程序服务，不是com建立的，这表明可以将最新的DLL 复制到自己的应用程序目录中（bin目录） 他会自动开始使用这些文件中的组件，并从内存中卸载掉老版本 的组件
为了简化应用程序的重新部署，ASP。NET使用了CLR的Shadow Copy 功能来确保组件文件不会被锁定。CLR的Shadow Copy 功能之所以如此，是因为文件在加载之前会先复制到某个高速缓存区域。这样也就表明原来的文件不会从最初的位置加载了。
Shadow Copy功能仅用于位于bin目录的ASP.NET组件文件
ASP.NET 是使用 CLR 的程序服务，不是com建立的，这表明可以将最新的DLL 复制到自己的应用程序目录中（bin目录） 他会自动开始使用这些文件中的组件，并从内存中卸载掉老版本 的组件
为了简化应用程序的重新部署，ASP。NET使用了CLR的Shadow Copy 功能来确保组件文件不会被锁定。CLR的Shadow Copy 功能之所以如此，是因为文件在加载之前会先复制到某个高速缓存区域。这样也就表明原来的文件不会从最初的位置加载了。
Shadow Copy功能仅用于位于bin目录的ASP.NET组件文件
#11
当第一次请求一个页面中,ASP.NET会将网页编译成一个程序集 所创建的目录%systemroot%/Micorsoft.net/framework/v1.n.nnn/Temporary ASP.NET Files下的一个子目录
中,该程序集还包含了一个生成的类,该类由System.Web.UI.Page类派生.该类包含了 生成网页的所需的全部代码,每次出现对aspx网页的请求时 .Net Framework 都会事例化次类,以处理请求.
当为某个.aspx网页 生成一个.NET类时,该网页的依赖性(如 .aspx网页,和任何包含文件)就构成了经过编译后的类的组成部分.在网页显示出来之前,这些依赖性都要进行检查,如果网页被编译后发现文件有改动,程序集会被删除,创建一个新的程序集
machine.config 的编译元素中添加一个tempDiectory属性,修改ASP.NET所使用的临时目录
#12
如果无效那么<probing privatePath="bin;bin2\subbin;bin3"/>这个privatePath有什么用，看帮助的确是一个搜索目录
#13
把你的dll全部放在C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322里面好了
呵呵,虽然不是很科学...
呵呵,虽然不是很科学...
#14
我也很关注这个问题﹐在学习过程中仿petshop做了个测试﹐分三层﹐我把cs转换了dll文件。但不知怎幺调用dll.﹐全部复制到bin目录下﹐肯定不行。比如说在对客户安装时﹐BLL﹑DALFactory之类中间层的dll要根据需要部书到另外一台机﹐而SQLServer数据层又是另外一台机﹐path是动态的
#15
我不是想把所有的文件放在C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322，而是想按我的要求安排在任意目录
#16
up
#1
应该是这样的，要不然.net怎么知道编译那个.dll文件？我想这是无法修改的，从没听说能
对此进行配置。
对此进行配置。
#2
是的 这是缺省的
#3
可以放在站点根目录下的bin文件夹下~
比如一个解决方案下的所有应用程序的DLL文件都可以统一放在根目录下的bin下
而且各应用程序目录下只需要放wen.config Global.asax *.aspx等文件就好了, *.aspx.cs还有src文件都不用保留
比如一个解决方案下的所有应用程序的DLL文件都可以统一放在根目录下的bin下
而且各应用程序目录下只需要放wen.config Global.asax *.aspx等文件就好了, *.aspx.cs还有src文件都不用保留
#4
在项目属性里可以修改输出目录。
#5
我知道可以在项目属性里可以修改输出目录，但我现在想知道能否部署在我希望的目录上，如果光修改输出目录还是不能运行
#6
>>>asp.net应用程序编译后的dll文件一定要放在aspx文件所在目录的bin目录下吗？
no, if your dll is strong-named, you can install it to GAC, or modify your web.config, for example, from the documentation:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
no, if your dll is strong-named, you can install it to GAC, or modify your web.config, for example, from the documentation:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
#7
同意saucer(思归) 大侠的
#8
配制WEB.CONFIG文件
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
或在项目中改它的路径安装打包时会自动发布到相对应的目录
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
或在项目中改它的路径安装打包时会自动发布到相对应的目录
#9
无效
#10
ASP。NET（特别是CLR）不需要对组件进行注册，只要组件文件位于虚拟目录的bin目录中（不可以修改该目录的名称）就可以创建asp.net网页并使用这个组件了
ASP.NET 是使用 CLR 的程序服务，不是com建立的，这表明可以将最新的DLL 复制到自己的应用程序目录中（bin目录） 他会自动开始使用这些文件中的组件，并从内存中卸载掉老版本 的组件
为了简化应用程序的重新部署，ASP。NET使用了CLR的Shadow Copy 功能来确保组件文件不会被锁定。CLR的Shadow Copy 功能之所以如此，是因为文件在加载之前会先复制到某个高速缓存区域。这样也就表明原来的文件不会从最初的位置加载了。
Shadow Copy功能仅用于位于bin目录的ASP.NET组件文件
ASP.NET 是使用 CLR 的程序服务，不是com建立的，这表明可以将最新的DLL 复制到自己的应用程序目录中（bin目录） 他会自动开始使用这些文件中的组件，并从内存中卸载掉老版本 的组件
为了简化应用程序的重新部署，ASP。NET使用了CLR的Shadow Copy 功能来确保组件文件不会被锁定。CLR的Shadow Copy 功能之所以如此，是因为文件在加载之前会先复制到某个高速缓存区域。这样也就表明原来的文件不会从最初的位置加载了。
Shadow Copy功能仅用于位于bin目录的ASP.NET组件文件
#11
当第一次请求一个页面中,ASP.NET会将网页编译成一个程序集 所创建的目录%systemroot%/Micorsoft.net/framework/v1.n.nnn/Temporary ASP.NET Files下的一个子目录
中,该程序集还包含了一个生成的类,该类由System.Web.UI.Page类派生.该类包含了 生成网页的所需的全部代码,每次出现对aspx网页的请求时 .Net Framework 都会事例化次类,以处理请求.
当为某个.aspx网页 生成一个.NET类时,该网页的依赖性(如 .aspx网页,和任何包含文件)就构成了经过编译后的类的组成部分.在网页显示出来之前,这些依赖性都要进行检查,如果网页被编译后发现文件有改动,程序集会被删除,创建一个新的程序集
machine.config 的编译元素中添加一个tempDiectory属性,修改ASP.NET所使用的临时目录
#12
如果无效那么<probing privatePath="bin;bin2\subbin;bin3"/>这个privatePath有什么用，看帮助的确是一个搜索目录
#13
把你的dll全部放在C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322里面好了
呵呵,虽然不是很科学...
呵呵,虽然不是很科学...
#14
我也很关注这个问题﹐在学习过程中仿petshop做了个测试﹐分三层﹐我把cs转换了dll文件。但不知怎幺调用dll.﹐全部复制到bin目录下﹐肯定不行。比如说在对客户安装时﹐BLL﹑DALFactory之类中间层的dll要根据需要部书到另外一台机﹐而SQLServer数据层又是另外一台机﹐path是动态的
#15
我不是想把所有的文件放在C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322，而是想按我的要求安排在任意目录
#16
up