nuget 构建自己的包_适用于企业的NuGet:持续集成自动构建系统中的NuGet

nuget 构建自己的包

nuget 构建自己的包

I had the pleasure of speaking at TechEd 2011 North America last week in Atlanta. You can see ALL the videos of all the sessions on Channel 9. As an aside, you might notice that they are in the process of organizing video archives of ALL Microsoft developer events at http://channel9.msdn.com/Events. You can even see PDC 1999 if you like or see sessions by Speaker at http://channel9.msdn.com/Events/Speakers. Here are all my talks with a horrible headshot that I plan on asking Duncan to swap out ASAP.

上周,我很高兴在亚特兰大举行的TechEd 2011北美会议上发言。 您可以在Channel 9上观看所有会议的所有视频。 顺便说一句,您可能会注意到它们正在组织所有Microsoft开发人员事件的视频存档,网址http://channel9.msdn.com/Events 。 如果愿意,您甚至可以查看PDC 1999,或者在http://channel9.msdn.com/Events/Speakers上查看议长的会议。 这是我打算让邓肯尽快换掉的所有爆料演讲

My favorite talk was NuGet: Microsoft .NET Package Management for the Enterprise. I talked about NuGet, like I did in The Netherlands a few weeks ago, except the TechEd talk was focused much more on how NuGet fits into the software development lifecycle in a diverse Enterprise (or big boring company, if you prefer) environment.

我最喜欢的话题是NuGet:企业版Microsoft .NET软件包管理。 我谈论了NuGet,就像几周前在荷兰一样,只是TechEd的演讲更加关注NuGet如何适应多样化的Enterprise(或大型无聊的公司,如果您愿意)环境中的软件开发生命周期。

Here's the video downloads, or you can click the slide at the right.

这是视频下载,或者您可以单击右侧的幻灯片。

At my last company, we used Subversion for source control and CruiseControl for Continuous Integration (CI). I thought it'd be nice to setup a similar system using the latest free (and mostly free) tools. Note, you can do all this with TFS as well for both Source and Build. I'll do a post on that later. For now, I give you:

在我的上一家公司,我们使用Subversion进行源代码控制,使用Cruise Cruise进行持续集成(CI)。 我认为最好使用最新的免费(且大多是免费)工具来建立类似的系统。 注意,您也可以使用TFS对Source和Build进行所有这些操作。 稍后我会发表一篇文章。 现在,我给你:

设置NuGet以使用Mercurial进行源代码管理并使用JetBrains TeamCity进行持续集成,同时推送到本地Orchard NuGet Gallery Server (Setting up NuGet to build using Mercurial for Source Control and JetBrains TeamCity for Continuous Integration while pushing to a local Orchard NuGet Gallery Server)

Oh yes, that's a long H3 right there but it's descriptive, right? Here's the general idea.

哦,是的,那是一个很长的H3,但这是描述性的,对吗? 这是一般的想法。

This of course, is not unique to NuGet, as NuGet is just a build artifact. At my last company we had several things that popped out of the build. Not just the DLLs, but also a ZIP file, MSI installer and even a complete configured and prepped Virtual Machine for sales people to pick up and give demos with our latest bits. You can setup your Continuous Integration system to be as awesome or as simple as you like. You should be thinking about which libraries and parts will create NuGet packages.

当然,这不是NuGet独有的,因为NuGet只是一个构建工件。 在我上一家公司,我们从构建中弹出了几件事。 不仅是DLL,还有ZIP文件,MSI安装程序,甚至是完整的配置和准备好的虚拟机,供销售人员使用,并提供我们最新的演示。 您可以将Continuous Integration系统设置为您喜欢的真棒或简单。 您应该考虑哪些库和部件将创建NuGet包。

Another thing to think about is daily (or every build) packages vs. stable or release packages. There are some discussions on the NuGet site around a "-beta" switch and baked-in support for understanding stable vs. volatile builds. For now, consider two locations for your builds, one for each build and one for "blessed." For some, this might mean a folder for dailies and only blessed go to a server.

要考虑的另一件事是每日(或每个构建)软件包与稳定或发行软件包。 在NuGet网站上,围绕“ -beta”开关和对理解稳定版本与易失版本的内置支持进行了一些讨论。 现在,为您的构建考虑两个位置,每个构建一个位置,一个“有福”位置。 对于某些人来说,这可能意味着一个日用文件夹,只有祝福的文件夹才能进入服务器。

