小编Spi*_*lis的帖子

• 我正在使用Enterprise Library记录消息.
• 我想将其中一些(通常是错误和警告)传递给Windows事件系统.我今天通过entlib.config路由这些.

这个解决方案有效,到目前为止,非常好.但是,我有更多的需求,而不是这个解决方案为我提供的.我有多个应该登录到不同日志的安装,但我希望它们的名称在事件查看器中是合乎逻辑且直观的.但是,Windows事件系统不能有两个类别,其中名称中的前8个字符相同.类别名称可以更长,但只有前8个字母用于区分它们.如果发生这种情况,.Net实际上会输出警告:

只有自定义日志名称的前八个字符才有意义,并且系统上已经有另一个日志使用给定名称的前八个字符.

目前我不得不求助于密码前缀,但是我仍然面临着多次安装在regrads中相互"碰撞"到logname的危险,所以我需要一个更好的解决方案.

但是,在我的计算机上的事件查看器中,我可以看到还有层次结构的日志名称 - 这正是我需要的.微软和思科显然都找到了这样做的方法:

但是,如何为日志记录创建这样的层次结构,每个应用程序可能安装多次？像这样:

CompanyName
  ApplicationName
    Installation1
    Installation2

我们希望使用NuGet在我们组织的开发人员之间共享程序集.我们目前正在设置三个NuGet源,如下所示:

• 释放进给:组件的稳定版本质量版本.
• QA-feed:在master-branch(我们的集成分支)中构建的程序集.
• 开发Feed:在任何功能分支中构建的程序集(共享进度).

不应将开发人员机器上的本地构建发送到任何这些源.只有构建服务器完成的构建才能执行这些操作.我们的构建服务器执行三种不同类型的构建,具体取决于分支,Development,QA和Release分支.其中每个都具有相应的构建配置,可在源更改时触发.在构建时,每个构建器都会将构建的组件 - nuget-packages推送到相应的feed.Development-builds将在版本中添加"-dev".QA版本将为版本添加"-qa",而版本版本将具有"纯"版本号.

现在,问题:

1. 什么是开发人员控制使用什么包的最佳解决方案？我想dev手动必须编辑依赖源param以显式定义从哪个feed获取程序集:有时你想要发布程序集,有时你需要QA程序集,有时你甚至想要最前沿的开发版本.

2. 我们还在考虑将本地构建包推送到每个开发者自己的机器上的本地私有源,以帮助加速构建.就哪些饲料来说,这会有问题吗？

3. 如果这些定义是由依赖项文件中的dev(也必须是版本控制的)创建的,那么当源被提交到repo时,该设置将被带入Development feed(与开发人员相同的构建焦点,只是与他人分享).这可能是也可能不是开发Feed的正确之处？

4. 当源被合并到qa-branch时,依赖关系中定义的提要仍然与开发者一样,可能从Development feed获取程序集.对于QA版本,我认为这可能不是我们想要的.QA版本应该仅限制发布程序集的订阅源,因为您希望查看更改是否按照发行版组件的预期工作.您不希望使用其他"未经测试"的QA程序集对其进行测试.这对其他人也有意义吗？

5. 在发布分支中,发布版本应该只使用发布供稿程序集,我想？我有一种感觉,可能会就此达成共识,所以也许根本不是一个问题:).

因此,总结一下建议的过程......在构建期间,我们将:

• 在本地和开发版本的依赖关系规范中遵循开发人员设置的源.
• 在执行QA和发布版本时,Feed应限制为Release Feed.

作为旁注,QA订阅源实际上不会被任何其他版本使用.但是,质量保证部门将使用它们,因为他们将使用这些进行测试.

我们开始使用NuGet,我们遇到了一些问题:

首先是一些NuGet事实:

(只是为了确保我们了解NuGet的工作原理)

• 在添加,更新或删除包时,会创建并更新packages.config(位于project-root中).在此文件中,包版本属性反映了正在使用的完整版本,因此在这个意义上它也是一个状态.可以将allowedVersions属性添加到包规范中,这是对可以更新的版本的限制.要使程序包还原起作用,此文件需要受源代码管理.

• packages文件夹位于solution-root中,并在子文件夹中包含下载版本的依赖包,其名称与包名称(包括版本)相匹配,以允许多个中的不同项目使用同一包的多个版本 - 项目解决方案.建议不要将它们作为二进制文件来源控制,并且包恢复可以在需要时重新创建它们.更新包时,将使用其中的包创建与更新匹配的新文件夹.

• 项目文件包含对packages文件夹中的包的引用,以使构建工作,并且visual studio也能够提供自动完成,智能感知等.更新包时,项目文件中的引用将更新以匹配packages文件夹中包的新位置.

问题:

1. 由于packages.config文件包条目包含完整的版本信息,因此我们经常需要更新源控件存储库.或者,我们可以在大多数情况下忽略这些更改,但是当版本发生变化时,我们(在大多数情况下)会忽略它们.这似乎是非常不必要的,因为NuGet恢复应该能够知道允许哪些版本(通过allowedVersions).

