Core projects fail to build when they reference other projects not included to solution

[abpiskunov]

I have following solution structure:

ClassLibrary1 (classic net46)
somefolder\
    ClassLibrary7
        \ClassLibrary7 (core net46)

ClassLibrary7 has project reference for ClassLibrary1 in the form that specify Guid:

    <ProjectReference Include="..\..\..\ClassLibrary1\ClassLibrary1.csproj">
      <Project>{2684d895-d7ce-4b24-a29e-caed2291e2ea}</Project>
      <Name>ClassLibrary1</Name>
   </ProjectReference>

Build fails both from VS and from command line saying that

ClassLibrary7.csproj (ReportAssetsLogMessages target) error NU1105: Unable to find project information for 'c:\users\antonpis \source\ClassLibrary1\ClassLibrary1.csproj'. The project file may be invalid or missing targets required for restore.

Classic csproj would work in this case (VS however showed a warning but built fine) both in VS and command line (command line did not have warnings)

[abpiskunov]

Note: removing Guid and Name metadata from ProjectReference would fix that, but imagine users converting tehir projects and see errors when where there should be no error at all... they know that csproj file does exist in that location.

[davkean]

Can you expand on above? Do you mean that ClassLibrary1.csproj is referenced but not included in the solution?

[abpiskunov]

yes, correct

[davkean]

This issue was moved to NuGet/Home#5820

[emgarten]

The project system would need to allow NuGet to read these external projects in order for this to happen. I think this issue is best tracked here.

[davkean]

I'm not convinced that this repo is the correct repo either. We fire up project instances when we are directed to by the Solution, in this case, these references aren't seen by the solution and we're never even loaded to look at these projects.

NuGet isn't the only thing broken here, you won't get cross-project IntelliSense, they won't build when the solution is built inside Visual Studio (they will build from command-line but using the default configuration instead of the one passed via the command-line) and probably a few other things.

@abpiskunov TBH, I don't want to tackle this issue - as a workaround add the projects to the solution - I'm gonna move it to the Unknown milestone, if you find a better home feel free to move it.

[abpiskunov]

Just encountered this issue again and was going to open an issue and remembered that i already opened it before. I believe this needs to be fixed and here is why:

In our WTE repo we have about 12 different solutions for different features. Each solution might have 10-30 projects , so they are not small. Some projects are reused across different solutions. Now i converted those shared projects to dotnet core and i see very annoying behavior: when shared project depends on other projects, and i was working on one solution, then i did work around this issue by adding all dependencies to the solution. But when i open other solutions i see same thing again and again. That means that when i do change some dependencies on shared project i need to go and edit all 12 sln files and not forget to remove unnecessary projects in case i remove dependencies, since the only reason they were added to some sln files was shared project depended on them, but if they are removed i need to remember it and do manual actions every where.

This is a real world scenario and we are facing it. I understand why it is happening, however it just feels that design did not consider such scenarios and should be changed a little.

My main motivation here is that "tool" is a tool for reason and should be smart to help people more than command line does, it is not just the editor. In fact in DNX project system in Dev14 we handled it differently and this issue did not exist. That is pretty unfortunate that nuget restore and some other logic did not take into account past experience and we got to deal with similar issues again in next releases (I am not talking about bugs here, but overall design that was created "brand new" for some Dev15 features, like restore for example)

[abpiskunov]

In this scenario, project system does have all info it needs and don't have to go to DTE. Project reference path is fully resolved and brought by DT build.

Btw, one more problem which can be a separate bug, but it is related to this issue: when i do add a missing project to the solution, clean and rebuild - error is still there. I have to do a manual restore - but why should i? Everything is already restored. Also it goes away if i close and reopen VS instance. (Note: in some cases it did work, in some did not, feels like some timing or caching issue)

[julielerman]

I got this error message when creating a new solution, copying two projects from elsewhere into the solution's folder, then back in VS2017 15.5.2, adding both projects to the solution. When building, I got the error on multiple attempts. Closing and re-opening VS2017 made the problem disappear. Unfortunately, this seems to be the solution to a variety of weird problems that I've had over time which is why I do it before wasting too much time scratching my head.

[ceddlyburge]

I am getting this error message a lot today as well, and a restart of visual studio fixes it. The projects are loaded and in the solution, so that's not the problem for me.

[BrunoZell]

I'm facing the same problem right now when using nested submodules (submodule depends on other repository with csproj). The temporary workarround is to use a conditional ProjectReference:

<ItemGroup>
  <!-- Temporary solution until nested submodules are easier to work with -->
  <SolutionSubmodule Include="$(SolutionDir)\modules\DependencyName\src\DependencyName\DependencyName.csproj"></SolutionSubmodule>
  <NestedSubmodule Include="..\..\modules\DependencyName\src\DependencyName\DependencyName.csproj"></NestedSubmodule>
</ItemGroup>

<ItemGroup>
  <ProjectReference Include="@(SolutionSubmodule)" Condition="Exists(@(SolutionSubmodule))" />
  <ProjectReference Include="@(NestedSubmodule)" Condition="!Exists(@(SolutionSubmodule))" />
</ItemGroup>

Then each dependency needs to be added to the solution only once, and not for every subomdule that references it. Howerver, there are many disatvantages:

• Each dependency from imported modules itself has to be a direct submodule of the project. Annoying for big projects.
• It's not allowing for different versions of a dependency, since the used csproj is not the one from the nested submodule anymore
• It's very verbose and you have to write it manually
• Each used csproj still has to be added to the solution

[mynkow]

This is still an issue in mid 2019

[nkolev92]

The NuGet side of the feature was implemented in NuGet/NuGet.Client#2521.

If you fully build the projects that are getting loaded in VS by other means, NuGet should be able to reuse the assets from the local project's obj.