小编Jar*_*red的帖子

是否可以为在VS2005中生成的Web部署安装程序创建补丁安装程序？

我的情况是,不希望执行完全卸载/重新安装的网站,但是定期修复错误并进行小的升级.

我已尝试按照各种在线帖子中有关使用msimsp.exe生成补丁文件的说明,但大部分/全部都依赖msiexec.exe的一些用法来创建用于比较的管理安装,因为msimsp.exe可以' t处理压缩内容(例如CAB文件).但是,Web安装实际上没有管理安装,最终修补程序创建失败.

当然,我可以手动创建一个仅包含已更改文件的安装程序,但这很容易出错,并且更需要自动化过程.

任何帮助表示赞赏.

我需要在同一个虚拟文件夹中安装多个Web安装项目(使用VS2005和ASP.Net/C#).这些项目共享一些程序集引用(文件系统都被构造为使用相同的"bin"文件夹),因此部署对这些程序集的更改会出现问题,因为如果当前安装的版本比以前安装的版本旧,则MS安装程序将仅覆盖程序集. MSI.

我并不是说悲观的安装方案是错误的 - 只是它在我给予的环境中产生了问题.由于有相当数量的通用程序集和大量开发人员可能会更改通用程序集但忘记更新其版本号,因此尝试手动管理版本控制最终会导致安装时出现大量混淆.

在这个问题的另一面,同样重要的是不要自发更新版本号并在每次安装时替换所有通用程序集,因为这可能(暂时至少)模糊实际更改的情况.

也就是说,我正在寻找的是只有在程序集成分(代码模块,资源等)实际已经发生变化的情况下才更新程序集版本信息(最好使用MSBuild)的方法.

我已经发现了一些引用是至少部分相关这里(MSDN上的AssemblyInfo任务)和这里(类似于我所需要的,但两年多岁,没有一个明确的解决方案).

我的团队也使用TFS版本控制,因此自动化解决方案应该包括在构建期间可以检出/输入AssebmlyInfo的方法.

任何帮助将非常感激.

提前致谢.

这是我多年来在多个地方看到的情景; 我想知道是否有其他人遇到过比我更好的解决方案......

我公司销售的产品数量相对较少,但我们销售的产品是高度专业化的(即为了选择给定的产品,必须提供大量的细节).问题在于,虽然选择给定产品所需的细节数量相对恒定,但所需的细节类型在不同产品之间差异很大.例如:

产品X可能具有识别特征,如(假设)

• '颜色',
• '材料'
• '平均失败时间'

但是产品Y可能具有特征

• '厚度',
• '直径'
• '能量源'

在创建同时使用产品X和产品Y的订单系统时,问题(其中之一,无论如何)是订单行必须在某个时候引用它"销售"的内容.由于产品X和产品Y在两个不同的表中定义 - 并且使用宽表格方案的产品非规范化不是一种选择(产品定义非常深) - 很难看到在这样的定义订单行的明确方法订单输入,编辑和报告的实用方式.

我过去曾经尝试过的事情

• 创建一个名为"Product"的父表,其中包含Product X和Product Y的通用列,然后使用"Product"作为OrderLine表的引用,并创建一个FK关系,将"Product"作为Product X表之间的主要副本和产品Y.这基本上将'Product'表作为OrderLine和所有不同产品表(例如Products X和Y)的父级.它适用于订单输入,但会导致订单报告或编辑出现问题,因为"产品"记录必须跟踪它是什么类型的产品,以确定如何将"产品"加入其更详细的子产品,产品X或产品Y. 优点:保持关键关系. 缺点:在订单行/产品级别进行报告,编辑.
• 在订单行级别创建"产品类型"和"产品密钥"列,然后使用一些CASE逻辑或视图来确定该行所引用的自定义产品.这类似于第(1)项,没有通用的"产品"表.我认为这是一个更"快速和肮脏"的解决方案,因为它完全取消了订单行和产品定义之间的外键.优点:快速解决方案. 缺点:与第(1)项相同,加上丢失的RI.
• 通过创建公共标头表并为自定义属性使用键/值对来均匀化产品定义(OrderLine [n] < - [1] Product [1] < - [n] ProductAttribute). 优点:保持关键关系; 没有关于产品定义的含糊不清. 缺点:报告(例如,检索具有其属性的产品列表),属性值的数据类型,性能(获取产品属性,插入或更新产品属性等)

如果其他人尝试了更多成功的不同策略,我肯定希望听到它.

谢谢.