ClickOnce 部署概述

转MSDN http://msdn.microsoft.com/zh-cn/library/142dbbz4(VS.80).aspx

ClickOnce 是一种部署技术，使用该技术可创建自行更新的基于 Windows 的应用程序，这些应用程序可以通过最低程度的用户交互来安装和运行。ClickOnce 部署克服了部署中所固有的三个主要问题：

• 更新应用程序的困难。 使用 Microsoft Windows Installer 部署，每次应用程序更新，用户都必须重新安装整个应用程序；使用 ClickOnce 部署，则可以自动提供更新。只有更改过的应用程序部分才会被下载，然后从新的并行文件夹重新安装完整的、更新后的应用程序。

• 对用户的计算机的影响。 使用 Windows Installer 部署时，应用程序通常依赖于共享组件，这便有可能发生版本冲突；而使用 ClickOnce 部署时，每个应用程序都是独立的，不会干扰其他应用程序。

• 安全权限。 Windows Installer 部署要求管理员权限并且只允许受限制的用户安装；而 ClickOnce 部署允许非管理用户安装应用程序并仅授予应用程序所需要的那些代码访问安全权限。

过去，这些问题有时会使开发人员决定创建 Web 应用程序而不是基于 Windows 的应用程序，为便于安装而牺牲了 Windows 窗体丰富的用户界面和响应性。对于使用 ClickOnce 部署的应用程序，您可以集这两种技术的优势于一身。

什么是 ClickOnce 应用程序？

ClickOnce 部署的工作方式

核心 ClickOnce 部署结构基于两个 XML 清单文件：一个应用程序清单和一个部署清单。

应 用程序清单描述应用程序本身，包括程序集、组成应用程序的依赖项和文件、所需的权限以及提供更新的位置。应用程序开发人员使用 Visual Studio 2005 中的发布向导或 .NET Framework SDK 中的清单生成工具 (Mage.exe) 来创作应用程序清单。有关更多信息，请参见如何：发布 ClickOnce 应用程序。

部署清单描述如何部署应用程序，包括应用程序清单的位置以及客户端应运行的应用程序的版本。管理员使用 .NET Framework SDK 中的清单生成工具 (Mage.exe) 来创作部署清单。

注意
Microsoft Visual Studio 2005 中的“发布向导”也可生成部署清单。

部 署清单在创建后会被复制到部署位置。部署位置可以是 Web 服务器、网络文件共享或媒体（如 CD）。应用程序清单和所有应用程序文件也都被复制到在部署清单中指定的一个部署位置。此位置可以与部署清单的部署位置相同，也可以不同。使用 Microsoft Visual Studio 2005 中的“发布向导”时，复制操作是自动执行的。

注意
如果开发人员同时也是管理员（即开发人员在将要部署部署清单的网站或文件共享位置具有管理员特权），则只需要此清单即可。如果开发人员不是管理员，则必须由管理员使用命令行工具更新清单并对清单进行签名。

当 部署清单被部署到部署位置后，最终用户可以在网页上或文件夹中单击表示部署清单文件的图标，从而下载和安装应用程序。在大多数情况下，会向最终用户提供一 个简单的对话框以请用户确认安装，在此之后便不需要进一步的用户干预，安装会继续执行且应用程序会被启动。在应用程序要求提升的权限的情况下，该对话框还 会请用户在安装继续进行之前授予相应权限。

应用程序会被添加到用户的“开始”菜单和“控制面板”中的“添加/删除程序”组中。与其他部署技术不同，此部署技术不会向“Program Files”文件夹、注册表和桌面添加任何内容，且安装无需任何管理员权限

注意
也可以禁止将应用程序添加到“开始”菜单和“添加/删除程序”组中，其效果是使应用程序的行为与 Web 应用程序相类似。有关更多信息，请参见选择 ClickOnce 部署策略。

当应用程序开发人员创建更新版本的应用程序时，开发人员也会生成新的应用程序清单，并将文件复制到一个部署位置 -- 通常是原始应用程序部署文件夹的同级文件夹。管理员会更新部署清单，使之指向新版本的应用程序所在的位置。

注意
可以使用 Microsoft Visual Studio 2005 中的“发布向导”执行这些步骤。

除 部署位置外，部署清单还包含应用程序在其中检查更新版本的更新位置（一个网页或网络文件共享）。ClickOnce 的“Publish”属性用于指定应用程序检查更新的时间和频率。更新行为可以在部署清单中指定，也可以通过 ClickOnce API 在应用程序的用户界面中以用户选项的形式提供。此外，“Publish”属性还可以用于将更新设置为强制性的，或是用于将应用程序回滚到较早版本。有关更 多信息，请参见选择 ClickOnce 更新策略。

ClickOnce 和 Windows Installer 比较表

下表将 ClickOnce 部署的功能与 Windows Installer 部署的功能进行了比较：

说明

1. 对于 Windows Installer，必须在应用程序代码中实现编程方式的更新。

2. 对于 ClickOnce，可在“添加/删除程序”中实现回滚。