Here's the demo I did. You can change what you like and swap out for your favorite tools. I'll point out some gotchas and issues that hit me and might hit you. It's not perfect, but we're moving in the right direction.

这是我做的演示。 您可以更改自己喜欢的东西,并换成您喜欢的工具。 我会指出一些困扰我并且可能困扰您的陷阱和问题。 这并不完美,但是我们正在朝着正确的方向发展。

步骤0-准备材料 (Step 0 - Prep Stuff)

Some of these steps are "make sure x is setup" type steps and can happen whenever, so don't take the ordering of the steps as totally crucial. Here's what I used and installed.

其中一些步骤是“确保设置了x”类型的步骤,并且随时可能发生,因此,不要将这些步骤的顺序视为至关重要。 这是我使用和安装的。

第1步-确保您的项目已生成,并且可以制作一个NuGet包(nupkg) (Step 1 - Make sure your project builds and you can make a NuGet package (nupkg))

I'm doing all this on one laptop, but you might have things spread out at your company. Do what makes you happy.

我要在一台笔记本电脑上完成所有这些工作,但是您可能会在公司中分散工作。 做些让您开心的事。

I made a trivial little class library called TechEdLibrary and confirmed it builds with MSBuild like this:

我制作了一个普通的小类库TechEdLibrary,并确认它是使用MSBuild构建的,如下所示:

C:\dev\techedlibrary\TechEdLibrary>msbuild TechEdLibrary.csproj
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.225]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 5/24/2011 4:52:54 PM.
..snip...
Done Building Project "C:\dev\techedlibrary\TechEdLibrary\TechEdLibrary.csproj"

Build succeeded.
0 Warning(s)
0 Error(s)

Time Elapsed 00:00:00.13

The most important part is to make sure that your AssemblyInfo.cs is actually filed out and not just the defaults. This is because we'll want to update the NuGet's specification file using the values from the DLL and project. Basically we want the metadata of the project to drive the NuGet package (or we have to update it all manually.)

最重要的部分是确保您的AssemblyInfo.cs实际上已归档,而不仅仅是默认值。 这是因为我们要使用DLL和项目中的值更新NuGet的规范文件。 基本上,我们希望项目的元数据来驱动NuGet包(或者我们必须手动更新它们)。

I need a spec file. I can do this a few ways. I can do it manually with just "nuget spec," I can build it off the resulting DLL with "nuget spec -assemblyPath bin\debug\techedlibrary.dll" or off the csproject with "nuget spec techedlibrary.csproj."

我需要一个规格文件。 我可以通过几种方法做到这一点。 我可以仅使用“ nuget spec”手动完成操作,也可以使用“ nuget spec -assemblyPath bin \ debug \ techedlibrary.dll”从生成的DLL中构建文件,也可以使用“ nuget spec techedlibrary.csproj”在csproject中构建文件。

If I create it off the csproj, the NuGet spec file will be created with some $tokens$ that will be filled out at packaging time:

如果我是通过csproj创建的,则将使用一些$ tokens $创建NuGet规范文件,该文件将在打包时填写:

C:\dev\techedlibrary\TechEdLibrary>nuget spec TechEdLibrary.csproj
Created 'TechEdLibrary.nuspec' successfully.

In the talk at TechEd I mistakenly build it off the DLL and ended up hard-coding the versions. In a continuous integration system you'll want to update the version in your spec as the build versions. You can either do it with tokens like I will in this post, or you can pass in the version (often from an environment variable) into the command line like "NuGet Pack -version 1.0.1.0."

在TechEd的一次演讲中,我错误地将其构建为DLL,并最终对版本进行了硬编码。 在持续集成系统中,您需要将规范中的版本更新为构建版本。 您可以像本文中将要使用的令牌那样来完成此操作,也可以将版本(通常是来自环境变量)传入命令行,例如“ NuGet Pack -version 1.0.1.0”。

You can also  use the UpdateVersion.exe that Matt Griffith and I updated SO many years ago to change your AssemblyInfo.cs, then the NuGet package can pick it up. Again, there is no right answer, the point is to have a strategy. What drives the version and how does NuGet find out about it?

您还可以使用Matt Griffith和我几年前进行了更新的UpdateVersion.exe来更改您的AssemblyInfo.cs,然后NuGet包可以将其拾取。 同样,没有正确的答案,关键是要有策略。 是什么驱动版本,NuGet如何找到它?

My TechEdLibrary.nuspec I just made looks like this:

