Modernize Shared Projects: Use globs in projitems files, allow editing them in VS

Visual Studio Version: 16.6

Expected Behavior:

1. Newly created projitems files contain a single line.

<Compile Include="$(MSBuildThisFileDirectory)**\*$(DefaultLanguageSourceExtension)" />

1. IDE does not add new entries to the file when adding files to the shared project that uses globs.

2. IDE does not change projitems file when a file is removed using Solution Explorer UI

3. IDE does not change projitems files when a file is moved from one shared project to another

4. The IDE can open projitems file for editing

Actual Behavior:

1. Newly created shared project’s projitems file does not have the glob include.

2. Adding a new file in the IDE to a shared project that contains entry with a glob adds an explicit entry.

3. Removing the file in IDE removes the item glob and breaks the project.

4. Moving files between shared projects removes the item glob from source project and breaks the project.

5. Can’t open projitems file for editing in VS.

6. Cannot use Build Current Project

Scenarios

1. Merge conflicts

   Listing all items in the projitems file results in frequent merge conflicts that need to be resolved.

2. Slow project reloading

   Changing a branch to one where the project contains different files leads to project reloading.

3. Keeping the list of files in sync with the actual directory content adds maintenance cost

4. Adding a link to an existing file to a shared project.

   Because “add a link to an existing file” feature is not available, one needs to edit the projitems file manually. Due to [5] that’s also not possible in VS. The file needs to be open and edited in an external editor. Once the linked <Compile> item is added and the file is saved the VS reloads the project. One needs to also make sure that any unsaved changes in the file made by VS were saved, otherwise they would be discarded.

[CyrusNajmabadi]

@jjmew can items like ‘6: Cannot use Build Current Project’ be done? We should already know the current project context (since we present it in things like the nav bar list):

So it feels like it should be hard for build-current-project to support that. Note: because i don’t have build-current-project, my only option is to build-all. But this takes around 25 minutes on my box. So this is really incredibly painful to deal with.

We understand that this is painful

I’m not sure the level of pain is truly understood 😃

Also:

Just does not seem to work at all. So, effectively, shared files feel like random floating files that i never know how to find or deal with.

[riesvriend]

@tmat I’m testing this workaround : instead of a .shproj, use a .csproj for the shared project.

Prevent the shared project from being compiled by editing its .csproj like below. This will still automatically include all files in the project’s folder to be part of the project from the Solution Explorer’s point of view, as well as for source control.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <EnableDefaultCompileItems>false</EnableDefaultCompileItems>
    <EnableDefaultNoneItems>false</EnableDefaultNoneItems>
  </PropertyGroup>
  <ItemGroup>
    <None Include="**\*.cs" Exclude="obj\**\*.*" />
  </ItemGroup>
</Project>

To reference the shared project files, do this:

<!--Reference files from shared csproj-->
<ItemGroup Label="Imports">
  <Compile Include="..\WorkflowModule\**\*.cs"></Compile>
</ItemGroup>

<!--Instead of shproj import --> 
<!--<Import Project="..\WorkflowModule\WorkflowModule.projitems" Label="Shared" />-->

As far has I have tested, it gives you all features from your expected behavior.