13

What are the differences between aspnetcidev and aspnetvnext?

I see that aspnetcidev says "quick builds", but what does this mean?

roydukkey
  • 3,149
  • 2
  • 27
  • 43

2 Answers2

35

Jan 29, 2016 edit:

This information is now part of the ASP.NET wiki: https://github.com/aspnet/Home/wiki/NuGet-feeds


The ASP.NET build system uses 3 myget feeds for each branch + nuget.org.

  • aspnetvolatile<branch> (aspnetvolatiledev/aspnetvolatilerelease)
  • aspnetci<branch> (aspnetcidev/aspnetcirelease)
  • aspnetvnext (dev branch)/aspnetrelease (release branch)

After each repo under github.com/aspnet builds successfully, each package produced by it is pushed to the corresponding volatile feed.

After the graph of repos is build, we trigger the Coherence build. This build verifies that the packages have matching versions and their references are correct (that they are coherent). Then, it pushes them to aspnetci<branch>.

Once the Coherence build passes, we run all our tests on the packages in the aspnetci<branch> feed. If the tests pass, we sign the packages and ship them to aspnetvnext or aspnetrelease

So the differences are:

  • aspnetvolatile<branch>

    • latest packages
    • possible not coherent
    • not tested
    • not signed
    • updated on every checkin
    • mostly used to diagnose build failure
  • aspnetci<branch>

    • possible not latest
    • coherent
    • not tested
    • not signed
    • updated when all repos build successfully
    • used by our build system
  • aspnetvnext/ (aspnetrelease|nuget.org)

    • possible not latest
    • coherent
    • signed
    • tested
    • updated when everything works
    • used for stable packages

Once the aspnetcirelease feed is stable, we push the packages from it to nuget.org.

Unless you work on developing new features for ASP.NET, I recommend that you use aspnetvnext (for dev bits) or nuget.org (for release bits). The release feed (aspnetrelease) is just a staging feed and it's not always in a good shape.

Edit:

I think it's easier to understand from a table: enter image description here

Victor Hurdugaci
  • 28,177
  • 5
  • 87
  • 103
  • The information is helpful, but it don't describes why for example **aspnetcidev** has `castle.core.netcore v3.3.4-beta8`, which not exist in **aspnetvnext** and why `CoreCLR v1.0.0-beta6-10444` exists in **aspnetvnext**, but not in **aspnetcidev**. Why **aspnetcidev** has `CultureInfoGenerator v1.0.0-rc1-15822` and `EntityFramework.Commands v7.0.0-rc2-16668m` but "nightly" **aspnetvnext** have `CultureInfoGenerator v1.0.0-rc1-15732` and `EntityFramework.Commands v7.0.0-rc2-16649` (relatively large difference in versions). See https://www.myget.org/gallery/aspnetcidev and /aspnetvnext – Oleg Jan 04 '16 at 20:29
  • We clean packages from that feed regulary but if a package doesn't exist anymore in sources or it gets renamed, there might be some left overs – Victor Hurdugaci Jan 04 '16 at 20:31
  • What about EntityFramework.Commands in version v7.0.0-rc2-16649 on https://www.myget.org/gallery/aspnetvnext and in version v7.0.0-rc2-16668 on https://www.myget.org/gallery/aspnetcidev ? Why one have so large difference in version numbers? – Oleg Jan 04 '16 at 20:34
  • 16649 completed on 28 Dec 15 18:48; 16668 completed on 04 Jan 16 04:36. Between these two builds, EF built successfully every time. Unfortunately, there were some test failures up the stream. If we have any test failures, we don't push *any* package to `aspnetvnext` from `aspnetcidev`. Right now there's a test failure in the `Security` repo. – Victor Hurdugaci Jan 04 '16 at 20:40
  • Sorry about the previous comment. The information displayed in the gallery is wrong. EntityFramework.Commands for example exist in aspnetvnext in versions v7.0.0-rc2-16649, v7.0.0-rc2-16647, v7.0.0-rc2-16647, ..., but in aspnetcidev as v7.0.0-rc2-16668, v7.0.0-rc2-16667, v7.0.0-rc2-16665, v7.0.0-rc2-16664, v7.0.0-rc2-16663, ... In any way one can see that there are no clear rule about the published or removed version in both repositories. – Oleg Jan 04 '16 at 20:41
  • That's because we don't push every package. Only the latest successful. Also, because of myget space constrains, we only keep the latest 5 (I think?) versions of each package – Victor Hurdugaci Jan 04 '16 at 20:43
  • It's a little *another problem*, but in my experience the largest problem with different NuGet sources is the usage of locally cached packages. All the packages will be saved in `%USERPROFILE%\.dnx\packages`. If we would build one project which uses `EntityFramework.Commands` using NuGet feed1, it saves the version locally, then if we build another project using **another** NuGet feed2 then Visual Studio will get just **the latest version from cache even if feed2 (which we want to use) don't have it**. It makes many problems and one have to delete full `%USERPROFILE%\.dnx\packages` regular. – Oleg Jan 04 '16 at 20:57
2

I'm abrade that you can get the exact answer on the question only from Microsoft. You can open https://www.myget.org/gallery and filter for "aspnet" for example and will find many other repositories published for different teams.

For me more interesting is the information displayed by .NET Version Manager: dnvm (without parameters):

enter image description here

Thus, for me, the source https://www.myget.org/F/aspnetvnext/api/v2/ (or https://www.myget.org/F/aspnetvnext/api/v3/index.json) is the "official" place for the night builds of ASP.NET 5.

On the other side by filtering of https://www.myget.org/gallery "aspnet" you can see that aspnetvnext contains more distinct packages as aspnetcidev.

enter image description here

It's clear that both repositories probably contains different set of packages.

One important example where the repository https://www.myget.org/gallery/aspnetcidev be used is the new .NET Command Line Interface (.NET CLI) which you find on GitHub here. The new dotnet utility uses https://www.myget.org/F/aspnetcidev/api/v3/index.json together with many other sources in https://github.com/dotnet/cli/blob/master/NuGet.Config.

I suppose that AspNetCIDev is the repository of packages required for .NET CLI. It's the utility, which should replace dnx and dnu in RC2 of ASP.NET 5. See the post, this one and some other.

Oleg
  • 220,925
  • 34
  • 403
  • 798
  • `aspnetcidev` is where our coherent but not tested packages go. See my answer for details – Victor Hurdugaci Jan 04 '16 at 19:43
  • @VictorHurdugaci: Thanks for the info! It seems to me that a lot of different NuGet repositories with the same or not the same packages confuse many users. A little more information about *public* NuGet repositories would be very helpful. – Oleg Jan 04 '16 at 20:18