我刚刚制作的TechEdLibrary.nuspec如下所示:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>$id$</id>
<version>$version$</version>
<authors>$author$</authors>
<owners>$author$</owners>
<iconUrl>http://www.hanselman.com/images/nugeticon.png
</iconUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>$description$</description>
</metadata>
</package>

And my AssemblyInfo.cs (abridged) is like this. The attributes from the DLL will get copied into the $tokens$ and packaged.

我的AssemblyInfo.cs(节略)就是这样。 来自DLL的属性将被复制到$ tokens $中并打包。

[assembly: AssemblyTitle("TechEdLibrary")]
[assembly: AssemblyDescription("This is my cool library")]
[assembly: AssemblyCompany("Scott Hanselman")]
[assembly: AssemblyProduct("TechEdLibrary")]
[assembly: AssemblyVersion("0.9.*")] //The * means I'll get an automatic version bump
//and more...

Now I can pack it up with NuGet Pack TechEdLibrary.csproj. Note the command line output find the spec and does the token/metadata replacement?

现在,我可以使用NuGet Pack TechEdLibrary.csproj打包它。 注意命令行输出找到规范,令牌/元数据是否替换?

C:\dev\techedlibrary\TechEdLibrary>nuget pack TechEdLibrary.csproj
Attempting to build package from 'TechEdLibrary.csproj'.
Building project for target framework '.NETFramework,Version=v4.0'.
Packing files from 'C:\dev\techedlibrary\TechEdLibrary\bin\Release'.
Using 'TechEdLibrary.nuspec' for metadata.
Successfully created package 'C:\dev\techedlibrary\TechEdLibrary\TechEdLibrary.0.9.4161.28882.nupkg'.

Now I can just open the .nupkg into the NuGet Package Explorer and see the version, author, ID (from Title) description and version are all there, brought in from the attributes and combined with my NuSpec. I can edit the NuSpec to taste as long as I maintain the $tokens$ I want.

现在,我可以在NuGet软件包浏览器中打开.nupkg,并查看版本,作者,ID(来自标题)的描述和版本,并从属性中引入并与我的NuSpec结合使用。 只要保持所需的$ tokens $,我就可以编辑NuSpec进行品尝。

Now if I build the library again I'll get a new version from the .NET build system and that will cause a new NuPkg to be built with a new version. I make a change to my application's source, build again, then pack again. Note the results in my directory after I make a small change, build and pack.

现在,如果我再次构建该库,我将从.NET构建系统中获得一个新版本,这将导致使用新版本构建新的NuPkg。 我对应用程序的源进行了更改,再次构建,然后再次打包。 进行少量更改,构建和打包后,请注意目录中的结果。

C:\dev\techedlibrary\TechEdLibrary>msbuild TechEdLibrary.csproj 
Microsoft (R) Build Engine Version 4.0.30319.1
Build started 5/24/2011 5:07:58 PM.
blah build blah
Done Building Project "C:\dev\techedlibrary\TechEdLibrary\TechEdLibrary.csproj" (rebuild target(s))

Build succeeded.
0 Warning(s)
0 Error(s)

Time Elapsed 00:00:00.32

C:\dev\techedlibrary\TechEdLibrary>nuget pack TechEdLibrary.csproj
Attempting to build package from 'TechEdLibrary.csproj'.
Building project for target framework '.NETFramework,Version=v4.0'.
Packing files from 'C:\dev\techedlibrary\TechEdLibrary\bin\Release'.
Using 'TechEdLibrary.nuspec' for metadata.
Successfully created package 'C:\dev\techedlibrary\TechEdLibrary\TechEdLibrary.0.9.4161.29041.nupkg'
.

C:\dev\techedlibrary\TechEdLibrary>dir *.nupkg

05/24/2011 05:07 PM 4,770 TechEdLibrary.0.9.4161.28882.nupkg
05/24/2011 05:08 PM 4,763 TechEdLibrary.0.9.4161.29041.nupkg
2 File(s) 9,533 bytes

Without settings really anything up but the versioning plan, spec file and checking if packing works, I've got a little system here and hopefully you can see how it'll work.

没有设置,除了版本计划,规范文件和检查打包是否有效以外,我什么都没有,我这里有一个小系统,希望您能看到它如何工作。

WEIRDNESS NOTE: We do have a double-build going on. NuGet.exe, for some weird reason, is running MSBuild again for us. That's lame, and a known bug. Surprisingly in a large number of CI systems in both the .NET and Java worlds "double builds" are common. Weaksauce, but common. Still, no excuse. That'll be fixed in NuGet.exe soon.