3. ClickOnce 部署只有使用“完全信任”权限才能访问 HKEY_LOCAL_MACHINE (HKLM)。

就这几个状态而言，明眼人一看就清楚一个bug从发现到排除要走哪些流程：
1、测试人员发现bug，提交。bug状态为New&Acitve
2、开发人员接收bug。bug状态为in progress
3、开发人员修改完毕并提交。bug状态为Fixed
4、测试人员针对开发人员的解决方案再次对bug进行验证测试。如果bug依然存在，则把bug状态设置为reopened，流程返回至第二步。如果问题已经解决，就直接设置为close。
经过以上四个步骤，整个bug的流程就基本走完了。

看似流程非常简，可是在实际使用中还是会发现一些问题：
1、bug信息不全。
      有的信息如项目，模块，指定处理人等。依据这些信息会用来作统计分析，哪个项目，哪个模块，谁的bug多，谁发现的bug多，谁改的bug多等等，则可以大致看出一个人的工作量和工作质量。所以测试人员在填写bug问题单时，不要嫌麻烦。应该把涉及bug相关的信息完全写出来。
2、提供的信息不准确。
      有的bug描述一带而过，表述含糊不清。只是说出了错误并没有清楚的描述错误的现象是什么，提示信息是什么，怎么操作才可以出现等。这样的bug交给开发人员，只会给开发人员增加负担。因为当开发人员拿到bug后，发现不明之处还需要再做测试才可发现更多的信息去解决bug。或者与相关测试人员讨论并询问详情，有时要多次在反馈信息当中才能明确bug的目的。这无疑造成了研发周期的无限延长。
3、开发人员关闭bug
     只有bug的提交人（也就是发现人）才能关闭bug，开发人员只能使用两种状态，即“处理中”和“已修正”。
4、bug的重要性
     这个重要性是在bug管理软件中无法体现和度量的，这个任务主要体现在测试这边。如果当测试人员发现了一个bug，及时与开发人员沟通时无法重现bug，此时连测试人员都不知道这个bug是怎样操作才出现的。对于这样不能重现的bug几乎就不能算是bug，也是最让人头疼的问题。那么作为测试人员，其任务就是要尽可能的找出bug出现的规律。尝试各种可能，即使不能重现也起码要让开发人员知道测试人员是怎么做的，而减少开发人员的再操作的时间。

BugTracker.net也是web方式的，而且开源，使用asp.net编写，是页面代码和script代码混合编写的方式，而不是常见的
.aspx文件-.cs文件的方式。提供常见的bug管理功能，有邮件订阅功能。而且运行速度也不错，尽管还有一些问题（主要在search的按日期查找，和报表的按用户分类上)，好在是开源的，可以自己很方便的修改，而且对于一个小型团队，它所提供的功能也已经够用了。同时提供了自定义查询和报表和打印功能，可以打印一个bug的详细信息和bug列表，报表提供饼图，条状图，线型图和列表等方式，我现在就自己定义了几个报表来显示各个模块的bug数，某个人修正的bug数，每个人发现的bug数，可以对测试人员和开发人员的工作量有一个统计（当然并不能完全反映工作量），同时作扩展添加了测试用例模块，对系统原有的部分做了汉化。
 
这还是我头一次使用开源软件做实施维护工作，不由的感慨开源的优势，自己可以根据需要做修改，扩展。
 
下面说说在使用BugTracker.net前考虑的几个类似软件：
OnTimer：
有cs版和web版，是要收费的，不过用.net编写的东西似乎比较容易破解，我用Reflector看了看，很容易找到加密的地方。这个软件 比bugTracker.net要复杂些，权限等控制的更细，同时似乎并不仅限于bug跟踪，而倾向与缺陷管理。同时它使用了aspnetmenu等组件，和bugTracker.net相比速度要慢些。
BugZilla：
听说是很强大的工具，但是下下来一看，要用MySql，同时代码好象是Perl写的（.pm和.pl文件是用什么写的?)，怕怕，不用。
myTracker：
 使用InterBse数据库，也有cs和web两种方式，我下午才装上InterBase，准备明天看看，这个软件看样子也不仅限于bug跟踪，还有其他的功能，帮助比较全，等用起来再说。
Mantis：
基于PHP和MySql，现在正在使用中不过不是免费的，用起来还是很方便的。 
 
总的来说，BugTracker.net虽然有很多缺陷，但是对与一个小团队来说，简单实用是最大的优点，同时也易于维护，扩展。

            string vReturnDate = vCurrentDate.ToString(pFormat, DateTimeFormatInfo.InvariantInfo);

            return vReturnDate;
        }
//西历转和历
private string DateTimeTransform(string pDate, string pFormat)
        {
            CultureInfo vCurrentInfo = new CultureInfo("ja-JP", true);
            vCurrentInfo.DateTimeFormat.Calendar = new JapaneseCalendar();
            DateTime vCurrentDate = Convert.ToDateTime(pDate);

简介

更多信息