UserSecrets causes design-time tools to crash

[natemcmaster]

Changes made to support MSBuild #525 attribute break design-time usages of .AddUserSecrets() because Assembly.GetEntryAssembly() is different at design-time than runtime.

Known design-time scenarios affected
EF migrations - see dotnet/efcore#6918
ASP.NET Scaffolding

Workaround:
Users should specify the app assembly with the overload of .AddUserSecrets(Assembly assembly)
Example

.AddUserSecrets(typeof(Startup).GetTypeInfo().Assembly)

[davidfowl]

This is pretty horrible...

[natemcmaster]

@davidfowl proposed mitigation: #544. Basically, we shouldn't make .AddUserSecrets() the default method anymore. IMO we should obsolete it.

[Eilon]

This patch fix is approved!

[natemcmaster]

Resolved in #544. Design-time operations may still throw an error about either (1) entry assembly is null or (2) the UserSecretIdAttribute could not be found, but after looking at the options, we determined that for 1.0/1.1 there isn't much more .AddUserSecrets() can do to locate the user secret ID. We will consider revisiting this in 2.0 (see #550)

In most cases, uses will want to start using .AddUserSecrets<Startup>() instead.