1. 15 2月, 2017 6 次提交
  2. 14 2月, 2017 1 次提交
  3. 11 2月, 2017 1 次提交
  4. 10 2月, 2017 3 次提交
  5. 09 2月, 2017 6 次提交
  6. 08 2月, 2017 6 次提交
  7. 07 2月, 2017 4 次提交
  8. 05 2月, 2017 1 次提交
  9. 04 2月, 2017 8 次提交
  10. 03 2月, 2017 4 次提交
    • J
      Capture documents in dump in event of FindToken crash with linked files. · 5ea743de
      Jonathon Marolf 提交于
      We are seeing reports of Visual Studio crashing in FindToken with argument out
      of range exceptions.  It appears that this is causes by linked files being of
      differing lengths.  This change captures the original and linked documents
      on the stack so we can better understand what is happening.
      5ea743de
    • C
      Merge pull request #16883 from CyrusNajmabadi/symbolKeywork · 0ed38ad1
      CyrusNajmabadi 提交于
      Fix crash in roundtripping a symbol that references a LocalFunction's TypeParameter.
      0ed38ad1
    • J
      Merge pull request #14354 from jasonmalinowski/fix-visualstudioworkspace-affinity · df01cbdc
      Jason Malinowski 提交于
      Fix VisualStudioWorkspace thread affinity and defer creation
      df01cbdc
    • D
      Avoid deadlocks when unloading .NET Standard Projects (directly or via... · e2cc9b6e
      David Poeschl 提交于
      Avoid deadlocks when unloading .NET Standard Projects (directly or via Solution close) referencing Shared Projects
      
      Fixes https://github.com/dotnet/roslyn/issues/14479
      
      The problem here is that unloading projects takes a serialization lock,
      which can cause Shared Project IVsHierarchys to notify us that their
      context hierarchy has changed. In response to this, we try to set the
      new active context document for open files, which also tries to take the
      serialization lock, and we deadlock.
      
      For .NET Framework Projects that reference Shared Projects, two things
      prevent deadlocks when projects unload. During solution close, any
      Shared Projects are disconnected before the projects start to unload, so
      no IVsHierarchy events are fired. During a single project unload, we
      receive notification of the context hierarchy change before the project
      is unloaded, avoiding any IVsHierarchy events if we tell the shared
      hierarchy to set its context hierarchy to what it already is.
      
      Neither of these behaviors are safe to rely on with .NET Standard
      projects, so we have to prevent the deadlock ourselves. We do this by
      remembering if we're already in the serialization lock due to project
      unload, and then not take the lock to update document contexts if so
      (but continuing to lock if it's not during a project unload).
      e2cc9b6e