.NET 框架先决条件

发布于 2024-11-18 07:40:19 字数 473 浏览 2 评论 0原文

你好，朋友们，我需要有关在目标计算机中安装已发布的应用程序时.NET 框架先决条件的解释。

由于java是向下兼容的，我的意思是如果我安装了java v1.6并且应用程序是使用java v1.5开发的（我也意味着只有1.5中可用的类和包用于构建应用程序。）

我确信通过安装最新或更高版本的jre或j2se，开发的应用程序一定可以运行。

同样，在 .NET 平台的情况下，假设如果我使用 .NET Framework 3.5 开发应用程序，并且在目标计算机中我已经安装了 .NET Framework 4.0（最新），即使它提示安装 .NET Framework 3.5 为什么会这样？

实时示例是我已经下载并尝试安装 MySQL Workbench 并安装了 .NET Framework 4.0 但它仍然要求在运行 MySQL 安装之前安装 .NET Framework 3.5。

我的问题是 .NET 框架是否与 java 或 .NET 向下兼容？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

清风不识月 2024-11-25 07:40:19

.NET Framework 中的版本兼容性：

.NET Framework 4 是
向后兼容应用程序
使用 .NET 构建的
框架版本 1.1、2.0、3.0 和
3.5. 换句话说，使用以前构建的应用程序和组件
.NET Framework 的版本将
致力于 .NET Framework 4。
然而，在实践中，这
兼容性可能会被破坏
看似无关紧要的变化
.NET Framework 和变化
编程技术。例如，
.NET 中的性能改进
框架 4 可以暴露竞争
未发生的情况
早期版本。同样，使用
.NET Framework 的硬编码路径
集会，执行平等
与特定版本的比较
.NET Framework 的，并获取
使用私有字段的值
反射不向后兼容
做法。另外，每个版本
.NET Framework 的错误
修复和安全相关的更改
这可能会影响兼容性
一些应用程序和组件。
如果您的应用程序或组件确实
在 .NET 上无法按预期工作
框架4，使用以下
清单。
对于 .NET Framework 2.0、3.0 和 3.5 应用程序：
检查 .NET Framework 4 迁移
任何可能发生的更改的问题
影响您的申请并申请
描述了解决方法。
如果您要重新编译现有源代码
在 .NET Framework 4 上运行的代码，
或者如果您正在开发新版本
的应用程序或组件
面向 .NET Framework 4
现有源代码库，检查
.NET Framework 中已过时的内容
对于过时的类型和成员，以及
应用所描述的解决方法。
（之前编译的代码将
继续对抗类型和
已被标记为的成员
已过时。）
如果您确定更改
.NET Framework 4 破坏了您的
应用程序，检查运行时
设置Schema来确定是否
您可以在您的
应用程序配置文件到
恢复之前的行为。
如果您遇到的问题不属于
记录下来，提交 Microsoft Connect
错误和联系方式[电子邮件受保护]
以及错误编号。

Version Compatibility in the .NET Framework:

The .NET Framework 4 is
backward-compatible with applications
that were built with the .NET
Framework versions 1.1, 2.0, 3.0, and
3.5. In other words, applications and components built with previous
versions of the .NET Framework will
work on the .NET Framework 4.
However, in practice, this
compatibility can be broken by
seemingly inconsequential changes in
the .NET Framework and changes in
programming techniques. For example,
performance improvements in the .NET
Framework 4 can expose a race
condition that did not occur on
earlier versions. Similarly, using a
hard-coded path to .NET Framework
assemblies, performing an equality
comparison with a particular version
of the .NET Framework, and getting the
value of a private field by using
reflection are not backward-compatible
practices. In addition, each version
of the .NET Framework includes bug
fixes and security-related changes
that can affect the compatibility of
some applications and components.
If your application or component does
not work as expected on the .NET
Framework 4, use the following
checklists.
For .NET Framework 2.0, 3.0, and 3.5 applications:
Check .NET Framework 4 Migration
Issues for any changes that might
affect your application and apply the
workaround described.
If you are recompiling existing source
code to run on the .NET Framework 4,
or if you are developing a new version
of an application or component that
targets .NET Framework 4 from an
existing source code base, check
What's Obsolete in the .NET Framework
for obsolete types and members, and
apply the workaround described.
(Previously compiled code will
continue to run against types and
members that have been marked as
obsolete.)
If you determine that a change in the
.NET Framework 4 has broken your
application, check the Runtime
Settings Schema to determine whether
you can use a runtime setting in your
application configuration file to
restore the previous behavior.
If you encounter an issue that is not
documented, file a Microsoft Connect
bug and contact [email protected]
with the bug number.