Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CSProj Loading Error #661

Closed
wjk opened this issue Nov 6, 2016 · 33 comments
Closed

CSProj Loading Error #661

wjk opened this issue Nov 6, 2016 · 33 comments
Assignees
@DustinCampbell
Labels
fixed

Comments

@wjk
Copy link

wjk commented Nov 6, 2016

When I try to load a fairly-simple tree of csproj files (private repo, though I can tell you it is a fairly simple port of PowerShell), the following exception is thrown (original, unedited transcript):

Starting OmniSharp server at 11/5/2016, 10:50:13 PM
    Target: /Volumes/Sources/SunburstApps/src/PowerShell

OmniSharp server started wth Mono
    Path: /Users/wjk/.vscode/omnisharp~netcoreapp10/OmniSharp
    PID: 14713

OmniSharp: -s /Volumes/Sources/SunburstApps/src/PowerShell --hostPID 14667 DotNet:enablePackageRestore=false --encoding utf-8 --stdio
[INFORMATION:OmniSharp.Startup] Omnisharp server running using Stdio at location '/Volumes/Sources/SunburstApps/src/PowerShell' on host 14667.
[INFORMATION:OmniSharp#MSBuild] No solution files found in '/Volumes/Sources/SunburstApps/src/PowerShell'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/tools/TypeCatalogGen/TypeCatalogGen.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/tools/Microsoft.PowerShell.ResGen/Microsoft.PowerShell.ResGen.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/tools/Microsoft.PowerShell.BuildDependencies/Microsoft.PowerShell.BuildDependencies.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/System.Management.Automation/System.Management.Automation.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/powershell-win/powershell.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/powershell-unix/powershell.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.WSMan.Runtime/Microsoft.WSMan.Runtime.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.WSMan.Management/Microsoft.WSMan.Management.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PowerShell.Security/Microsoft.PowerShell.Security.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PowerShell.PSReadLine/Microsoft.PowerShell.PSReadLine.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PowerShell.PackageManagement/Microsoft.PowerShell.PackageManagement.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PowerShell.LocalAccounts/Microsoft.PowerShell.LocalAccounts.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PowerShell.CoreCLR.Eventing/Microsoft.PowerShell.CoreCLR.Eventing.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PowerShell.CoreCLR.AssemblyLoadContext/Microsoft.PowerShell.CoreCLR.AssemblyLoadContext.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PowerShell.ConsoleHost/Microsoft.PowerShell.ConsoleHost.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PowerShell.Commands.Utility/Microsoft.PowerShell.Commands.Utility.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PowerShell.Commands.Management/Microsoft.PowerShell.Commands.Management.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PowerShell.Commands.Diagnostics/Microsoft.PowerShell.Commands.Diagnostics.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PackageManagement.NuGetProvider/Microsoft.PackageManagement.NuGetProvider.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PackageManagement.MetaProvider.PowerShell/Microsoft.PackageManagement.MetaProvider.PowerShell.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PackageManagement.CoreProviders/Microsoft.PackageManagement.CoreProviders.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PackageManagement.ArchiverProviders/Microsoft.PackageManagement.ArchiverProviders.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.PackageManagement/Microsoft.PackageManagement.csproj'
[INFORMATION:OmniSharp#ProjectFileInfo] Using toolset 15.0 for '/Volumes/Sources/SunburstApps/src/PowerShell/src/Microsoft.Management.Infrastructure.CimCmdlets/Microsoft.Management.Infrastructure.CimCmdlets.csproj'
[ERROR:OmniSharp.Startup] The project system 'MSBuildProjectSystem' threw exception during initialization.
'System.Management.Automation' is already referenced.
   at Microsoft.CodeAnalysis.Workspace.CheckProjectDoesNotHaveProjectReference(ProjectId fromProjectId, ProjectReference projectReference)
   at Microsoft.CodeAnalysis.Workspace.OnProjectReferenceAdded(ProjectId projectId, ProjectReference projectReference)
   at OmniSharp.MSBuild.MSBuildProjectSystem.UpdateProjectReferences(Project project, IList`1 projectReferences) in /Volumes/Sources/Third-Party/omnisharp-roslyn/src/OmniSharp.MSBuild/MSBuildProjectSystem.cs:line 397
   at OmniSharp.MSBuild.MSBuildProjectSystem.UpdateProject(ProjectFileInfo projectFileInfo) in /Volumes/Sources/Third-Party/omnisharp-roslyn/src/OmniSharp.MSBuild/MSBuildProjectSystem.cs:line 310
   at OmniSharp.MSBuild.MSBuildProjectSystem.Initalize(IConfiguration configuration) in /Volumes/Sources/Third-Party/omnisharp-roslyn/src/OmniSharp.MSBuild/MSBuildProjectSystem.cs:line 91
   at OmniSharp.Startup.Configure(IApplicationBuilder app, IServiceProvider serviceProvider, IOmnisharpEnvironment env, ILoggerFactory loggerFactory, ISharedTextWriter writer, IOmnisharpAssemblyLoader loader, IOptions`1 optionsAccessor) in /Volumes/Sources/Third-Party/omnisharp-roslyn/src/OmniSharp.Host/Startup.cs:line 183
[INFORMATION:OmniSharp.Startup] Configuration finished.
[INFORMATION:OmniSharp.Middleware.LoggingMiddleware] /currentfilemembersastree: 200 64ms

Several projects reference System.Management.Automation.csproj, both directly and indirectly. (I have to duplicate the references across many different projects because MSBuild <ProjectReference>s are not transitive.) What's strange is that this error only shows up after the very last project is loaded, Microsoft.Management.Infrastructure.CimCmdlets. If it was a problem about the DLL being added to the workspace too many times, it ought to occur at the time it is added the second time (by my observation, that would probably be during the loading of Microsoft.PowerShell.Security.csproj).

I would prepare a PR that prevents the adding of duplicate projects to the workspace, except that I cannot easily write any C# in VSCode right now because of omnisharp-vscode#836 et al. (As a developer, I am very dependent on the correct functioning of my IntelliSense. When it malfunctions, I have a very hard time writing any code at all.)
@DustinCampbell
Copy link
Contributor

It appears that a netcoreapp1.0 version of OmniSharp is being used to open .csproj files. This isn't very functional today. It seems like you've downloaded OmniSharp and set the "omnisharp.path" setting in VS Code, correct? If these are standard .csproj proejcts that target a .NET desktop framework you might have more luck downloading a Mono version of OmniSharp instead of the netcoreapp1.0 version for this particular project.

@wjk
Copy link
Author

wjk commented Nov 10, 2016

@DustinCampbell I actually forgot to mention that these are Core projects. In addition, yes, I have set the omnisharp.path VSCode setting. The main reason I did this is because if I use the bundled copy of OmniSharp, it emits errors while trying to load the Core csproj files. The same error is given on every project; I have reproduced one below:

[ERROR:OmniSharp#ProjectFileInfo] The "ResolvePackageDependencies" task failed unexpectedly.
System.TypeLoadException: Could not load type 'NuGet.Common.INuGetPathContext' from assembly 'NuGet.Common, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.get_PackageResolver()
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.ResolvePackagePath(LockFileLibrary package)
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageAndFileDefinitions()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__25.MoveNext()

I have built a custom copy of OmniSharp (following these directions) to avoid these errors.

@DustinCampbell
Copy link
Contributor

OK. That makes sense. Yeah, that error is going to be expected because that task requires a newer version of NuGet than what is bundled with OmniSharp. You might want to try the new release preview release I just put out https://github.com/OmniSharp/omnisharp-vscode/releases/tag/v1.5-future-preview1. This includes at least initial support for MSBuild-based .NET Core projects.

@wjk
Copy link
Author

wjk commented Nov 10, 2016

Well, that didn't work. I now get this exception on every project:

Microsoft.Build.Exceptions.InvalidToolsetDefinitionException: Error reading the toolset information from the configuration file "System.Configuration (6)". Unrecognized configuration section <startup> ---> System.Configuration.ConfigurationErrorsException: Unrecognized configuration section <startup> (/Users/wjk/.vscode/extensions/ms-vscode.csharp-1.5.0-future-preview1/bin/omnisharp/MSBuild.dll.config line 6)
  at System.Configuration.ConfigInfo.ThrowException (System.String text, System.Xml.XmlReader reader) [0x00007] in <42f076b78acf4ebd9ea481aca766b25b>:0 
  at System.Configuration.SectionGroupInfo.ReadContent (System.Xml.XmlReader reader, System.Configuration.Configuration config, System.Boolean overrideAllowed, System.Boolean root) [0x00170] in <42f076b78acf4ebd9ea481aca766b25b>:0 
  at System.Configuration.SectionGroupInfo.ReadRootData (System.Xml.XmlReader reader, System.Configuration.Configuration config, System.Boolean overrideAllowed) [0x00007] in <42f076b78acf4ebd9ea481aca766b25b>:0 
  at System.Configuration.Configuration.ReadConfigFile (System.Xml.XmlReader reader, System.String fileName) [0x000ec] in <42f076b78acf4ebd9ea481aca766b25b>:0 
  at System.Configuration.Configuration.Load () [0x00052] in <42f076b78acf4ebd9ea481aca766b25b>:0 
  at System.Configuration.Configuration.Init (System.Configuration.Internal.IConfigSystem system, System.String configPath, System.Configuration.Configuration parent) [0x00065] in <42f076b78acf4ebd9ea481aca766b25b>:0 
  at System.Configuration.Configuration..ctor (System.Configuration.InternalConfigurationSystem system, System.String locationSubPath) [0x0005c] in <42f076b78acf4ebd9ea481aca766b25b>:0 
  at System.Configuration.InternalConfigurationFactory.Create (System.Type typeConfigHost, System.Object[] hostInitConfigurationParams) [0x0000e] in <42f076b78acf4ebd9ea481aca766b25b>:0 
  at System.Configuration.ConfigurationManager.OpenMappedExeConfiguration (System.Configuration.ExeConfigurationFileMap fileMap, System.Configuration.ConfigurationUserLevel userLevel) [0x00005] in <42f076b78acf4ebd9ea481aca766b25b>:0 
  at Microsoft.Build.Evaluation.ToolsetConfigurationReader.ReadApplicationConfiguration () [0x00036] in <1be2c21a97cd402db77c8e905b7fd466>:0 
  at Microsoft.Build.Evaluation.ToolsetConfigurationReader.get_ConfigurationSection () [0x00019] in <1be2c21a97cd402db77c8e905b7fd466>:0 
   --- End of inner exception stack trace ---
  at Microsoft.Build.Exceptions.InvalidToolsetDefinitionException.Throw (System.Exception innerException, System.String resourceName, System.String[] args) [0x0001b] in <1be2c21a97cd402db77c8e905b7fd466>:0 
  at Microsoft.Build.Evaluation.ToolsetConfigurationReader.get_ConfigurationSection () [0x00067] in <1be2c21a97cd402db77c8e905b7fd466>:0 
  at Microsoft.Build.Evaluation.ToolsetConfigurationReader+<>c__Iterator0.MoveNext () [0x00024] in <1be2c21a97cd402db77c8e905b7fd466>:0 
  at Microsoft.Build.Evaluation.ToolsetReader.ReadEachToolset (System.Collections.Generic.Dictionary`2[TKey,TValue] toolsets, Microsoft.Build.Collections.PropertyDictionary`1[T] globalProperties, Microsoft.Build.Collections.PropertyDictionary`1[T] initialProperties, System.Boolean accumulateProperties) [0x00057] in <1be2c21a97cd402db77c8e905b7fd466>:0 
  at Microsoft.Build.Evaluation.ToolsetReader.ReadToolsets (System.Collections.Generic.Dictionary`2[TKey,TValue] toolsets, Microsoft.Build.Collections.PropertyDictionary`1[T] globalProperties, Microsoft.Build.Collections.PropertyDictionary`1[T] initialProperties, System.Boolean accumulateProperties, System.String& msBuildOverrideTasksPath, System.String& defaultOverrideToolsVersion) [0x0000c] in <1be2c21a97cd402db77c8e905b7fd466>:0 
  at Microsoft.Build.Evaluation.ToolsetReader.ReadAllToolsets (System.Collections.Generic.Dictionary`2[TKey,TValue] toolsets, Microsoft.Build.Evaluation.ToolsetRegistryReader registryReader, Microsoft.Build.Evaluation.ToolsetConfigurationReader configurationReader, Microsoft.Build.Collections.PropertyDictionary`1[T] environmentProperties, Microsoft.Build.Collections.PropertyDictionary`1[T] globalProperties, Microsoft.Build.Evaluation.ToolsetDefinitionLocations locations) [0x00044] in <1be2c21a97cd402db77c8e905b7fd466>:0 
  at Microsoft.Build.Evaluation.ProjectCollection.InitializeToolsetCollection (Microsoft.Build.Evaluation.ToolsetRegistryReader registryReader, Microsoft.Build.Evaluation.ToolsetConfigurationReader configReader) [0x00020] in <1be2c21a97cd402db77c8e905b7fd466>:0 
  at Microsoft.Build.Evaluation.ProjectCollection..ctor (System.Collections.Generic.IDictionary`2[TKey,TValue] globalProperties, System.Collections.Generic.IEnumerable`1[T] loggers, System.Collections.Generic.IEnumerable`1[T] remoteLoggers, Microsoft.Build.Evaluation.ToolsetDefinitionLocations toolsetDefinitionLocations, System.Int32 maxNodeCount, System.Boolean onlyLogCriticalEvents) [0x0012b] in <1be2c21a97cd402db77c8e905b7fd466>:0

@DustinCampbell
Copy link
Contributor

Whoa -- what OS are you using? OSX?

@DustinCampbell
Copy link
Contributor

Also, could you share one of the project files?

@wjk
Copy link
Author

wjk commented Nov 10, 2016

Yeah, OSX. Here is a sample project file, as well.

@DustinCampbell
Copy link
Contributor

Hmmm... this works for me on OSX (Sierra) with a newly created .NET Core project using the latest CLI. The project isn't all that different:

<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>

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

  <ItemGroup>
    <PackageReference Include="Microsoft.NETCore.App">
      <Version>1.0.1</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.NET.Sdk">
      <Version>1.0.0-alpha-20161104-2</Version>
      <PrivateAssets>All</PrivateAssets>
    </PackageReference>
  </ItemGroup>

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

And I'm scratching my head a bit at why System.Configuration might throw. The MSBuild.dll.config file should look like the following and I don't see anything controversial there. Hmmm...

<?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <configSections>
      <section name="msbuildToolsets" type="Microsoft.Build.Evaluation.ToolsetConfigurationSection, Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    </configSections>
    <startup useLegacyV2RuntimeActivationPolicy="true">
      <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" />
    </startup>
    <runtime>
      <DisableFXClosureWalk enabled="true" />
      <generatePublisherEvidence enabled="false" />
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity name="Microsoft.Build.Framework" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
          <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity name="Microsoft.Build" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
          <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity name="Microsoft.Build.Conversion.Core" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
          <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity name="Microsoft.Build.Tasks.Core" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
          <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity name="Microsoft.Build.Utilities.Core" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
          <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
        </dependentAssembly>
        <dependentAssembly>a
          <assemblyIdentity name="Microsoft.Build.Engine" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
          <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity name="Microsoft.Build.Conversion.Core" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
          <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity name="Microsoft.Activities.Build" culture="neutral" publicKeyToken="31bf3856ad364e35" />
          <bindingRedirect oldVersion="4.0.0.0" newVersion="15.0.0.0" />
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity name="XamlBuildTask" culture="neutral" publicKeyToken="31bf3856ad364e35" />
          <bindingRedirect oldVersion="4.0.0.0" newVersion="15.0.0.0" />
        </dependentAssembly>
      </assemblyBinding>
    </runtime>
    <!-- To define one or more new toolsets, add an 'msbuildToolsets' element in this file. -->
    <msbuildToolsets default="15.0">
      <toolset toolsVersion="15.0">
        <property name="MSBuildRootWorkaround704" value="$([MSBuild]::GetCurrentExecutableDirectory())" />
        <!-- See https://github.com/Microsoft/msbuild/issues/704 -->
        <property name="MSBuildToolsPath" value="." />
        <property name="MSBuildToolsPath32" value="$(MSBuildToolsPath)" />
        <property name="MSBuildToolsPath64" value="$(MSBuildToolsPath)\amd64" />
        <property name="MSBuildRuntimeVersion" value="4.0.30319" />

        <property name="TargetFrameworkRootPathSearchPathsOSX" value="/Library/Frameworks/Mono.framework/External/xbuild-frameworks/" />
        <projectImportSearchPaths>
          <searchPaths os="windows">
            <property name="MSBuildExtensionsPath" value="$(MSBuildProgramFiles32)\MSBuild"/>
            <property name="MSBuildExtensionsPath32" value="$(MSBuildProgramFiles32)\MSBuild"/>
            <property name="MSBuildExtensionsPath64" value="$(MSBuildProgramFiles32)\MSBuild"/>
          </searchPaths>

          <searchPaths os="osx">
            <property name="MSBuildExtensionsPath" value="/Library/Frameworks/Mono.framework/External/xbuild/"/>
            <property name="MSBuildExtensionsPath32" value="/Library/Frameworks/Mono.framework/External/xbuild/"/>
            <property name="MSBuildExtensionsPath64" value="/Library/Frameworks/Mono.framework/External/xbuild/"/>
          </searchPaths>
        </projectImportSearchPaths>
      </toolset>
    </msbuildToolsets>
  </configuration>

@wjk
Copy link
Author

wjk commented Nov 10, 2016

I can't find the MSBuild.exe.config file. Where would it be located? Furthermore, I am using a copy of Mono installed using Homebrew, not from any official Mono or Xamarin installer. Therefore, /Library/Frameworks/Mono.framework doesn’t exist on my system. However, seeing as OmniSharp downloads its own private copy of Mono, this shouldn't affect anything.

@DustinCampbell
Copy link
Contributor

It's MSBuild.dll.config in the MSBuild xplat builds.

Yeah, I wouldn't expect that to affect anything. It shouldn't actually be looking there for anything anyway.

@wjk
Copy link
Author

wjk commented Nov 10, 2016

Yeah, but where would I find that on my system? I want to verify that its contents match the example above. In addition, updating .NET CLI (to version 1.0.0-preview4-004071) doesn’t change anything.

@DustinCampbell
Copy link
Contributor

According to the exception you got, it should be in /Users/wjk/.vscode/extensions/ms-vscode.csharp-1.5.0-future-preview1/bin/omnisharp/MSBuild.dll.config

@DustinCampbell
Copy link
Contributor

I got a repro

@wjk
Copy link
Author

wjk commented Nov 10, 2016

BTW, my MSBuild.dll.config exactly matches yours.

@DustinCampbell
Copy link
Contributor

FYI, I'm getting closer on this. I'll let you know when I have a solution

@DustinCampbell
Copy link
Contributor

All right I've got a solution. I need to package it up again and provide you with instructions on how to try again once it's ready.

@DustinCampbell
Copy link
Contributor

OK. If you still have the preview installed, try the following:

  1. Close Visual Studio Code
  2. In the terminal window enter the following:
cd /Users/wjk/.vscode/extensions/ms-vscode.csharp-1.5.0-future-preview1/
rm -rf bin
rm install.lock

Now, open Visual Studio Code and load your project. Fingers crossed!

@DustinCampbell DustinCampbell mentioned this issue Nov 10, 2016
Closed
@DustinCampbell DustinCampbell self-assigned this Nov 10, 2016
@wjk
Copy link
Author

wjk commented Nov 10, 2016

It works! Thank you so much! What exactly was the cause of this, by the way?

@DustinCampbell
Copy link
Contributor

Well, it nearly caused me to lose my remaining hair.

The problem was that I did not include the machine.config file that is necessary to let the whole System.Configuration system work. The error was completely correct. <startup> really was unrecognized -- because it wasn't defined anywhere.

@wjk
Copy link
Author

wjk commented Nov 10, 2016

And I am still having problems. I see “0 projects” in the VSCode status bar, and my intellisense is broken. (If I restart OmniSharp, it appears to be functional, but as soon as I start typing something it dies; the completion list simply says “Loading” and the “# references” lines in the editor vanish.) Furthermore, the OmniSharp log still displays the error about System.Management.Automation being referenced twice.

@wjk
Copy link
Author

wjk commented Nov 10, 2016

Note that when I place my cursor on a symbol and press F12, the OmniSharp log displays the following error:

[ERROR:Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware] An unhandled exception has occurred: A task was canceled.
[INFORMATION:OmniSharp.Middleware.LoggingMiddleware] /gotoDefinition: 500 2275ms

This might have something to do with the broken intellisense.

@DustinCampbell
Copy link
Contributor

The "0 projects" issue is here: dotnet/vscode-csharp#835

@DustinCampbell
Copy link
Contributor

Are you able to add me to your repo? If so, I'll take a look. I'd like to get this working for you.

@wjk
Copy link
Author

wjk commented Nov 10, 2016

@DustinCampbell I’ve just sent you an invite to wjk/SunburstApps.

@DustinCampbell
Copy link
Contributor

thanks. I'll try it out and see if I can't get some fixes for you.

@wjk
Copy link
Author

wjk commented Nov 10, 2016 •
edited
Loading

@DustinCampbell I’ve removed your push access from wjk/SunburstApps, because you don’t need it anymore; I have opened the repository up to all contributors. Feel free to send in PRs, though!

@DustinCampbell
Copy link
Contributor

Sounds good. I've cloned the project and am working through issues.

@DustinCampbell
Copy link
Contributor

OK. I see why your getting that duplicate reference. Should be easy to fix.

@DustinCampbell
Copy link
Contributor

Note: the reason duplicate references are being added is because it's defined that way in your projects. Both powershell-unix/powershell.csproj and powershell-win/powershell.csproj reference System.Management.Automation.csproj and they both import Microsoft.PowerShell.SDK.targets which also adds the same reference again. OmniSharp should have been resilient against this case but it wasn't.

@wjk
Copy link
Author

wjk commented Nov 10, 2016

That did it, all right. The duplicate-reference error is gone.

@DustinCampbell
Copy link
Contributor

I'll have a real fix coming for you soon. The duplicate reference shouldn't be something you have to manage.

@wjk
Copy link
Author

wjk commented Nov 10, 2016

Nonetheless, thank you very, very much. I would never have found it on my own. Thank you!

@DustinCampbell
Copy link
Contributor

OK. I've updated the binaries again with a couple of fixes. You can refresh them by doing the following:

  1. Close Visual Studio Code
  2. In the terminal window enter the following:
cd /Users/wjk/.vscode/extensions/ms-vscode.csharp-1.5.0-future-preview1/
rm -rf bin
rm install.lock

There are still several bugs lingering, but I'm going to resolve this one because I think we've gotten to the heart of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@DustinCampbell DustinCampbell

Labels
fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@DustinCampbell @wjk