- 19 1月, 2017 5 次提交
-
-
由 David Poeschl 提交于
Fixes #15326, #15486
-
由 Heejae Chang 提交于
make sure we empty out information in solution/project/documentInfo whose ownership is moved to Solution/Project/DocumentState otherwise, we will keep holding on staled data longer than necessary. this change makes OOP to consume 300MB less in roslyn size solution.
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 13 1月, 2017 2 次提交
-
-
由 Dustin Campbell 提交于
**Customer Scenario**: Referencing the latest Microsoft.Net.Compilers package and try to run csc.exe on Mono fails. (This was found building the xplat branch of MSBuild.) **Summary of Change**: Don't use System.Runtime.InteropServices.RuntimeInformation in Compiler, Workspace or Features layers **Details**: Recently, we took a change to use `System.Runtime.InteropServices.RuntimeInformation.IsOSPlatform(...)` to detect the current platform. The API is designed such that different implementations are delivered via NuGet depending on the TFM. For .NET Core, this works great. When restoring an app using Microsoft.CodeAnalysis on Windows, a Windows implementation is delivered. And, when restoring the same app targeting macOS/Linux, a Unix-specific implementation is delivered. However, for apps targeting .NET Framework (such as the desktop compiler), this design presents a serious problem. Essentially, the Windows implementation is always picked for .NET Framework apps (such as net451, net46, etc.). So, if that app is then run on macOS or Linux on Mono, Microsoft.CodeAnalysis will *think* it's running on Windows and start reporting errors because path separators are pointing the wrong direction.
-
由 Heejae Chang 提交于
make sure we use ordered list of document/projectIds when creating checksum make sure we set HasAllInformation when creating projectInfo added unit test
-
- 12 1月, 2017 7 次提交
-
-
由 Jonathon Marolf 提交于
We now return false if we get an empty set of naming styles.
-
由 David Poeschl 提交于
Fixes #15345 Do not run Naming Styles on overrides or known explicit/implicit interface implementations.
-
由 Adrian Secchia 提交于
-
由 Adrian Secchia 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
If we read in bad data from disk, do not blindly use it as it may not be valid wrt the state of the project.
-
- 10 1月, 2017 4 次提交
-
-
由 Jared Parsons 提交于
-
由 Jonathon Marolf 提交于
in Dev14 these options were persisted as booleans. They are now persisted as xml in Dev15. The fix is to not have the persistence keys overlap, ensuring Dev14 will not try to deserialize Dev15 options and vice versa
-
由 CyrusNajmabadi 提交于
* Make tuple types more round-trippable. * Add more test info. * Update test. * Support roundtripping errors/non-errors.
-
由 David Poeschl 提交于
Fixes #13249
-
- 07 1月, 2017 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 06 1月, 2017 1 次提交
-
-
由 David Poeschl 提交于
Fixes #15943
-
- 04 1月, 2017 2 次提交
-
-
由 Heejae Chang 提交于
-
由 Heejae Chang 提交于
-
- 31 12月, 2016 4 次提交
-
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
- 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 提交于
-
- 23 12月, 2016 9 次提交
-
-
由 Mikayla Hutchinson 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 22 12月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-