2. 必须手动添加allowedVersions属性,这很容易被遗忘.我们正在使用语义版本控制,因此对于我们来说,在安装即Foo-1.1.0版本时,应隐含allowedVersions ="[1,2]".

3. 当添加allowedVersion时,NuGet包恢复似乎无法找到-prerelease程序集(可能是一个错误？).

4. 为什么NuGet在解决方案级别处理包？如果您正在使用包含项目A(repo-1)和项目B(repo-2)的混合搭配解决方案,那么解决方案级别的打包将无法正常运行.也就是说,如果您将该解决方案文件保存在一个单独的位置,那么事情可能仍然有效.但是,如果你然后设置另一个包含项目-A(repo-1)和项目-C(repo-3)的解决方案,那么项目-A将突然再次需要一个包恢复,更糟糕的是,项目引用将是更改为匹配上次更改.回到第一个解决方案将有参考不起作用.检查这些肯定会使它们不适合其他人.

5. 在程序包更新中,更新项目文件引用(以匹配其中包含versionid的新foldernames),并将显示为未提交的更改.承诺这一变化似乎是常态,但我们认为这不是必要的.

关于ExcludeVersion的注释(可以建议作为上述问题的解决方案:

• 您只能在手动执行NuGet命令时提供该选项.通过Visual Studio中的NuGet菜单安装/更新软件包时,无法使用该选项.使用任何自动化工具意味着必须手动修复foldername和项目引用.

• 我们知道ExcludeVersion不是默认设置,可能是因为支持某人在多项目解决方案中工作的情况,其中不同的项目依赖于同一个包的不同版本.

可能的解决方案？

(但是,这可能需要NuGet生态系统的重大变化？)

A - packages.config

我希望packages.config中的每个package元素都可以抛弃allowedVersions,而是将version更改为范围说明符.packages元素还应提供一种单独标识从哪个源获取更新的方法.最后,如果安装的软件包遵循语义版本控制,则版本属性应根据安装的版本自动设置版本范围.

示例packages.config:

`<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Foo" version="[1,2] source="Development Feed">
</packages>`

这个会:

• 修复了package.config文件过多提交的问题,因为版本属性不再经常更新.

• 无需记住为语义版本的项目设置范围.

• 确保从所需的源中获取包,并且通过在错误的源中查找它而不浪费时间.

B - Packages文件夹和其中已安装软件包的名称

我希望packages文件夹位于每个项目根目录中,并且子文件夹名称仅限于包名称,不包括版本.这个会:

• 修复了项目文件过多提交的问题,因为项目文件中的项目引用现在指向更新后的同一个包文件夹.

• 允许项目使用相同包的不同版本,因为它们真正相互独立.

我们很高兴听到所列问题的解决方案.

我想在我使用带有MUI2的NSIS创建的安装程序的欢迎屏幕中添加一个显示完整版本字符串的标签.

我已经搜索了有关如何执行此操作的信息,但只找到了使用MUI_INSTALLOPTIONS*的引用,我发现它已被弃用于MUI2.另一个提到使用INSTALLOPTIONS*的新版本具有相同的选项,但我无法使其正常工作.我最后还找到了使用nsDialogs的参考 - 这就是我用于自定义页面的内容.但是 - 我没有找到关于如何更改MUI2.nsh附带的任何现有页面的参考或示例.

我找到了一种更改MUI_HEADERTEXT的方法,但这不会影响欢迎屏幕.我希望有一种方法可以改变欢迎文本.也许使用MUI_WELCOMETITLE和MUI_WELCOMEBODY或类似的.

我想创建和分发一个NuGet包,当安装时只安装解决方案范围的root packages-folder,引用.NuGet\packages.config文件中的包.

我已经找到了关于这个主题的NuGet包格式的一些信息,根据NuGet FAQ,如果遵循这些指导原则,这应该是可能的:

项目级包和解决方案级包之间有什么区别？

解决方案级别的软件包只能在解决方案中安装一次,以便解决方案中的所有项目都可用.必须在要使用它的每个项目中单独安装项目级包.对于解决方案级别的包,NuGet不会更改项目中的任何内容,而在项目级别的包中则会更改.通常,解决方案级别的软件包会安装可在"软件包管理器控制台"窗口中调用的新命令.

另一个建议的SO解决方案表明上述应该也有效.

事情是,我无法让它工作.我已经验证我的包没有lib或内容目录:

我已将所有文件分发tools到包中的-folder中,包括在安装时运行的init.ps1`脚本.

我正在使用Visual Studio 2015,当我想安装包时:

1. 我首先必须选择要安装的项目.我曾经期望不必指定它,因为它应该是解决方案范围的.:/
2. 该init.ps1脚本确实运行并执行我希望它们执行的命令.:)
3. 但是,packages在项目中创建了一个文件夹,我被迫选择完成安装.我packages原本希望在解决方案根目录中创建-folder.:(
4. 此外,packages.config文件是在项目文件夹中创建的,而不是在.NuGet\packages.config我阅读我在此发现的文档后所期望的.:(

有关如何使这项工作的任何建议？这是VS 2015限制还是NuGet 3的变化(我认为它包含在VS2015中)？