Skip to content
This repository has been archived by the owner on Dec 18, 2018. It is now read-only.

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

Closed
divega opened this issue Jan 25, 2017 · 11 comments

Comments

@divega
Copy link

divega commented Jan 25, 2017

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
Copy link
Author

divega commented Jan 25, 2017

cc @muratg @natemcmaster

@natemcmaster
Copy link
Contributor

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
Copy link
Author

divega commented Jan 30, 2017

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

@muratg
Copy link

muratg commented Jan 30, 2017

@Eilon heads up, another 1.0.4 candidate.

@Eilon
Copy link
Member

Eilon commented Jan 30, 2017

Ok, please place in the appropriate milestone.

@muratg muratg added this to the 1.0.2 milestone Jan 30, 2017
@divega
Copy link
Author

divega commented Jan 31, 2017

@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
Copy link

muratg commented Jan 31, 2017

@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
Copy link
Member

Eilon commented Jan 31, 2017

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

@natemcmaster
Copy link
Contributor

Proposed patch: #594

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

@Eilon
Copy link
Member

Eilon commented Feb 8, 2017

This patch bug is approved. Please use the normal code review process w/ a PR and make sure the fix is in the correct branch, then close the bug and mark it as done.

@natemcmaster
Copy link
Contributor

Fixed in 618ff3c

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants