设置的版本升级问题

[扎菲德将军]

全部，

我和我的团队长期以来一直在解决设置问题，但是没有解决方案。本质上，大多数情况下，即使构建发生更改（甚至略有更改），设置文件的升级也会导致设置有些陈旧，看似随机。这很清楚，因为我们看到的东西之前已经设定好了，但现在已经不再存在。根据对时间的观察，这种随机性"may"导致最近被使用。有时回溯很多次修订。这是绝对令人困惑的。我一遍遍地寻找答案。最初，我们每次都调用升级，但是发现我们可以添加版本检查，并且仅在版本更改时才进行升级。因此，当我们更改版本时，我们这样做：

如果（GetLastRevision（）！= GetAppVersionString（））
{
Settings.Default.Upgrade（）;
SetLastRevision（GetAppVersionString（））; //现在，这还将保存所有设置。
return true;
}

我希望有人对此有所修正。这真的是在杀死我们。非常感谢您的帮助！！！

-广州

 

[羊皮]

这是更新程序应用程序吗？您要发布到git或其他回购提供商吗？您如何管理版本？

我觉得这里没有足够的信息可以为您提供帮助，我不能说自己之前从未经历过类似的事情。

 

[扎菲德将军]

这是更新程序应用程序吗？您要发布到git或其他回购提供商吗？您如何管理版本？

我觉得这里没有足够的信息可以为您提供帮助，我不能说自己之前从未经历过类似的事情。

嗨，谢谢你的提问。我们确实发布到私人git仓库。这只是一个测试应用程序，它使用基本的.net设置文件作为存储用户可配置设置的方式。当前使用本地构建手动管理构建，并使用inno编译器执行构建。我已经在考虑使用ADO托管环境来进行更多托管构建。 Inno可能会导致设置升级有些混乱吗？

 

[羊皮]

Inno可能会导致设置升级有些混乱吗？

我不这么认为。我刚刚做了一些挖掘工作，看来您的问题相当孤立。因此，我会更倾向于考虑其他可能性，例如您的团队中没有一个拥有最新的回购协议，并且可能正在将旧文件推出git。如果由谁来编译您的应用程序，则会拉入您和您的团队编辑过的所有文件，然后由该文件的编辑者使用另一个团队成员提交的过时设置文件。那可能吗？我可能会更仔细地研究您的文件在团队之间的分配方式。如果您可以排除这一点……那么您的猜测确实和我的一样好。

 

[跳伞]

我希望帖子＃1上的代码是伪代码，而不是真实代码。我之所以这样说是因为，通常，只有在应用程序版本大于设置中的先前版本时，才应该升级。如果当前应用程序版本早于设置文件版本，则您只需中止（除非您的设置始终向后兼容）。

 

[扎菲德将军]

我希望帖子＃1上的代码是伪代码，而不是真实代码。我之所以这样说是因为，通常，只有在应用程序版本大于设置中的先前版本时，才应该升级。如果当前应用程序版本早于设置文件版本，则您只需中止（除非您的设置始终向后兼容）。

就是这样。我将当前版本保存在设置中，然后与当前版本进行比较。

 

[扎菲德将军]

我不这么认为。我刚刚做了一些挖掘工作，看来您的问题相当孤立。因此，我会更倾向于考虑其他可能性，例如您的团队中没有一个拥有最新的回购协议，并且可能正在将旧文件推出git。如果由谁来编译您的应用程序，则会拉入您和您的团队编辑过的所有文件，然后由该文件的编辑者使用另一个团队成员提交的过时设置文件。那可能吗？我可能会更仔细地研究您的文件在团队之间的分配方式。如果您可以排除这一点……那么您的猜测确实和我的一样好。

我之前应该提到过这一点，但是这种情况仅在从VS更改并运行时发生。每当我做一点导致版本更改的更改时，甚至只是在本地更改，我都会看到这种情况大部分发生。而且它绝对是旧的设置文件。我注意到，该应用似乎为您保存了旧版本，但我没有挖掘出它的工作原理。我只是确定这是我以前使用过但已更改的内容。这是最明显的，因为我保存了"last file path"对于经常更改的内容，因此当它不自动加载我使用过的最新内容时，这是非常明显的。我确信其他设置值也很简单地以我们使用它的方式与该旧版本匹配。

 

[跳伞]

您的AssemblyInfo.cs中是否有一个或多个星号，例如：

[assembly: AssemblyVersion("1.0.0.*")]

如果是这样，那么每次编译时，程序集版本都会更改。

 

[扎菲德将军]

您的AssemblyInfo.cs中是否有一个或多个星号，例如：

[assembly: AssemblyVersion("1.0.0.*")]

