VS.net的FrameWork2.0的一个有趣的BUG!关于EXE应用程序的.config配置文件，请教大家!

xtmes 2006-04-17 03:22:22

一、我的ＥＸＥ程序是一个基于ＭＦＣ的托管程序，是ＭＤＩ多文档形式，关联了文档类型。
二、我直接启动这个ＥＸＥ时，会调用相应的.Net应用程序config配置文件。即与ＥＸＥ相同目录下与应用程序文件名相同的.exe.config文件。
三、如果我在Windows的资源管理器中，以双击文件的方式加载这个ＥＸＥ应用程序，系统似乎没有加载那个.config的文件。我在其中写的probing的ＸＭＬ字段没有作用。
　　这是否是FrameWork没有预想到的一个问题？？

...全文

93 1 打赏收藏转发到动态举报

写回复

1 条回复

切换为时间正序

请发表友善的回复…

发表回复

xtmes 2006-04-17

打赏
举报

回复

三、如果我在Windows的资源管理器中，以双击关联ＤＯＣ文档文件的方式加载这个ＥＸＥ应用程序，系统似乎没有加载那个.config的文件。我在其中写的probing的ＸＭＬ字段没有作用。

.NET Framework SDK并非运行时环境，而是定义编译时契约的工具集合，其核心价值在于支撑确定性构建、强名称验证、IL级诊断与GAC精准部署。理解csc.exe、ildasm.exe、al.exe、sn.exe、gacutil.exe等命令行工具的职责边界、版本绑定关系及32/64位调用约束，是实现CI/CD自动化、遗留系统合规审计与运行时故障根因定位的技术前提。本文聚焦.NET Framework 4.x生态下真实可用的SDK工具链，覆盖从项目编译、元数据检查、程序集链接到COM注册的完整生命周

.NET Framework 是 Windows 平台企业级应用的底层运行基石，其核心由 CLR 运行时、BCL 类库和配置模型共同构成。从 1.0 到 4.0 的演进并非简单功能叠加，而是经历了四次底层契约重写：泛型引入重构 JIT 行为、CAS 安全模型确立权限边界、WCF/WPF 等技术整合带来跨组件互操作约束，以及 CLR 4.0 的并行运行时机制。这些变更深刻影响着程序集加载、ViewState 序列化、WCF 配置兼容性与 GAC 版本共存等关键环节。尤其在遗留系统迁移中，.NET Framew

.NET Framework并非单纯的功能叠加，而是面向不同硬件约束、部署环境与开发范式的系统性抽象升级。其核心围绕CLR运行时机制、内存管理模型（如分代GC、LOH优化）、异步与并发模型（TPL/async）、声明式编程（LINQ/Expression Tree）及安全模型（CAS→Claims→RBAC）持续演进。理解这些底层原理，有助于规避GAC冲突、GC风暴、线程阻塞、序列化异常等典型问题，并支撑.NET Framework向.NET Core/.NET 5+的平滑迁移。本文聚焦1.0至4.0关键版

.NET Framework升级是企业遗留系统演进中的关键工程实践，其本质并非单纯的技术迭代，而是围绕兼容性、安全生命周期与开发效能的综合权衡。从运行时原理看，.NET 3.5复用.NET 2.0的CLR（v2.0.50727），仅扩展类库（如LINQ、WCF），因此升级不改变JIT行为，却显著影响代码表达力与调试体验；技术价值体现在安全合规（如MS12-037补丁仅支持3.5 SP1）、开发效率（VS 2008智能感知与重构能力）及架构延展性（WCF服务化基础）。典型应用场景包括金融系统PCI DSS合规

.NET Framework 是微软构建的统一托管运行时平台，其核心在于公共语言运行时（CLR）对内存管理、线程调度与类型系统的深度控制。从1.0初代寄生式设计，到2.0引入分代垃圾回收与泛型支持，再到3.5依托表达式树实现LINQ声明式查询，最终在4.0完成IOCP线程池与Task并行库的工程落地——这一演进本质是运行时能力持续解耦、强化与标准化的过程。它奠定了现代.NET跨平台、高性能与安全隔离的技术根基，广泛应用于企业级Web服务、桌面应用及混合部署系统。理解CLR版本差异、泛型JIT特化机制与LIN

15,975

社区成员

115,866

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章