怪异的注意:我们确实有一个双重构建。 由于某些奇怪的原因,NuGet.exe为我们再次运行了MSBuild。 那很la脚,也是一个已知的错误。 令人惊讶的是,在.NET和Java世界中,在大量CI系统中,“双重构建”都很常见。 弱点,但常见。 不过,没有任何借口。 很快将在NuGet.exe中修复该问题。

第2步-初始来源签到 (Step 2 - Initial Source Check-in)

I like using BitBucket for small private projects and CodePlex for public Open Source projects. Both support Hg (the elemental symbol for "Mercury" as in Mercurial) and CodePlex supports TFS for both Source and Work Items. Since my demo is private and BitBucket supports unlimited private projects it was a good fit.

我喜欢将BitBucket用于小型私人项目,将CodePlex用于公共开源项目。 两者都支持Hg(在Mercurial中为“ Mercury”的基本符号),并且CodePlex都为源项和工作项都支持TFS。 由于我的演示是私有的,并且BitBucket支持无限的私有项目,因此非常适合。

I cloned my project URL from BitBucket into a folder, then added, commited and pushed my bits to the BitBucket Site:

我将项目URL从BitBucket克隆到一个文件夹中,然后添加,提交并将其推送到BitBucket站点:

C:\dev\something>hg clone https://shanselman@bitbucket.org/shanselman/techedlibrary
...move my files in...
C:\dev\something>hg add
...yada yada yada...
C:\dev\something>hg commit
...yada yada yada...
C:\dev\something>hg push
...yada yada yada...

It's useful then to make sure I can get my source code into another folder and still build it. It's common to miss a file or two. Since the CI Server will be getting the code into a temporary folder you really need to make sure the source will build as it is, retrieved fresh from your SCM.

这样很有用,以确保我可以将我的源代码放入另一个文件夹并仍在构建它。 丢失一两个文件很常见。 由于CI服务器会将代码放入一个临时文件夹中,因此您确实需要确保源代码可以按原样生成,并且可以从SCM中重新获取。

第3步-设置构建服务器 (Step 3 - Setup your Build Server)

I'm running TeamCity locally on http://localhost:8111/ with a "build agent" (there can be many) on the same machine. Visit Administration and make a new project, then a new Build Configuration (like Debug or Release).

我在http:// localhost:8111 /上本地运行TeamCity,并且在同一台计算机上运行“构建代理”(可以有很多)。 访问Administration并创建一个新项目,然后创建一个新的Build Configuration(例如Debug或Release)。

You'll need to make a VCS root (Version Control System - there are like 60 different acronyms for version control systems. If you see a TLA (Three Letter Acronym) out there that you don't recognize, it's probably something that means "Source Control.") in TeamCity. Note that I selected Mercurial and set the HG Command Path with the full path to HG.EXE as the CI will call that to check out the code from BitBucket. Note also that I put the path without my name and password for the "pull changes from" as I put the name and password lower down.

您需要制作一个VCS根目录(版本控制系统-版本控制系统有60个不同的首字母缩写词。如果您看到一个您不认识的TLA(三个字母的首字母缩写词),则可能是“源代码控制。”)。 请注意,我选择了Mercurial,并将HG命令路径设置为HG.EXE的完整路径,因为CI会调用该命令从BitBucket中检出代码。 还要注意,当我将名称和密码放低时,我将没有我的名称和密码的路径放入“从...处更改”。

Back in Administration, select Edit under your project. Note the nice lists of steps on the right.

返回“管理”中,选择项目下的“编辑”。 注意右边的步骤列表。

We want two steps, one for the MSBuild and one "custom command line" for the NuGet package step. The first step is easy, we call MSBuild on our TechEdLibrary.csproj.

我们需要两个步骤,一个用于MSBuild,一个用于“ NuGet”软件包步骤的“自定义命令行”。 第一步很简单,我们在TechEdLibrary.csproj上调用MSBuild。

The second step is a temporary hack. It's temporary because JetBrains TeamCity is building NuGet support in directly (screenshots of their internal build below!)

第二步是临时破解。 这是暂时的,因为JetBrains TeamCity正在直接构建NuGet支持(下面是其内部构建的屏幕截图! )

The custom script is basically a BATCH file that looks like this:

自定义脚本基本上是一个BATCH文件,如下所示:

del *.nupkg 

NuGet pack techedlibrary.csproj
forfiles /m *.nupkg /c "cmd /c NuGet.exe push @FILE yourapikey -source http://localhost:81/

There's a few interesting things going on here.

这里发生了一些有趣的事情。

