If you do a Find in Files with a loaded project, VS doesn't search in the project file.

A couple of things to make sure:

Find In Solution works
Open from search results works.

Current State:

With this in-progess PR: https://devdiv.visualstudio.com/DevDiv/_git/VS/pullrequest/124985 (Microsofties-only sorry), the following works:

What works:

If project file is closed:

• Find in Files/Find All set to Project or Solution

If project file is open but not active:

• Find in Files/Find All set to Project or Solution
• Find set to Project or Solution

If project file is open and active:

• Find set to Solution
• Find in Files/Find All set to Solution
• Incremental Find

What doesn't work:

If project file is open and active (cause: issue 1):

• Find set to Project
• Find in Files/Find All set to Project (returns "No files were found to look in")

If project file is closed (cause: issue 2):

• Find set to Project or Solution

If AppDesigner is open (cause: issue 3)

• Find set to Project or Solution

Other:

• Attempting to open the project file from Results window displays an error

Issues that need to be solved:

• 1. If the project file is open and active, Monitor Service thinks Solution is the active hierarchy and not the project.
• 2. FindOrOpenFile (FindUtil.cpp) is blocking opening the project file because RDT is returning RDT_ProjSlnDocument. Even if it does return, it asks ShellOpenDocumentService to OpenDocumentViaProject via LOGVIEWID_TextView.
• 3. If AppDesigner is open, ShellOpenDocumentService wants to activate it with a different logical view IVsMultiViewDocumentView.ActivateLogicalView

From @davkean on April 29, 2016 18:13

See:

Copied from original issue: dotnet/roslyn#10982

From @davkean on March 23, 2016 17:33

On retargeting a WPF flavor, it adds System.Xaml if WPF is referenced if targeting .NET Framework 4.0 or higher.

Copied from original issue: dotnet/roslyn#10013

Add following to AppDesigner context menu:

