- 30 12月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
TLDR: This change removes our use of suppressParent which should not be used The core problem in our build setup which lead to the use of suppressParent is having the same reference DLL introduced by different NuGet packages. These packages differed in name and version from each other. The most notable example is the reference DLL for Microsoft.VisualStudio.Language.NavigateTo.Interfaces.dll which is contained in 3 different NuGet packages: - RoslynDependencies.Microsoft.VisualStudio.Language.NavigateTo.Interfaces 14.0 - Roslyn.Microsoft.VisualStudio.Language.NavigateTo.Interfaces 15.0 preview 5 - Microsoft.VisualStudio.Language.NavigateTo.Interfaces 15.0 RC The differing names is a problem because when resolving conflicts NuGet doesn't consider the referenced DLL versions at all (by design). Instead it is only concerned with handling conflicts between packages of the same name. These packages have different name and hence NuGet never attempts to do any conflict resolution between them. It will consider each package to be a separate entity and pass on their assets to MSBuild. This means that MSBuild will eventually be handed the same DLL with 3 different versions and consequently begins issuing MSB3277 errors. The suppressParent entries in the project.json file suppressed this error because it essentially removes the listed package from the transitive graph. Hence it never appeared in referenced projects, only a single DLL was passed to MSBuild and compilations progressed. This is the wrong approach to fixing that problem because it's subverting both the depenedncy conflict resolution aspects of NuGet / MSBuild and causing us to create incomplete deployments in our unit test directories. This is fighting the tooling instead of leveraging it. The more robust approach to solving this problem is to have a reference DLL always distributed through the same NuGet package. This allows NuGet to handle the version conflicts using standard conflict rules and resulting in only a single DLL being passed to MSBuild. In the past this has been a blocker because we often need DLLs at versions that aren't available on NuGet. Going forward we will be working with the VSSDK to remedy that problem. Short term though we are simply going to upload ad-hoc packages with the correct name to the roslyn-tools feed using the pre-release moniker -alpha. This ensures we don't have any conflicts with official packages on NuGet.org. There are a few cases this change doesn't completely address that I want to call out: - Types moved between the MS.VS.Shell.Immutable and MS.VS.Shell.Framework DLLs between Dev14 and Dev15. To prevent a lot of duplicate type errors the MS.VS.Shell.Immutable DLLs need to be removed from the compile graph, but not the runtime graph, in our Next projects. - GraphModel is an adhoc package created by us that doesn't have an existing NuGet package to pattern off of and it's not obvious how such a package would be laid out if it existed. The Dev15 packages also include this as a reference by default which causes a confilct with our packages. As such I've used "include: none" for now to work around the problem until a final NuGet package is decided on.
-
- 29 12月, 2016 3 次提交
-
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
- 16 12月, 2016 1 次提交
-
-
由 Heejae Chang 提交于
latest version of JsonRpc supports custom JsonConverter which I added for these 4 types. Checksum, SolutionId, ProjectId, DocumentId we can add more to AggregateJsonConverter for common roslyn types. unit test added
-
- 30 11月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
This setting controls binary deployment hence it needs to be centrally managed to help ensure we have a correct build. Custom projects can continue to control this setting themselves.
-
- 18 11月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
Rename intenral code to 'FindUsages' so it better reflects that it can present results for more than just FindReferences.
-
- 02 11月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
-
- 31 10月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
-
- 28 10月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
-
- 26 10月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
-
- 22 10月, 2016 2 次提交
-
-
由 Jared Parsons 提交于
TLDR: artifacts are going to move around in Binaries\Debug and the directory is going to get a lot bigger. At a high level build projects can be classified into three categories based on how they write output: - incorrect: a given output path is written to more than once with different contents - less correct: a given output path is written to more than once but always with the same content - correct: a given output path is written to exactly once Today the roslyn build is decidedly “incorrect” as pretty much every file is written directly into Binaries\Debug. This means it ends up writing pretty much every Visual Studio SDK DLL twice: once for Dev14 and once for Dev15. For example at various points in the build Binaries\Debug\Microsoft.VisualStudio.Text.Data.dll may refer to Dev14 and at others it’s Dev15. If this seems like a scary proposition for a build that’s because it is indeed scary and it has real consequences. By now pretty much everyone on the team has hit the build race condition that is dragging down our PRs. The general fix here is to move build outputs into separate directories. Instead of building to $(Configuration) projects now build into say $(Configuration)\Exes\$(MSBuildProjectFileName). This will have a substantial increase in the size of Binaries. We will be looking into ways to reduce that. In the short term though build stability far outweighs the size increase. This change takes us most of the way to "correct". There are several places I had to compromise in order to get this initial change in: - UnitTests still build to a common output folder (one for Dev14, another for Dev15). Pulling unit tests apart is going to take a bit of work. - Every project has a <RoslynProjectType> entry. This will go away in the future for most projects. It's temporarily needed so I can fix roslyn-internal in parallel without taking down the build. - VSL.Imports.targets is messy. Unavoidable for now due to the above. It will get cleaner as I iterate on this. None of these are relevant to the underlying race condition. Hence it's okay to push them off.
-
由 Heejae Chang 提交于
now remote host has moved down to common layer and .Next dll gets loa
-
- 13 10月, 2016 1 次提交
-
-
由 Heejae Chang 提交于
now remote host has moved down to common layer and .Next dll gets loaded if remote host option is on, we don't need this unnecessary indirection to delay load .Next. it will still not load .Next if remote host option is off.
-
- 11 10月, 2016 1 次提交
-
-
由 Tanner Gooding 提交于
-
- 30 9月, 2016 3 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
Move the remote part of NavigateTo down to the features layer now that RemoteHostClient is available there.'
-
由 CyrusNajmabadi 提交于
Move Remote features down to lower levels now that the RemoteHostClient is available from the Workspace layer.
-
- 29 9月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 25 9月, 2016 2 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 24 9月, 2016 2 次提交
-
-
由 Heejae Chang 提交于
-
由 Andy Gocke 提交于
This change drops support for .NET 4.5 and retargets to desktop 4.6 + CoreCLR. It also fixes up various analyzer warnings that were created due to the move. Fixes #12926
-
- 23 9月, 2016 2 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 17 9月, 2016 4 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 15 9月, 2016 1 次提交
-
-
由 Paul Vick 提交于
-
- 14 9月, 2016 1 次提交
-
-
由 Paul Vick 提交于
-
- 13 9月, 2016 2 次提交
-
-
由 Heejae Chang 提交于
-
由 Heejae Chang 提交于
-
- 10 9月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 08 9月, 2016 1 次提交
-
-
由 Heejae Chang 提交于
this is to make develop - debug cycle easiler when adding new features to service hub. to enable this, turn on Roslyn/FeatureManager/Features/RemoteHost and RemoteHostInProc once enabled, InProcRemoteHostClient will be used instead of ServiceHubRemoteHostClient except concrete type of RemoteHostClient, all other parts, exactly same code will be used. InProcRemoteHostClient can be used in unit test to test client and server side as they are.
-
- 02 9月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 31 8月, 2016 1 次提交
-
-
由 Heejae Chang 提交于
this makes sending over roslyn-internal solution data to OOP from 3 minutes to 4 seconds. after that, only changed assets are sent over which is usually less than 1-2ms. this optimization is only for actually moving data between 2 processes. there are other things involved which need to be optimized as well to make whole system to be faster than right now (which takes about 1+ mins for initial solution load)
-
- 24 8月, 2016 1 次提交
-
-
由 Kevin Halverson 提交于
-
- 23 8月, 2016 1 次提交
-
-
由 Kevin Halverson 提交于
-
- 17 8月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
The ImportGroup element is just noise. It was also used very inconsistently in the repo and often within the same project file. Just remove it.
-