4

我有一个解决方案,包括了多个项目,包括:更新.NET项目引用(在配置文件中)

Foo.Bar.Client
Foo.Common

Foo.Bar.Client取决于组件Foo.Common。而且,Foo.Common没有自己的配置文件;它的设置存储在使用它的客户端应用程序的配置文件中,在本例中为Foo.Bar.Client
因此,Foo.Bar.Client配置文件包含

<configSections> 
    <section name="BletchConfiguration" 
      type="Foo.Common.Bletch, Version=1.1.0.0, ..."/> 
    .... 
    </configSections> 

我一直在负责调整我们的版本编号,使“修订”部分对应于最新的更改集(在我们的情况下,最新版本号,因为我们正在使用Subversion),例如从“1.1.0.0”到“1.1.0.12345”。

所以我实现了一个“shared”assembly-version-info模块,如here所述。而且我修改了我们的NAnt构建脚本以获取版本号并更新共享的assembly-info文件。

但是,我没有指望版本号被嵌入到配置文件中。是否有一种(相对)无痛的方式来自动更新配置文件中的版本号?

显然,我可以将“普通”程序集分解为单独的解决方案。
我也可以使用IoC配置通用组件,这将消除对特定于组件的配置节的需求。
然而,这些方法都涉及一些风险和时间......我相信这两种方法如果可能(至少现在)宁愿避免。

回答

2

快速回答 - 除非您在应用程序中支持多个同时版本的Foo.Common.dll,否则我会忽略配置部分中的版本号。

<configSections> 
    <section name="BletchConfiguration" 
     type="Foo.Common.Bletch, Foo.Common"/> 
    .... 
</configSections> 

这不是特殊的配置文件结构的“部分”区域 - 这是一种内在的东西。NET - 和一个用约定全部结束。

[编辑]

我无法找到具体涉及这部分是可选的任何文档。 MSDN文档只是指出结构http://msdn.microsoft.com/en-us/library/ms228245.aspx 然而,从内存和一个小实验......(这是相当灵活的 - 方括号表示可选)

如果你的DLL是在GAC - 你需要的版本... FullTypeAndNamespace, AssemblyNameWithoutExtension, Version, Culture, PublicKeyToken [,PlatformType]

如果你的DLL是在bin目录 FullTypeAndNamespace, AssemblyNameWithoutExtension [,Version, Culture, PublicKeyToken] [,PlatformType]

因此,前两个部分是强制性的,因为应用程序需要知道看什么组件,该类型已指定。

您可以以任意顺序拥有可选组件(因为它们被构造为键=值对,顺序无关紧要)。只需指定要约束的元素,省略其余元素。

因此,在我给出的示例中,CLR将加载与名称匹配的第一个DLL,并包含所需的类型。

+0

您将无法指点我一些文件,你会吗?我一直在思考(和搜索)这些方面,但是我还没有找到任何东西来表明'type'的哪些部分可以省略,什么时候可以省略。 – David

+0

我已经更新了我的答案以解决您的问题。 – Adam

1

我不会经常旋转我的AssemblyVersion。你应该为每个版本制作AssemblyFileVersion(所以你可以将它们区分开来),但是对于每个版本来说,AssetsVersion是相当有问题的。

What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?

编辑:我确实有更新的AssemblyVersion,我运行一个PowerShell脚本,发现需要修改的文件,检查出来,并让改变。我在验证文件的子集后手动提交更改。

这里是更新实际的AssemblyVersion脚本:

get-childitem . -rec -include AssemblyInfo.cs | select-string "assembly: AssemblyVersion(" -simplematch -list | % { & p4 sync $_.path; & p4 edit $_.path; (get-content $_.Path) |% { $_ -replace "assembly: AssemblyVersion\(`"\d\.\d\.\d\.\d", "assembly: AssemblyVersion(`"2.0.0.0" } | set-content $_.Path -Encoding UTF8 } 

这里是一个更新的项目参考从1.5.0.0 2.0.0.0到:

get-childitem . -rec -include *.csproj | select-string "<Reference Include=`"Acme.SomeProduct," -simplematch -list | % { & p4 sync $_.path; & p4 edit $_.path; (get-content $_.Path) |% { $_ -replace "<Reference Include=`"Acme\.SomeProduct, Version=1\.5\.0\.0,", "<Reference Include=`"Acme.SomeProduct, Version=2.0.0.0," } | set-content $_.Path -Encoding UTF8 } 
+0

我也同意这一点。我们修改每个版本的文件版本,并且只在发布时更改组件标识。但是 - 不管你多久改变一次 - 如果你的配置中有版本号 - 它可能会在某个时刻出现你。 Suzanne Cooke建议您在开始开发之前更改程序集版本(http://blogs.msdn.com/b/suzcook/archive/2003/05/29/when-to-change-file-assembly -versions.aspx),而不是仅在发布之前 - 出于很好的理由 - 更改程序集标识会影响应用程序的行为。 – Adam

+0

这很有道理。不幸的是,某些'.config'引用正在被传递到一个(较旧的)企业库块,该库需要一个由四部分组成的组件版本号,即major.minor.build.revision。 – David

+0

@Russell - 感谢您的回复......我很难挑选“接受”答案。我敬畏你的PowerShell-fu。 – David