First, I delete all the nupkg files in the CI folder as it's all temporary and we don't want to accidentally push old stuff.

首先,我删除了CI文件夹中的所有nupkg文件,因为它们都是临时文件,我们不想意外地推送旧文件。

Second, I pack up the NuGet package like we saw before.

其次,我像之前看到的那样打包了NuGet包。

Finally, I don't know the name of the newly created *.nupkg file, so I cheat by making a DOS BATCH "for loop" that has only one item in it, the newly created .nupkg file! Then I call cmd.exe execute NuGet.exe pack with that new file as a parameter. Make sure you have the trailing backslash.

最后,我不知道新创建的* .nupkg文件的名称,所以我作了一个欺骗,使其中只包含一项的DOS BATCH“ for循环”作弊,新创建的.nupkg文件! 然后我以该新文件为参数调用cmd.exe执行NuGet.exe包。 确保您有反斜杠。

NOTE: You can also save the API Key in local storage with NuGet SetApiKey yourapikey -source http://localhost:81 and it'll be saved on a per-source basis.

注意:您还可以使用NuGet SetApiKey yourapikey -source http:// localhost:81将API密钥保存在本地存储中,并将基于每个源进行保存。

Because I have an Orchard NuGet Gallery running locally, I have an API key for that server. I'm running my gallery server (it holds the packages and serves the OData Feed) locally on port 81 and the Orchard Site itself is on port 80.

因为我有一个本地运行的Orchard NuGet Gallery,所以我有该服务器的API密钥。 我在端口81上本地运行我的图库服务器(该服务器包含软件包并提供OData Feed)在Orchard网站本身位于端口80上。

I set the build to check Source Control every 60 seconds, if a change is detected, the source is retrieved, build, then NuGet packed, and published to my local server (or the public one).

我将构建设置为每60秒检查一次源代码控制,如果检测到更改,则检索,构建源,然后打包NuGet,并将其发布到本地服务器(或公共服务器)。

TeamCity is something I like to have running on extra hardware I've got lying around. You can have up to 20 projects with their free version, so when combined with BitBucket and CodePlex where I keep my projects I can setup my own Continuous Integration System in just a few hours and have better confidence in my code. You can even use Amazon EC2 images to run your builds or just be a build agent.

我希望TeamCity可以在我闲散的额外硬件上运行。 免费版本最多可以包含20个项目,因此当我将项目保存在BitBucket和CodePlex上时,我可以在短短几个小时内设置自己的持续集成系统,并对我的代码更有信心。 您甚至可以使用Amazon EC2映像来运行您的构建或仅作为构建代理。

高峰-具有NuGet集成的TeamCity (Sneak Peak - TeamCity with NuGet Integration)

I'm continuing to talk to companies and software vendors who are jazzed about NuGet. If you are one, watch my talk for ideas on what you can do as a commercial software entity and get into the discussion on CodePlex.

我将继续与热衷于NuGet的公司和软件供应商交谈。 如果您是一个人,请观看我的演讲,以获取有关您可以作为商业软件实体做什么的想法,并开始讨论CodePlex。

Here's some mockups of what JetBrains is planning for TeamCity. These are just ideas, and they aren't available, so don't stress or pressure them. ;)

这是JetBrains为TeamCity计划的一些模型。 这些只是想法,它们不可用,所以不要强调或施加压力。 ;)

This is a mockup of NuGet as a possible Build Step within TeamCity.

这是NuGet的模型,可作为TeamCity中的可能构建步骤。

Here's a mockup of a Build Feature where TeamCity downloads specific packages that will be needed by the build.

这是一个构建功能的模型,其中TeamCity下载了构建所需的特定软件包。

Here's a screenshot of some early work that Martin Woodward from the TFS team is doing to make sure NuGet and Team Foundation Server work well together in a Continuous Integration environment. Feel free to contact Martin via his blog and continue the discussion on http://nuget.codeplex.com.

这是TFS团队的Martin Woodward正在做的一些早期工作的屏幕快照,以确保NuGet和Team Foundation Server在持续集成环境中可以很好地协同工作。 请随时通过他的博客与Martin联系,并在http://nuget.codeplex.com上继续讨论。

Hope this helps you integrate NuGet into your company, however you like it.

希望这可以帮助您将NuGet集成到公司中,但是您愿意。

Related Links

相关链接

翻译自: https://www.hanselman.com/blog/nuget-for-the-enterprise-nuget-in-a-continuous-integration-automated-build-system

nuget 构建自己的包

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值