Clean up dependencies projects#25609
Conversation
There was a problem hiding this comment.
Is this a functional or style consistency change? If it's the former then I may update BuildBoss to catch it.
There was a problem hiding this comment.
Style consistency.
There was a problem hiding this comment.
Why are you removing DevdiVPackagesDebugger? Had that in this solution to make the inner loop here easy:
- Restore DevDivInsertionFiles.sln
- F5
There was a problem hiding this comment.
This PR changes your loop to restore Roslyn.sln, F5. That's not changing either way, so no reason to have it here.
There was a problem hiding this comment.
(and yes the restore is more expensive there. But now it means compiler dependencies are actually being considered, so the next time somebody from your team adds a dependency there's a chance the right thing will happen, instead of nothing happening)
There was a problem hiding this comment.
DevDivInsertionFiles.vbproj is not in Roslyn.sln. It would need to be added there to keep the loop you subscribe. I'm fine with doing that but probably should delete DevDivInsertionFiles.sln at the same time. It's only purpose was to support that specific developer loop.
There was a problem hiding this comment.
It's only purpose was to support that specific developer loop.
Well, when DevDivInsertionFiles.sln was created, Roslyn wasn't even using NuGet -- we were just checking in references into our TFVC repo... 😄
The restore inputs of DevDivInsertionFiles.vb isn't needed as an input in anything anyways -- F5 would probably still do it. I'm happy to delete the solution file and move the project in if you'd like.
There was a problem hiding this comment.
The restore inputs of DevDivInsertionFiles.vb isn't needed as an input in anything anyways
Sure but the restore of what used to be DevDivInsertionFiles.sln was a nice inner dev loop and a functional requirement in our old setup. Given the deletion of the project references the SLN file can't be restored + F5'd and the project itself doesn't need to be restored hence the SLN is pointless now.
I'm happy to delete the solution file and move the project in if you'd like.
I'd prefer that. It was my eventual plan anyways.
There was a problem hiding this comment.
I guess the functional requirement was undocumented, and perhaps only known by you. 😉
Will do the deletion, but going to do that in a separate PR. @tmat wants this in to facilitate the System.Collections.Immutable cleanup (as he'll hit the same things I did without this), and I don't want to delay this one much further than necessary.
There was a problem hiding this comment.
I guess the functional requirement was undocumented, and perhaps only known by you.
And the test infrastructure that I wrote to make sure it worked 😄
Will do the deletion, but going to do that in a separate PR.
Okay
This contained a list of packages that we depended on and needed facades deployed into Visual Studio. We already have VisualStudioSetup.Dependencies that already (should have...) contained all the facades and more. We can just consume that project instead of having yet another duplication of facade lists.
…t include This ensures that if the compiler adds a new facade but we don't update VisualStudioSetup.Dependencies (either intentionally or by accident) we still will include the right facades.
a6655d6 to
ed6497f
Compare
By doing this, the VisualStudioSetup.Dependencies.csproj will now figure out the highest version of our own dependencies and the debugger dependencies, and create a single package that we can deploy that contains all of them.
ed6497f to
9b20d50
Compare
This makes BuildBoss happy.
|
Going to need to delete this line: Looks like BuildBoss wasn't running on DevDivInsertionFiles.sln hence items ilke this got missed. |
|
@tmat will continue to monitor this but I have no further changes. If it's green, feel free to merge before I do. |
Infrastructure only change.
This cleans up our dependencies projects which are used to determine the list of facades we put into PortableFacades. Previously, we had two projects, DevDivPackagesRoslyn (which would state the things we depended on) and DevDivPackagesDebugger, which is what the Debugger depends on that we're responsible for handling their dependencies. A few things had gotten screwed up in this process: