Fixes for Building with Update 1 #6206
Conversation
|
👍 The changes look good, though:
|
|
You already said the same thing to me - damn, no longer getting notifications anymore. |
jasonmalinowski
force-pushed
the
building-with-update-1-fixes
branch
from
8679a34 to
5dc4451
Compare
|
@dotnet-bot, retest this please. Having to re-run since commits were added that Jenkins didn't pick up. |
| @@ -4,7 +4,9 @@ | |||
| "net45": { } | |||
| }, | |||
| "runtimes": { | |||
| "win7": { }, | |||
| "win7-anycpu": { }, | |||
There was a problem hiding this comment.
Should we be removing these, or are you leaving them for compat with VS2015 RTM?
There was a problem hiding this comment.
I'm leaving them in for compat with RTM until we declare RTM no longer suitable for Roslyn development. More practically, our build machines still need that!
|
👍 (Aside: I wonder if we should ask GitHub to suppress diffs in project.lock.json files by default, the way they do in resx designer generated files?) |
|
Tagging @yishaigalatzer and @davidfowl for the question above. |
|
I thought the main reason you checked the lock files in is to see the diffs? |
|
retest prtest/win/dbg/unit64 please |
|
@yishaigalatzer we want to know if a lock file changed when we didn't expect it to, but not necessarily to see every diff when we are mucking with project.json files. |
|
@yishaigalatzer: and it's also a workaround for restore instability on some of the non-Windows platforms we're still bringing up. |
… such Update 1 defaults to copying implementations for some class libraries, but we don't need that for our feature binaries.
With Visual Studio 2015 Update 1 you should not specify -anycpu in the runtimes section. Right now we'll have both to allow us to build with and without Update 1, and we'll remove the old ones once we've made the transition. Update 1 also tries deploying implementations for some class libraries, so I'm updating all our test and VSIX deployment class libraries to now include implementations.
We don't need SolutionDir or RestorePackages, which were for very old- style restore systems.
These interfaces change between VS versions, so this makes us not dependent upon a specific version of VS.
jasonmalinowski
force-pushed
the
building-with-update-1-fixes
branch
from
2962dab to
4263f09
Compare
|
The re-push was just to rebase this atop the latest stabilization, since there's been a few days of changes I want to ensure I cleanly test with. |
By luck, we were getting the real version we did want, but this is correct.
…fixes Fixes for Building with Update 1
|
Isn't branching off stabilization but target master in pr still merge and pollute master breaking RTM? Did you mean need rebase to master before submitting?
|
|
@DiryBoy: the expectation (at least for people doing IDE bug fixing) will be to branch off of stabilization, since that ensures that you have internal APIs that are synced with VS synced. But you'll submit to master. This won't pollute master since we're going to be merging stabilization back down into master any time we make a change in stabilization before Update 1 ships. |
|
If you're making changes in the compiler, you might do other workflows. |
A set of changes to update the Roslyn solution to build with Update 1. These changes are needed since we've formalized how project.json works with desktop-targeting clas libraries. The changes should all be backwards compatible with the original release of Visual Studio 2015 and should be an effective no-op for anybody building there.
These changes are targeting stabilization because once Update 1 is released, our community will be branching off of stabilization (although submitting PRs to master) to ensure they're working on the same base and won't have internal API breaks.
Reviewers: @dotnet/roslyn-ide, @kevinpi, @tannergooding, @agocke