• Add Item
• Open In File Explorer
• Delete
• Rename (dotnet/roslyn#9993)

From @davkean on May 10, 2016 23:51

Property pages/Application Designer has a pattern of wrapping calls in try...catch and swallowing them - we should silently watson when we hit those blocks so that we can see stacks and hit counts.

Copied from original issue: dotnet/roslyn#11229

From @davkean on April 29, 2016 17:9

Unlike csproj, which requires a project reload.

1. Create a new project
2. Rename the project.json to ProjectName.project.json.
3. Edit the project.json to add a reference to your favorite package.
4. Rebuild.

Expected: the package reference is added
Actual: it's not

Background: once the project.json is renamed, we don't have the proper logic to update the file system watcher that is watching project.lock.json.

Copied from original issue: dotnet/roslyn#10973

From @davkean on April 29, 2016 18:42

(Moved from: https://connect.microsoft.com/VisualStudio/feedback/details/2091320/environment-variables-configuration-platform-in-csproj-wrong)

Description: Environment Variables $(Platform) in csproj always AnyCPU,
Environment Variables $(Configuration) in csproj always Debug

Repro Steps:Edit the csproj file and add this path

<ItemGroup> 
<Content Include="$(SolutionPath)\$(Platform)\$(Configuration)\Foo.dll" /> 
</ItemGroup> 

and solution and project choose release & x64.

select this file in solution explorer and prop always "SolutionPath\AnyCPU\Debug\Foo.dll"

Impact:buildbreak, can't find the lib.

Copied from original issue: dotnet/roslyn#10984

From @davkean on April 29, 2016 18:9

Steps to reproduce:

1. Run VS on a monitor with 150% DPI (not sure if DPI is related to bug)
2. Create a C# console application
3. In solution explorer, right click on project and choose "Properties"
4. Click Debug tab

Result (I also attached a screenshot):
Notice that I have a ton of real estate, and the editor is using very little of it:

Copied from original issue: dotnet/roslyn#10981

From @davkean on May 4, 2016 15:45

Today, C#'s version of ILanguageFeaturesProvider is answer language questions without using Roslyn. We should change it to call through Roslyn.

At the same time, we should implement the VB version - I'm not sure what's broken without it.

Copied from original issue: dotnet/roslyn#11061

From @davkean on April 29, 2016 22:23

We need to determine if we're going to implement the hosting process. We're waiting on the debugger team to provide data on how much time this saves on F5.

We'll also need an async way of initializing this - it's currently the top three of UI delays.

Copied from original issue: dotnet/roslyn#10995

From @davkean on March 22, 2016 22:30

To create and return Win32 app.manifest.

Used when you check Enable ClickOnce security settings via Security property page.

Copied from original issue: dotnet/roslyn#9988

From @davkean on March 22, 2016 23:42

You should be able to manipulate folders and files, by moving, renaming and deleting that are outside of the project, similar to csproj/msvbproj.

Copied from original issue: dotnet/roslyn#9991

From @davkean on April 29, 2016 21:39

(Filed on behalf of a customer)

Today in csproj/msvbprj, target framework, assembly name, etc are all project-wide properties - something that's not expected vary based on configuration. In the rewrite, we should making effectively all properties configuration-based

Copied from original issue: dotnet/roslyn#10991

From @davkean on March 23, 2016 0:0

Copied from original issue: dotnet/roslyn#9999

CPS does not provide a project system up-to-date check out of the box - to get a similar experience to csproj/msvbproj where they only call MSBuild after they've determined that they are out of date, we should implement one.

Design

To do a fast up-to-date check, we should implement IBuildUpToDateCheckProvider, a configured level service, that is called back to determine if build should call into MSBuild.

Requirements

• Respect <DisableFastUpToDateCheck> property to disable the build
• Always write to output window why we ended up calling MSBuild (under which verbosity?)
• Respect <ExcludedFromBuild> on items
• We should drive almost all inputs/output for the up-to-date check via the items above, such as (but not limited to) XML doc files, pdb, exe.config, deps.json, runtimeconfig.json, etc) to avoid hardcoding these in the project system. We should make changes in the SDK/MSBuild to add these.
• Respect IItemType.UpToDateCheckInput on other items (basically all known items) - see IProjectItemSchemaService
• Respect <UpToDateCheckOutput Include=""/> and <UpToDateCheckInput Include=""/> to supplement the build. We'll need to create ProjectItemDefinitions for these (so that we see them in data flow) and set UpToDateCheckInput for the later.
• Send telemetry to track why we ended up calling MSBuild
• Handle situations, such as WinMDs, where the binary copied to the output directory is the same binary as csc produced.
• Handle situations, such as <UseCommonOutputDirectory> where dependencies aren't copied to the output directory.
• Handle <CopyToOutputDirectory> items especially when set to <Always> where the legacy project system always shells out to MSBuild.
• Rationalize <FileWrites> vs <UpToDateCheckOutput> (should we respect the former to avoid having update all of msbuild to tell us about all the outputs?)
• Rationalize whether we need to be run before or after draining critical tasks (BeforeDrainCriticalTasks metadata) - what if we haven't restored yet and NuGet brings down a bunch of packages, should we build or not?
• Work with NuGet folks to make sure GeneratePackageOnBuild sets the right inputs and outputs above to play nicely with up-to-date.

Things to watch out for

• While IBuildUpToDateCheckProvider is at each configured project level - in multi-targeting projects we only ever build the VS "active" config. We end up building all TFMs by clearing out the TargetFramework property. This is really important, and it means we need to factor in all other active configurations as to the determination of whether we need to shell out to MSBuild.
• See VCBuildUpToDateCheck for an example of a functioning up-to-date check,

From @davkean on April 1, 2016 17:27

We need to AppDesigner/Editors tests from internal.

Copied from original issue: dotnet/roslyn#10255

From @davkean on April 29, 2016 17:12

Unlike csproj.

Copied from original issue: dotnet/roslyn#10975

From @davkean on May 7, 2016 16:57

Version Used:

Steps to Reproduce:
1.
2.
3.

Expected Behavior:

Actual Behavior:

Copied from original issue: dotnet/roslyn#11162

From @davkean on March 23, 2016 17:30

Represents what happens when you add an item to a project, either by dragging it into the tree, including it, rename it or adding via Add Item dialog.

We need to set defaults, such as Build Action and Generator.

Make note that the WPF flavor has different and additional code to handle this above and beyond csproj.dll/msvbproj.dll.

Copied from original issue: dotnet/roslyn#10011

From @davkean on April 12, 2016 0:54

I'm thinking that we implement a pre-req handler via IVsRetargetProject that does a check to see if the project contains a list of unsupported features, and then offers to reload via csproj/msvbproj.

As we bring up features we simply remove them from this list so that we open more and more projects via CPS.

Copied from original issue: dotnet/roslyn#10493

From @davkean on April 29, 2016 17:53

(Moved from https://connect.microsoft.com/VisualStudio/feedback/details/1322721/solution-explorer-displays-conditional-references-wrongly.)

Specifying a condition in reference one is able to reference different libraries in Debug and Release mode. It makes sense for example to reference obfuscated nuGet package in Release configuration, and reference precompiled debug binaries in Debug configuration. Consider the following extract from .csproj file:

<ItemGroup> 
<Reference Include="Lib.Core, ....." Condition="'$(Configuration)' == 'Release'"> 
<HintPath>..\..\Packages\Lib.Core.5.4\lib\net45\Lib.Core.dll</HintPath> 
<Private>True</Private> 
</Reference> 
<Reference Include="Lib.Core,...." Condition="'$(Configuration)' == 'Debug'"> 
<SpecificVersion>False</SpecificVersion> 
<HintPath>..\..\Lib Dependencies\Lib.Core.dll</HintPath> 
<Private>True</Private> 
</Reference> 
</ItemGroup> 

This is built correctly in both configurations, however the Solution Explorer displays the references with errors:

• There are 2 Lib.Core references on project in both configurations
• 2nd Lib.Core reference is marked with warning sign, and it's properties are empty as if typical "this reference cannot be located" situation occur
• The physical path for 1st reference is displayed as if it is 2nd one (though switching Copy Local property on and off updates correct item in project file)

Taking into account this question ( http://stackoverflow.com/questions/1786917/is-there-a-way-to-specify-assembly-references-based-on-build-configuration-in-vi ) I assume that the display was correct in previous versions of VS.

Thank you.

Copied from original issue: dotnet/roslyn#10979

From @davkean on March 23, 2016 17:23

Tracking the XBAP debugging support in the WPF flavor.

Copied from original issue: dotnet/roslyn#10009

From @davkean on May 3, 2016 17:37

It would be great to be able to drag an item to another item in the tree to automatically add the the "DependentUpon" metadata.

Copied from original issue: dotnet/roslyn#11030

From @davkean on April 29, 2016 17:10

Unlike csproj.

1. Create a new project
2. Unload the project. rename the project.json to <ProjectName>.project.json
3. Reload the project.
4. Rename the project to something else.

Expected: the project.json should be renamed
Actual: it's not, so the project is broken

Copied from original issue: dotnet/roslyn#10974

From @davkean on March 22, 2016 23:55

We should remove ProjectCapabilitiesFromImportXmlProvider and ProjectCapabilitiesFromImportEvaluationProvider from C# and VB, and instead pull directly based on the extension or via a default targets file.

Copied from original issue: dotnet/roslyn#9996

We need to remove ManagedLang capability from Microsoft.CSharp.Designer.targets/Microsoft.VisualBasic.Designer.targets after CPS has removed inbox C#/VB components.

From @davkean on May 12, 2016 21:7

We duplicated ProjectTypeRegistrationAttribute as we added extra fields, remove this when we upgrade to CPS Preview 3.

Copied from original issue: dotnet/roslyn#11277

From @davkean on May 6, 2016 0:29

To drive the AppDesignerFolder, see CSharpProjectTreeModifier on index for examples.

Copied from original issue: dotnet/roslyn#11138

From @davkean on May 13, 2016 2:10

While most projects don't need to upgrade from VS 2015 -> VS 15, we still have to handle project upgrade from earlier versions.

We basically need to fill out implementations of IFlavoredProjectCompatibilityProvider.IsProjectNeedBeUpgradedAsync to decide whether to delegate onto csproj.

Copied from original issue: dotnet/roslyn#11285

From @davkean on April 29, 2016 18:37

(Posted on behalf of a customer)

using this:

robocopy “$(TargetDir)\” “$(SolutionDir)\Application\$(OutDir)\Modules” $(TargetName).dll $(TargetName).pdb
``

when my solution path is":

C:\Users\user\Documents\Visual Studio 2012\Foo\Foo Bar\Foo App

error message

Invalid Parameter #: "2012\Foo\Foo"

shows that it is not respecting the quotes around and split

_Copied from original issue: dotnet/roslyn#10983_

From @davkean on May 8, 2016 16:41

We don't show PublicKeyToken or the full name of the assembly, this would be extremely helpful.

Copied from original issue: dotnet/roslyn#11169

From @davkean on March 30, 2016 19:3

VS let's you open and explore extensibility projects even when the flavor or tools aren't installed. We should do a better job for other project types so that you can (at least) inspect the code.

See: https://twitter.com/hmemcpy/status/715252172955508736

Copied from original issue: dotnet/roslyn#10204

From @davkean on March 23, 2016 16:54

Copied from original issue: dotnet/roslyn#10008

From @davkean on May 11, 2016 1:57

Today if you double-click on a type that implements IComponent in Solution Explorer, we open the component designer.

While that's useful for forms, and user controls, it's not very useful for controls, or other components that contain just code and nothing "designable".

We should consider open code view by default. Let's pull the telemetry on whom double-click on a component, only to immediately close it and choose View Code.

Copied from original issue: dotnet/roslyn#11236

From @davkean on March 22, 2016 23:47

In msvbproj, by default My Project doesn't show it's contents. We need to decide if that's the right behavior, and if so, apply it to My Project in CPS.

Copied from original issue: dotnet/roslyn#9994

From @davkean on April 19, 2016 18:6

We need to port LanguageServiceErrorListProvider.cs, see: https://mseng.visualstudio.com/VSIDEProj/_git/VSIDEProj.CPS/pullrequest/99076#view=discussion

Copied from original issue: dotnet/roslyn#10688

From @davkean on April 29, 2016 18:48

Copied from original issue: dotnet/roslyn#10986

From @davkean on March 23, 2016 0:2

On a reference, CopyLocal is a 3-state;' Use MSBuild default behavior, Don't copy local and Always Copy Local.

Copied from original issue: dotnet/roslyn#10000

From @davkean on April 20, 2016 17:14

In csproj/msvbproj, you can manipulate/rename nodes that are not included as part of the project - CPS doesn't allow this. This will be a regression from previous releases.

Copied from original issue: dotnet/roslyn#10724

From @davkean on May 6, 2016 16:2

Editors.pkgdef is used for multiple reasons;

1. For registering property pages, designers ,etc
2. For registering dependent assemblies for the editor extension; Common7\IDE\CommonExtensions\Microsoft\Editor (see 343941fe645959363b33f965b6259630868cfda2 commit in VS tree).

When we delete editors internal, we should make sure we split 2) into a separate pkgdef and leave it in VS.

Copied from original issue: dotnet/roslyn#11146

From @davkean on May 11, 2016 8:12

See this commit: 78075ed

Here I add a new file, and the project system re-formatted the project file, we shouldn't do that and we should treat it similar to a source file, where we only change pieces that the user actually changed.

Copied from original issue: dotnet/roslyn#11245

From @Mike-EEE on May 12, 2016 8:5

I (unfortunately) made a lengthy, somewhat off-topic post/rant about this in another thread yesterday so I am going to throw it down here in a dedicated issue and see how it goes.

There's talk about the new build system. There has been previous efforts over at MSBuild to examine the build system and improve upon its format. These were ultimately denied, expressing a "better safe than sorry" (huh? 😛) perspective. So, with all the energy/enthusiasm/magic over here, this appears to be the new lightning rod for developer creativity. 😄

My ask is simple: Continue to use the XML format (or even JSON), but move away from the element mapping-to-POCO strategy and make the csproj/xproj/proj file a fully (XML or JSON) serialized POCO instead, so that at the very least we know the precise POCO (and definition/schema) that we are dealing with and constructing. This helps not only developer experience (and thereby sanity 😄 ) but also any tools/designers that wish to build off of it.

Currently, the project file looks like something like the following:

<Project>
 <ItemGroup> ... </ItemGroup>
 <PropertyGroup>... </PropertyGroup>
</Project>

This is great for defining arbitrary data in a file, but it is completely useless for someone who opens up the file and wondering: "what the **** is a <Project /> element?!"

The above design requires at least three artifacts:

1. The data file itself, expressing the data constructs (.csproj)
2. The schema file, defining what is allowed (.xsd if in XML, and I have never seen one in my 15 years of .NET for a .csproj file!)
3. The POCO that ultimately gets created from reading in the data file.

Oh but wait, there's more! Due to the above design, I bet you there is at least a fourth artifact!
4. The mapping class/utility that reads in the data file as an XmlDocument and laboriously reads in element by element, attribute by attribute to create and instantiate the POCO object(s) with their initialized values. OH THE INEFFICIENT HORROR!!

Conversely, if we take a page from Xaml file design, we have the data file's schema baked right into the file by way of the class definition. As a result, we only require two artifacts:

1. The data file (.xaml)
2. The class definition file (.cs/.vb)

This is a MUCH easier to design to produce, maintain, and manage. Tooling can tie right into the class file (using Roslyn??? 😄 ) and get all the information it needs. Developers do NOT need to hunt and chase down schemas in some arbitrary, hidden location (registry?! LOL, might as well be!) to figure out the file they are working with!

This is a very (relatively) simple design improvement that will make a world's (universe's!) difference in project look and feel. I cringe every time I have to go into the .csproj file because it is SO ARCANE AND MYSTERIOUS TO WORK WITH!

Finally, by using a class definition as the schema, another headache that this eradicates is the inconsistency between camelCase and PascalCase when declaring/using symbols/attribute names within the file (ALL THE INCONSIST!).

Anyways, thank you for any consideration and dialogue around this idea.

Copied from original issue: dotnet/roslyn#11263

From @davkean on April 1, 2016 17:25

Currently, Microsoft.VisualStudio.Editor's pkgdef is hand-written + expected to be pre-processed. We should move it an auto-generated model.

Copied from original issue: dotnet/roslyn#10253

From @davkean on May 11, 2016 1:35

Want to go from something like:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>0a5fdbad-1d09-4833-a0b4-cf17a684fb2e</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>ClassLibrary1</RootNamespace>
    <AssemblyName>ClassLibrary1</AssemblyName>
    <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System"/>

    <Reference Include="System.Core"/>
    <Reference Include="System.Xml.Linq"/>
    <Reference Include="System.Data.DataSetExtensions"/>


    <Reference Include="Microsoft.CSharp"/>

    <Reference Include="System.Data"/>

    <Reference Include="System.Net.Http"/>

    <Reference Include="System.Xml"/>
  </ItemGroup>
  <ItemGroup>
    <Compile Include="Class1.cs" />
    <Compile Include="Properties\AssemblyInfo.cs" />
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->

 </Project>

To something like:

<?xml version="1.0" encoding="utf-8"?>
<Project>

  <PropertyGroup>
    <OutputType>Library</OutputType>
    <RootNamespace>ClassLibrary22</RootNamespace>
    <AssemblyName>ClassLibrary22</AssemblyName>
    <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
  </PropertyGroup>

  <ItemGroup>
    <Reference Include="System"/>
    <Reference Include="System.Core"/>
    <Reference Include="System.Xml.Linq"/>
    <Reference Include="System.Net.Http"/>
    <Reference Include="System.Xml"/>
  </ItemGroup>

  <ItemGroup>
    <Compile Include="**\*.cs" />
  </ItemGroup>

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

</Project>

Copied from original issue: dotnet/roslyn#11235

From @davkean on March 22, 2016 23:45

CPS allows you to rename Properties/My Project folder. Either we should disallow like csproj/msvbproj, or make sure we do the right things to update the associated project property; <AppDesignerFolder>

Copied from original issue: dotnet/roslyn#9993

From @davkean on March 23, 2016 18:9

WPF flavor swaps in property pages, we need to decide what we'll do around this:

        if (pageReplacements == null)
        {
            // Populate the page replacements list
            pageReplacements = new List<PageReplacementItem>();
            if (IsHostInBrowser)
            {
                // For XBAPs, swap in the new security and signing pages:
                pageReplacements.Add(new PageReplacementItem(
                    "{DF8F7042-0BB1-47D1-8E6D-DEB3D07698BD}",   // Security property page
                    "{00a2c8fe-3844-41be-9637-167454a7f1a7}"    // WPF Security property page
                ));
                pageReplacements.Add(new PageReplacementItem(
                    "{F8D6553F-F752-4DBF-ACB6-F291B744A792}",   // Signing property page
                    "{e4b54061-084d-4484-9d21-ecae95a78a56}"    // WPF Signing property page
                ));
            }
            if (GetLanguage() == Language.VisualBasic)
            {
                // For all VB WPF apps, swap in the new application page:
                pageReplacements.Add(new PageReplacementItem(
                    "{8998E48E-B89A-4034-B66E-353D8C1FDC2E}",   // VB Application property page
                    "{00aa1f44-2ba3-4eaa-b54a-ce18000e6c5d}"    // VB WPF Application property page
                ));
            }
        }

Copied from original issue: dotnet/roslyn#10017

From @davkean on March 22, 2016 23:58

This is tracking simplified add item - ie choose Add Item, such as Add Windows Form, should add to the tree and automatically enter rename mode instead of opening the dialog.

Copied from original issue: dotnet/roslyn#9998

From @davkean on April 29, 2016 17:56

1. Create a new project (say WPF project).
2. Right click on the project an click on properties, keep it open.
3. Right click and add reference to the project.

Actual : No * appears next to the file name in the tab header. It appears if I close the tab and open it again via Right click -> properties on the project.

Expected : * should appear indicating that there are unsaved changes to the project file.

Copied from original issue: dotnet/roslyn#10980

From @davkean on April 11, 2016 22:56

Currently csproj/msvbproj uses vshost.exe to "speed up" F5 debugging for desktop client apps.It is also used for immediate window evaluation without starting a debugging session. We need to figure out if we are going to bring this forward to CPS or not.

Copied from original issue: dotnet/roslyn#10484

From @paul1956 on May 7, 2016 19:5

Version Used:
Feature Request
Steps to Reproduce:

1. ZIP a solution with Linked Files using underlying OS
2. Copy ZIP file to another computer and unZIP
3. build solution

Expected Behavior:
It has all the source files to build
Actual Behavior:
All linked files are missing

There needs to be a way to find and replace all linked files with physical files and then reverse it. I am looking for an easy solution other then to stop using linked files. I also don't want to have to find all the linked files in file system, manually copy them, ZIP then delete. This seems very error prone. The ability to highlight all Linked Files in Project system and convert linked to physical and visa versa, or a built in source packaging command could help. I am no proposing any specific solution.

Copied from original issue: dotnet/roslyn#11164