- 21 5月, 2019 1 次提交
-
-
由 Sam Harwell 提交于
-
- 16 5月, 2019 1 次提交
-
-
由 Manish Vasani 提交于
Add some more AnalyzerConfigDocument functionality to the VisualStudio layer. This includes the changes to enable Preview workspace and Preview changes functionality for analyzer config documents
-
- 13 4月, 2019 1 次提交
-
-
由 Jason Malinowski 提交于
This renames Create to TryCreate.
-
- 15 2月, 2019 1 次提交
-
-
https://github.com/dotnet/roslyn/issues/33080由 Jason Malinowski 提交于
We never actually had any tests that tested Code Model and our project system shims at the same time. To fix this required pulling RoslynVisualStudioWorkspace.GetFileCodeModel down to VisualStudioWorkspaceImpl, and fixing up some mocks we have to be (every so) slightly more accurate.
-
- 10 12月, 2018 1 次提交
-
-
由 dotnet-bot 提交于
-
- 04 12月, 2018 1 次提交
-
-
由 Jason Malinowski 提交于
Just removing a TODO.
-
- 28 11月, 2018 1 次提交
-
-
由 Jason Malinowski 提交于
The implementation was commented out and not restored prior to merging the project system refactoring.
-
- 02 11月, 2018 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 06 10月, 2018 2 次提交
-
-
由 Jason Malinowski 提交于
TypeScript uses the AbstractProject and VisualStudioProjectTracker to add and remove projects; this adds back a minimal shim for them to use.
-
由 Jason Malinowski 提交于
This produces a new free-threaded, well factored API for adding projects to the VisualStudioWorkspace. The core type is the VisualStudioProject which is a free-threaded API that you can use to push information over. CSharpProjectShim, VisualBasicProject and CPSProject each have an instance of VisualStudioProject that they push things through. The inheritence model here is now smaller. CSharpProjectShim and VisualBasicProject inherit from AbstractLegacyProject, but that's it. CPSProject now inherits nothing, and AbstractProject is here purely for TypeScript back-compat until they're moved onto the new APIs. The expectation is F# and TypeScript both move to VisualStudioProject, which we make public in some form. Then that type will go away.
-
- 21 3月, 2018 1 次提交
-
-
由 Neal Gafter 提交于
-
- 10 3月, 2018 5 次提交
-
-
由 Jason Malinowski 提交于
VisualStudioWorkspace had a virtual method to send a call over to the code model logic. Since we now have the requisite interface callable directly, we should just call it directly. It also saves us the trouble of passing a DocumentId only to re-decompose the type again.
-
由 Jason Malinowski 提交于
Our CodeModel implementation would go to AbstractProjects and then see if the implemented a special interface IProjectCodeModelProvider to fetch their ProjectCodeModel. This abstraction was pretty leaky: since we're already assuming carnal knowledge of AbstractProject, we can just make it a property that might be null and be done with it. This means we can push some code that is in very derived types (and duplicated) down into a single shared type. At this point, all project system calls flow through IProjectCodeModel, and the only tangling back to AbstractProject is just to do the lookup from project -> IProjectCodeModel. We can now introduce an interface IProjectCodeModelFactory that just maintains that mapping and then suddenly things are really clean.
-
由 Jason Malinowski 提交于
This interface is able to live in our ServicesVisualStudio project and that's what the project systems are able to interact with. This makes the API more like an "optional service" that they can create. Down the road, we can just have an IProjectCodeModelFactory that keeps the implementation entirely separated out.
-
由 Jason Malinowski 提交于
Rather than using inheritence, we only need one factory method. By favoring composition here this will set us up to remove a bunch of derived types. This commit is admittedly strange, as in some cases we now have a child type being created in derived types of AbstractProjectCodeModel. This is just to move things around, and it'll get better in the next commit.
-
由 Jason Malinowski 提交于
This was being used directly in a lot of places, but I think it's a bit eaiser to follow object relationships if all creation methods go through AbstractProjectCodeModel, and from there might get forwarded. A fair number of checks were being made of whether the CodeModelCache was null; I don't believe these make sense. Once the underlying _codeModelCache type is made non-null, it is never set to null, and the only way it could fail to create in the first place is if the project was never in the ProjectTracker. Given we only produce these once we already have a live AbstractProject, that's not possible.
-
- 23 8月, 2017 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 15 7月, 2017 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 29 6月, 2017 2 次提交
-
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
-
- 01 6月, 2017 1 次提交
-
-
由 Sam Harwell 提交于
-
- 20 4月, 2017 2 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
Move helper API up as it will be using functionality in EditorFeatures as part of FAR refactoring work.
-
- 14 3月, 2017 2 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 13 3月, 2017 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 20 11月, 2016 3 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 19 11月, 2016 1 次提交
-
-
由 Matt Warren 提交于
-
- 18 11月, 2016 5 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 Matt Warren 提交于
-
由 CyrusNajmabadi 提交于
Rename intenral code to 'FindUsages' so it better reflects that it can present results for more than just FindReferences.
-
- 15 11月, 2016 1 次提交
-
-
由 Jason Malinowski 提交于
Previously, when a VisualStudioWorkspace was constructed we were doing a bunch of work in the constructor talking to the UI thread. This was dangerous because we might get composed on a background thread. This moves the dangerous initialization until we're creating a project when we know we have a UI thread available. In this refactoring I moved the project tracker and a few other fields into a private class so it's more obvious what's dangerous to touch. I also do a pass through all consumers of the property and either update it to use the deferred state directly (because we're only consuming projects, so it's fine if we don't have anything) or to the factory method if we actually are creating projects. This does temporarily regress the ability to create projects on background threads, but it was unclear if that was generally safe to start with.
-
- 10 11月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 22 9月, 2016 1 次提交
-
-
由 Jason Malinowski 提交于
This introduces a new core interface IDocumentOptionsProvider that lets you provide options for documents. There's a factory to create them to deal with the fact the implementation will be living in EditorFeatures.Next.csproj for now.
-
- 26 7月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 25 7月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-