Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates to daily build guidance for EF Core 5.0/EF Core 6.0 #22535

Merged
merged 2 commits into from
Sep 18, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
83 changes: 75 additions & 8 deletions docs/DailyBuilds.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,28 +8,47 @@ Daily builds are created automatically whenever a new commit is merged to the `m

A disadvantage of using daily builds is that there can be significant API churn for new features. However, this should only be an issue if you're trying out new features as they are being developed.

## Using daily builds
## Package sources

The daily builds are not published to NuGet.org because the .NET build infrastructure is not set up for this. Instead they can be pulled from a custom NuGet feed. To access this feed, create a `NuGet.config` file in the same directory as your .NET solution or projects. The file should contain the following content:
The daily builds are not published to NuGet.org because the .NET build infrastructure is not set up for this. Instead they can be pulled from a custom NuGet package source. To access this custom source, create a `NuGet.config` file in the same directory as your .NET solution or projects.

There are two different NuGet package sources for daily builds as we transition from EF Core 5.0 to EF Core 6.0.

### Package source for EF Core 5.0

Note that a feature complete release candidate with a go-live license is [available now on NuGet](https://www.nuget.org/packages/Microsoft.EntityFrameworkCore/5.0.0-rc.1.20451.13). Daily builds are only needed for early access to the RC2 bits.

For EF Core 5.0 RC2 daily builds, `NuGet.config` should contain:

```xml
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="dotnet6" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json" />
<add key="dotnet5" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json" />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
```

## Which version to use
### Package source for EF Core 6.0

For EF Core 6.0 daily builds, `NuGet.config` should contain:

```xml
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="dotnet6" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json" />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
```

Daily builds are currently branded as EF Core 6.0. For example, `6.0.0-alpha.1.20457.2`. This is an artifact of the build system; **these builds still contain the bits what we plan to ship as EF Core 5.0**.
## Package versions to use

### Using wildcards

The easiest way to use daily builds is with wildcards in project references. For example:
The easiest way to use daily builds is with wildcards in project references. For example, for EF Core 6.0 daily builds:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure floating versions are a good guidance to give, because stuff breaks as new packages are released - that can give a pretty negative experience to daily builds and may make people avoid them (because they don't know they can do differently). I'd recommend doing things as usual without floating.

But that definitely seems out of scope for this PR, plus the 5.0 daily builds are now as stable as anything else.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe for our daily builds this is probably the best guidance we can give. If we lose confidence in the quality of the dailys, then maybe we should consider not recommending this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment was less about quality, and more about APIs/behavior intentionally changing and breaking people.


```xml
<ItemGroup>
Expand All @@ -40,7 +59,18 @@ The easiest way to use daily builds is with wildcards in project references. For
</ItemGroup>
```

This will cause NuGet to pull the latest daily build whenever packages are restored.
Or for EF Core 5.0 RC2 daily builds:

```xml
<ItemGroup>
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.0-rc.2.*" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="5.0.0-rc.2.*" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="5.0.0-rc.2.*" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer.NetTopologySuite" Version="5.0.0-rc.2.*" />
</ItemGroup>
```

Using wildcards will cause NuGet to pull the latest daily build whenever packages are restored.

### Using an explicit version

Expand All @@ -60,3 +90,40 @@ EF Core 5.0 targets .NET Standard 2.1. This means that:
* The daily builds should work with any IDE that supports .NET Core 3.1.
* They do not require a Visual Studio preview release, although previews will also work.
* The daily builds should work with either the .NET Core 3.1 SDK or the .NET 5 SDK installed.

## Troubleshooting

### Missing packages

The config files shown above contain the two NuGet package sources needed for EF Core and its dependencies. However, you may need to add additional package sources for daily builds of other projects, or your own internal packages.

In addition, packages may be missing if the standard `nuget.org` package source has been disabled elsewhere; adding the source in this config will not bring it back. To fix this, either don't disable `nuget.org` anywhere, or tell NuGet to ignore previously disabled sources:

```xml
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<disabledPackageSources>
<clear />
</disabledPackageSources>
<packageSources>
<add key="dotnet6" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json" />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
```

A good way to ensure you're dealing with a completely clean NuGet configuration is to clear both disabled package sources _and_ previously configured package sources. For example:

```xml
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<disabledPackageSources>
<clear />
</disabledPackageSources>
<packageSources>
<clear />
<add key="dotnet6" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json" />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
```