如果是这样，那么每次编译时，程序集版本都会更改。
[/引用]

再次嗨，谢谢。是的，这是完全正确的，根据对主题的所有搜索，我的理解是在程序集更改时升级设置。此代码手动检查版本以进行更改。我同意删除。*可以防止在进行本地构建时出现这种情况，但是在发布时，我们会修订程序集中的其他3个（共4个）数字，这似乎会引起相同的问题。由于我们实际上没有可更改第4个*的构建服务器（就像您将构建号一样），因此它确实变得一文不值。对于我的用户，因为我总是修订程序集版本，所以他们总是在发布的代码中遇到这种情况，这大概是.Upgrade本身的结果。您是否还说最终用户从1.2.3（即第4位）升级到1.2.4（执行升级）是否值得，因为没有第4位值？我会尝试的，因为绝对值得一试。再次感谢。

 

[羊皮]

您是否还说最终用户从1.2.3（即第4位）升级到1.2.4（执行升级）是否值得，因为没有第4位值？我会尝试的，因为绝对值得一试。

我不认为他是在说。但是您只能在以下情况下更新应用程序： 不是 修订或新版本。您有四个代表版本构建的数字。如果您具有1.3.4.6版本
---- 1 =专业----
---- 3 =次要----
---- 4 =构建----
---- 6 =修订版----
因此，如果您进行了修订编辑并进行了某些编辑，则修订号将增加。您应该控制自己的应用程序更新程序，并且如果可以控制应用程序更新的时间，则可以告诉它如果只是版本更改或新版本，则不要升级。我要告诉您的是检查哪个数字相对于当前（旧应用程序）版本有所增加。我不知道您的更新程序如何工作或如何配置您的设置，但是如果您像我使用的那样构建了自定义更新程序，那么最好管理何时进行升级或忽略升级。向我们详细介绍您的更新过程可能会有所帮助。

 

[扎菲德将军]

我不认为他是在说。但是您只能在以下情况下更新应用程序： 不是 修订或新版本。您有四个代表版本构建的数字。如果您具有1.3.4.6版本
---- 1 =专业----
---- 3 =次要----
---- 4 =构建----
---- 6 =修订版----
因此，如果您进行了修订编辑并进行了某些编辑，则修订号将增加。您应该控制自己的应用程序更新程序，并且如果可以控制应用程序更新的时间，则可以告诉它如果只是版本更改或新版本，则不要升级。我要告诉您的是检查哪个数字相对于当前（旧应用程序）版本有所增加。我不知道您的更新程序如何工作或如何配置您的设置，但是如果您像我使用的那样构建了自定义更新程序，那么最好管理何时进行升级或忽略升级。向我们详细介绍您的更新过程可能会有所帮助。

非常感谢您的回复。有趣的是，我完全删除了*。除了确定之外，它真的没有实现任何良好的目的"in-between"建立与我们无关的东西。结果：太糟糕了……我的手指交叉了，问题不再存在了。我还要补充一点，我怀疑您的建议可能也可行，但是我也对此表示怀疑。版本号似乎是随机的（看起来像16位范围值）。我怀疑在对随机值进行升级时，它会找到修订号最大的版本并进行升级。这可以解释我所看到的，但也可以解释为什么它不再这样做了。您会认为这是基于日期的，知道此值是随机的吗？

 

[跳伞]

在版本号中使用通配符时，遇到两种情况。

The first problem is that you were always calling Upgrade() whenever the version is different from the previous version. You really should only be upgrading if the current assembly version is greater than the previously saved version.

第二个问题可能是您的星号仅在版本的“修订”部分，而不是在“构建”部分。基本上，如果您或您的其他同事在多天内都在处理您的私有版本，则修订部分将翻转。来自 文件资料，这是更新版本号的这些部分的规则：

版本号，例如[assembly：AssemblyVersion（"1.2.*")] specifies 1 as the major version, 2 as the minor version, and accepts the default build and revision numbers. 版本号，例如[assembly：AssemblyVersion（"1.2.15.*"）]指定1为主要版本，2为次要版本，15为内部版本号，并接受默认修订版本号。默认内部版本号每天递增。默认修订版号是自当地时间午夜以来的秒数（不考虑夏令时的时区调整）除以2。

我希望您实际上有一个构建服务器，并且该构建服务器是创建测试人员和客户所获得的正式发行版本的服务器。如果要从私有开发机器中发布发行版本，则必须成熟您的开发流程。

我强烈推荐 MSBuild扩展包，并使用其 AssemblyInfo 任务以自动增加构建服务器上的版本号。对于开发机器，您可以在Build字段中使用星号，以使Build number和Revision字段相对唯一，但同时始终在增加。