MSBuildWorkspace.OpenSolutionAsync Throws Microsoft.Build.Exceptions.InvalidProjectFileException for Soluion having .vcxproj project along with .csproj

[abhijitparkhi1983]

Version Used: 1.3.2, 2.0.0, 2.0.1

Steps to Reproduce:

1. Using a older version of Visual Studios, say Visual Studios 2008, create a .NET Solution which consists of .csproj and .vcproj/.vcxproj projects under one solution.
2. This will create a .vcproj/.vcxproj which uses a MsBuild 3.5 or older version and older version of Visual C++ compiler and libraries.
3. When we try to open such a solution using MSBuildWorkspace.OpenSolutionAsync(solutionPath).Result, we get exception.

NOTE When we open the above solution using Visual Studios 2013 and above, we get a Review Solution Action message window which suggests that The project(s) will be upgraded to use the Microsoft Studios 2013/2015 compiler and libraries. Any managed or native code project(s) using C++/CLI extensions will be automatically upgraded to target .NET Framework 4.5.1/4.5.2/4.6.0/4.6.1. If you do not upgrade the project(s), building your porject(s) will require the corresponding version of Visual Studios to be installed

If we do the up-gradation, obviously the MSBuildWorkspace.OpenSolutionAsync will work. If we dont up-grade, and then we do UnLoad Project for .vcxproj/.vcproj projects, MSBuildWorkspace.OpenSolutionAsync command works well.

Expected Behavior: Because Roslyn does not handle the .vcxproj/.vcproj as of now, the command MSBuildWorkspace.OpenSolutionAsync should simply open the solution by unloading the .vcxproj/.vcproj projects and continue processing the the .csproj projects.

Actual Behavior:

Following exception is thrown:

Microsoft.Build.Exceptions.InvalidProjectFileException: Error parsing a project section.  C:\Roslyn\CSharp_VCX_MIX_Sample.sln
at Microsoft.Build.Shared.ProjectFileErrorUtilities.VerifyThrowInvalidProjectFile(Boolean condition, String errorSubCategoryResourceName, BuildEventFileInfo projectFile, Exception innerException, String resourceName, Object[] args)
   at Microsoft.Build.Construction.SolutionFile.ParseFirstProjectLine(String firstLine, ProjectInSolution proj)
   at Microsoft.Build.Construction.SolutionFile.ParseProject(String firstLine)
   at Microsoft.Build.Construction.SolutionFile.ParseSolution()
   at Microsoft.Build.Construction.SolutionFile.ParseSolutionFile()
   at Microsoft.Build.Construction.SolutionFile.Parse(String solutionFile)
   at Microsoft.CodeAnalysis.MSBuild.MSBuildProjectLoader.<LoadSolutionInfoAsync>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.MSBuild.MSBuildWorkspace.<OpenSolutionAsync>d__18.MoveNext()
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
   at System.Threading.Tasks.Task`1.get_Result()

[sharwell]

Your additional notes covering workarounds is very helpful. In light of those, I think your Expected Behavior is a reasonable expectation for this case, but I could be missing something since it's not my primary area. Someone else will be around soon to assign this to a particular team (one of the Area-* labels).

:memo: My only edit was to the formatting of the stack trace

[Pilchie]

Tagging @mattwar for historical context.

[abhijitparkhi1983]

@pilchie any updates on this thread?

[dotMorten]

Even worse, now that I upgraded my projects to VS2017, I'm currently getting the same problem with shared projects that uses C#. Now it doesn't know .shproj files, which it had no problem with when it was a 2015 project.