- 12 11月, 2019 4 次提交
-
-
由 Joey Robichaud 提交于
LOC CHECKIN | dotnet/roslyn release/dev16.4-vs-deps | 20191101
-
由 msftbot[bot] 提交于
Merge release/dev16.4 to release/dev16.4-vs-deps
-
由 Andy Gocke 提交于
The AnalyzerConfigSet had a race where we were storing the pooled object in the cache. It turns out that this often works, due to hash codes mapping different sets to different buckets, but is wildly unsafe and can produce almost any result. This change releases the object from the pool before using it as a key. Fixes #39599
-
由 Jason Malinowski 提交于
Don't try to use UIContexts if we are in a command line build
-
- 09 11月, 2019 1 次提交
-
-
由 Jinu 提交于
Do not report EnC diagnostics when EnC is disabled
-
- 08 11月, 2019 2 次提交
-
-
由 Jason Malinowski 提交于
This code isn't new, but the use inside VisualStudioWorkspaceImpl.cs meant that we'd throw an exception when a project was added. This would get caught by the project system and converted back to an HRESULT. Customer reports claim this is a regression in newer builds, and I can't disagree with that but can't explain it. We have integration tests that test this, and on our CI right now they are passing. I similarly saw passing tests locally when I previously investigated this but am now seeing failing tests on newer dogfood builds. I also saw it fail once with a different error code or simply no error code; it leads me to believe that something environmental can cause either the HRESULT to be converted differently (as this is using IErrorInfo which is often the cause of spooky-action-at-a-distance) or something the project system is doing is swallowing the exception. It's unclear but the fix seems the same no matter what. Fixes https://developercommunity.visualstudio.com/content/problem/806929/command-line-builds-using-devenv-no-longer-work-fo.html
-
由 Andy Gocke 提交于
Merge release/dev16.4 to release/dev16.4-vs-deps
-
- 07 11月, 2019 2 次提交
-
-
由 Charles Stoner 提交于
-
由 Rikki Gibson 提交于
-
- 06 11月, 2019 1 次提交
-
-
由 Tomáš Matoušek 提交于
-
- 05 11月, 2019 10 次提交
-
-
-
由 msftbot[bot] 提交于
Merge release/dev16.4 to release/dev16.4-vs-deps
-
由 Joey Robichaud 提交于
Switch some calls to ThreadHelper.ThrowIfNotOnUIThread to something else
-
由 Andy Gocke 提交于
Update release/dev16.4 version to -beta4
-
由 msftbot[bot] 提交于
Merge release/dev16.4 to release/dev16.4-vs-deps
-
由 Joey Robichaud 提交于
Revert "Run integration tests with .NET Core SDK shipped with VS"
-
由 Andy Gocke 提交于
-
由 Joey Robichaud 提交于
Use resource strings for validating warning text
-
由 Jason Malinowski 提交于
Skip failing integration tests
-
由 Andy Gocke 提交于
Merge release/dev16.4 to release/dev16.4-vs-deps
-
- 02 11月, 2019 5 次提交
-
-
由 Jason Malinowski 提交于
Fix crash where we are not always finding text snapshots
-
由 Joey Robichaud 提交于
-
由 Joey Robichaud 提交于
-
由 Joey Robichaud 提交于
Co-Authored-By: NSam Harwell <sam@tunnelvisionlabs.com>
-
由 Joey Robichaud 提交于
-
- 01 11月, 2019 11 次提交
-
-
由 Manish Vasani 提交于
Don't MEF import core Roslyn language service type in SolutionExplore…
-
-
由 Manish Vasani 提交于
-
由 Tomas Matousek 提交于
-
由 Tomáš Matoušek 提交于
Subscribe to OnModuleInstanceLoad/OnModuleInstanceUnload events only when managed debugging is being used. (#39568) Avoids loading Roslyn when debugging native code only.
-
由 Fred Silberberg 提交于
Introduce IUsingDeclarationOperation
-
由 Ivan Basov 提交于
Do not return favorites in expansions of null values.
-
由 msftbot[bot] 提交于
Merge release/dev16.4 to release/dev16.4-vs-deps
-
由 Fredric Silberberg 提交于
Make IUsingDeclarationOperation explicit, and the underlying IVariableDeclarationGroupOperation implicit.
-
由 Jason Malinowski 提交于
Given this is not a reliable crash, my guess is the problem is we are sometimes processing an older Solution snapshot. Asking a specific SourceText for the specific ITextSnapshot it came from could fail if that snapshot had been GC'ed, whereas going to the container first and asking for the buffer directly should be more reliable. Either way we now also handle the null case. Fixes https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1010045
-
由 Jason Malinowski 提交于
-
- 31 10月, 2019 4 次提交
-
-
由 Joey Robichaud 提交于
Run integration tests with .NET Core SDK shipped with VS
-
由 Manish Vasani 提交于
My recent [change](https://github.com/dotnet/roslyn/pull/37795/commits/03c9021af53e648c74a496a1a5e53a2dc616540c#diff-f7b9587085c9a364f8b4727f4599ebc5R76) caused an RPS regression where creating a new C++ project, which leads to us loading the Roslyn SolutionExplorerShim, now also loads Roslyn language service and all underlying Roslyn assemblies. This change avoids MEF importing the Roslyn type in AnalyzerCommandHandler constructor and instead gets it lazily. In future, we should add an analyzer to prevent SolutionExplorerShim from MEF importing any core Roslyn services.
-
由 Joey Robichaud 提交于
Integration tests were being run with the dotnet SDK from the build environment. This broke when VS updated to creating new .NET Core projects against a TFM not supported by the version of the SDK we were building against. This change allows the .NET Core SDK that shipped with VS to be found when running integration tests. Which is likely the desired behavior. Fixes #39588
-
由 Joey Robichaud 提交于
Check that PackageInstallerService is enabled before getting sources
-