Use MSBuild project extensions instead of importing the users project

[natemcmaster]

Implicit imports prevents using on a project file that has the Sdk attribute. This change instead generates a file in the MSBuildProjectExtensionsPath to inject targets require to find the UserSecretsId property in a project. (This is the approached used by dotnet-watch and dotnet-ef).

Resolves #242

cc @mlorbetske @muratg
cc @bricelam can you review? This is similar to the approach you've implemented in dotnet-ef to extract project metadata.

[natemcmaster]

cc @rainersigwald

[rainersigwald]

No strong objections for now, though the hardcoding of ./obj/ will have to be changed before RTM. And it seems like changing the extension of your wrapper project would be a smaller, easier change to make for this prerelease.

[rainersigwald]

This embeds some assumptions about the path to IntermediateObjectDirectory that won't always hold--but are probably ok for most new (or converted) .NET Core projects.

[bricelam]

[natemcmaster]

the hardcoding of ./obj/ will have to be changed before RTM.

Good to know. Where will MSBuildProjectExtensionsPath default to by RTM?

[rainersigwald]

@natemcmaster I expect that to stay the default (it's been like that for years), but the location of the obj directory is a user-specifiable option. Many teams prefer, for example, to have a single {repoRoot}\out directory that's easy to delete. Some folks even go so far as to put all build outputs on a different drive that they can format to get back to a clean state.

[bricelam]

We allow overriding it in dotnet-ef, but it does feel like we're abusing this feature a bit... Is there a way outside of MSBuild to get the value of the MSBuildProjectExtensionsPath property?

[natemcmaster]

Ok. Do you have any ideas how a tool like this could evaluate the value of MSBuildProjectExtensionsPath?

[bricelam]

Maybe, in general, we just need a built-in target to get the value of properties. E.g. msbuild /t:GetPropertyValue /p:Property=UserSecretsId /verbosity:minimal

(This would satisfy EF's requirements too.)

[rainersigwald]

You could use the OM to extract the property, but then you could just get the property you wanted instead (which is what I want to talk to you about after resolving the immediate issue).

For this limited case, you could probably force-override MSBuildProjectExtensionsPath with a command-line property to a folder you control (and clean up after execution). That might hork the project build in other ways, but since you're only calling one target that you control it might be ok?

[natemcmaster]

OM? Sorry, not familiar with that abbreviation.

Overriding the MSBuildProjectExtensionsPath prop would probably work for dotnet-user-secrets, but quickly falls over for anything that needs properties that depend on other project extensions such as those generated by NuGet restore.

Let's continue this conversation on #244.

[rainersigwald]

OM is "Object model"--I'm saying you could just evaluate the project programmatically and ask MSBuild what the property you want is.

[natemcmaster]

Gotcha. Unfortunately, we went down that path and got burned too many times by MSBuild API. At the strong recommendation of David Kean and others, we have been pursuing project-evaluation-as-a-target instead.

[natemcmaster]

Retargeted to feature/msbuild. This fix won't make it into RC.2, but will be in the next update.