We added a new API IProjectSiteEx.AddFileEx that takes the link metadata
for an item so we don't have to query an IVsHierarchy to figure out
where the file is linked into. If we don't have a link though, we should
compute the relative folder to the project directory and use that.

Fixes https://github.com/dotnet/roslyn/issues/33171

Fixes #31540

* Fix naming, remove help button, let the UI has a default selected destination

* Add comments

* remote question mark from warning dialog

The AnalyzersCommandHandler was still trying to call GetHostProject
to find the host project as a way to directly grab the rule set file
to process that. That was deprecated but we hadn't fixed it up yet.

The fix is to re-thread through a way to get to the rule set. The
"ownership" of a rule set file (if one exists for a project) is owned
by the VisualStudioProjectOptionsProcessor, so we now need a way to jump
to that directly from any project so another map is added to the
VisualStudioWorkspaceImpl. That map is unfortunate -- the
OptionsProcessor is really something that should be private to the
project system itself and shouldn't be grabbable by any random code.

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/779916
Completes task https://devdiv.visualstudio.com/DevDiv/_workitems/edit/698029

when it happens we will show the info bar and proceed. this is not error recovery but not forcing users to restart VS right away by crashing VS. now user will have time to do what they want and then restart VS

to retain fault result in task center, we need to provide detail info UI so that user can click the fault task left in the task center, but right now we don't have one and we don't want to just show exception message in message box.

we could think of using RetainAndNotifyFault so that we show exception message in the task center tip, but that would be annoying since most likely it is info user didn't ask for it.

we can add UI later if user ever ask for it. for now, taking simple approach of just removing it from task center once download is done in any way (success, cancelled, failed)

This is a reworked version of #32616 targeting the dev16.0-preview3 branch.

We previously always considered that closing and reopening a solution
should generate a new Id, even if it happened to be the same file.
Since we sometimes otherwise hold onto old state, we'll continue this.

Fixes https://github.com/dotnet/roslyn/issues/31686.

Co-Authored-By: Ngenlu <genlu@users.noreply.github.com>

This reverts commit 73f1152e. Right now
F# is still implicitly mentioning this type. This has been fixed in
https://github.com/Microsoft/visualfsharp/pull/6153 but until we can
get that rolled out we'll roll back the name change.

For legacy projects, we would update our bin path whenever the obj
path was updated as a heuristic. We lost that as a part of my rewrite
as a simple oversight; this restores that back.

Fixes https://github.com/dotnet/roslyn/issues/32711

Many of these can be called fairly often, so this avoids allocations in
the common case we don't refresh anything.

AbstractProject.RemoveDocument was trying to support removing
ContainedDocuments, but had a misplaced cast which negated the whole
attempt.

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/776782

Fixes #32490

When showing the preview changes dialog, we correctly de-duplicate the linked files by only showing changes for a single file. When applying changes, we undo changes which have been unchecked by the user in the preview changes dialog. However, the latter did not account for linked files. This led to us undoing unchecked changes for non-linked files, but not for linked files. This PR ensures that we also handle linked files when undoing changes.

When the AbstractEditorFactory needs to load the WinForms designer, it must first check the
project's TFM. If the TFM is netcoreapp and is greater or equal to 3.0, it specifies a
different string to the IVSMDDesignerService.CreateDesignerLoader(...) to indicate that the
new WinForms designer should be instantiated.

Eventually, this code will move into the WinForms designer itself.

We potentially run the creation of the output window pane during the
shutdown of Visual Studio. This can happen because we're using
InvokeBelowInputPriorityAsync, which queues the switch to the UI thread
using IThreadingContext.JoinableTaskFactory.SwitchToMainThreadAsync().
This resulting continuation can run during package shutdown when
services are no longer available.

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/744155

When we created metadata references inside of VisualStudioProject,
we ensured we created them with a file watcher so we would know about
changes. When we created a metadata reference after we converted a
project reference back to a metadata reference that was originally
a metadata reference, we didn't do so since that conversion happens
in VisualStudioWorkspaceImpl itself and it couldn't access the file
watcher.

This fixes this. The majority of the work here is just moving code
around. Basically the watchers were per-project, which meant that
it'd be forbidden to call into them the Workspace code because
that would violate the lock hierarchy. To fix this, I move the file
watching logic into it's own little type with a lock, and since no
calls are made back into the workspace under that lock, it removes
the deadlock concerns.

Fixes dotnet/roslyn#32554.

FileChangeWatcher wasn't specifying all the file watcher flags it should
have been. Reuse the constant that already existed for FileChangeTracker
so we get the same behavior.

FileChangeTracker is eventually going to be retired, and so I'm moving
over the constant to the long-term home.

This is referencing a method that has long since been deleted.

The actual work was a nested type called .Snapshot, which everything
was using directly. The renames in here are:

- VisualStudioMetadataReference.Snapshot to
  VisualStudioPortableExecutableReference
- The _provider field in .Snapshot to _referenceManager
- VisualStudioMetadataReferenceManager.CreateMetadataReferenceSnapshot
  to just .CreateMetadataReference, since it's always a snapshot.

The FileChangeWatcherProvider has to do some magic so we can hand
out a FileChangeWatcher that fetches the IVsFileChangeEx from the shell,
but not in a way that implicitly risks any marshal back to the UI thread
in a way that might deadlock. The odd bit was we were doing some of
that initialization in the VisualStudioWorkspace constructor itself
which didn't really make sense.

While I'm here, we can also remove the hack that was working around
a shell bug where we might deadlock if we called into the async service
provider from a background thread.

* Fixes 659765

* Respond to feedback

* Fix async and cancellation, add bool for polling

* Respond to feedback

* Remove unneeded bool

* Fix first run issue

* Check Suspend and Resume buttons

* Respond to feedback

* Check cancellation token
Co-Authored-By: Nchborl <chborl@users.noreply.github.com>

* Change to SafeContinueWithFromAsync

* Spelling
Co-Authored-By: Nchborl <chborl@users.noreply.github.com>

* Remove first run check

* Refactor OLECMD

* Respond to feedback

* Remove parentheses

* TryGet the InlineRename UndoState before trying to apply the current state

* Arcade SDK 1.0.0-beta.19054.11

* Consolidate OptProf scripts

* Use raw IBC data from VSTS drop