Consider improving missing user secrets ID exception message to help with migration to msbuild

[divega]

Customers that are using user secrets will need to tweak any call to AddUserSecrets() too as part of their migration from project.json to .csproj.

The current exception message when the location of the user secret ID cannot be found (e.g. using EF Migrations or while publishing) looks like this:

This method could not find a user secret ID because the application's entry assembly is not set. Try using the ".AddUserSecrets(Assembly assembly)" method instead.

This is all correct, but given a large number of customers may potentially run into this it makes sense to be more concise and to point to the easier to use AddUserSecrets<T>() overload.

[divega]

cc @muratg @natemcmaster

[natemcmaster]

I'm assuming the intent here is to help project.json --> MSBuild conversion. We'd need to put this into 1.0.x patch for this change to reach the right people.

[divega]

@natemcmaster yes that is it. I created this issue after the email thread.

[muratg]

@Eilon heads up, another 1.0.4 candidate.

[Eilon]

Ok, please place in the appropriate milestone.

[divega]

@natemcmaster mentioned we could also add ObsoleteAttribute to the overload that doesn't take parameters with a message pointing to the correct overload. That would probably help even more with the migration to .csproj than improving the exception message mentioned here but I don't think they are mutually exclusive.

[muratg]

@Eilon will track this with the rest of the Feb patch release. We may decide to skip this though, because we may need to patch a lot of other packages because of this version bump.

[Eilon]

We should do whatever change we feel is right. If it means we have to rebuild more packages, so be it.

[natemcmaster]

Proposed patch: #594

This requires bumping aspnet/Configuration to 1.0.2, which will probably mean rebuilding most downstream repos.