Failure loading Import from csproj

[jfmcbrayer]

Possibly related to #202.

I'm having a problem with loading an MSBuild solution (a .NET MVC 5 project, .sln file and .csproj files generated by VS 2015).

I am running v1.20.0 of omnisharp-roslyn, from the build omnisharp-win-x64-netcoreapp1.1.zip (I should possibly be using omnisharp-win-x64-net46.zip, but it crashes emacs when loaded by omnisharp-emacs).

It is choking on this line in SolutionDir/ProjectDir/Project.csproj:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets" />

Producing this error:

<-- OmniSharp server error: The imported project "c:\Users\McBrayJF\Programs\omnisharp-win-x64-netcoreapp1.1\msbuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. [2 times]

omnisharp-emacs is then not able to complete anything, nor find any usages, etc. Removing the line from the .csproj makes everything work, but VS 2015 will add it back whenever it opens it. Omnisharp is clearly looking for that target on the wrong path, but why?

Correct path should be C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets

I'm not 100% sure whether this is an actual omnisharp-roslyn bug, or if I'm simply doing something wrong in an obscure way. I can work around this by setting the environment variable MSBuildExtensionsPath32, but is it possible for there to be a sensible default? Or does that break cross-platform usage?

[DustinCampbell]

Hi! FWIW, you should use omnisharp-win-x64-net64.zip. The .NET Core version of OmniSharp won't be able to run the tasks and targets required to process a .NET Framework project like a WebApplication, since those tasks are intended to be run on Desktop CLR. I don't believe the .NET Core version of MSBuild will even be able to locate the extensions path (as you noted above).

I'm interested in learning why the .NET Framework version of OmniSharp crashes with omnisharp-emacs. @razzmatazz, is this a known issue?

[razzmatazz]

@DustinCampbell
I know that omnisharp-roslyn crashes on macos (and maybe linux?) when --stdio is NOT specified on command line, but that is not that big of a problem since almost everyone uses stdio transport with omnisharp-emacs.

Also, someone has reported this problem (of Emacs crashing on Windows) on Slack some time bfore, I think.. Probably not @jfmcbrayer; — I am not that sure what goes about in emacs (host for omnisharp-emacs) when it crashes on Windows. I am not using one myself (I am on macOS) and couldn't replicate the problem when I tried.

@jfmcbrayer — could you report Emacs crash to omnisharp-emacs repo?

[jfmcbrayer]

Yeah, I'll report it in omnisharp-emacs.

Actually, that is already OmniSharp/omnisharp-emacs#260, which I didn't see before.

[razzmatazz]

@jfmcbrayer I found the cause for emacs host crash on Windows:

• Emacs crash when start omnisharp server on windows omnisharp-emacs#315
• https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27527

Basically when launching a Windows binary emacs will try to sniff it out to check if it is a console app or regular Windows app, or a cygwin exe, etc... and it appears that .NET binaries compiled for x64 trigger that code to crash on a NULL deref somewhere when parsing PE directory on the executable.

The solution is to use the omnisharp-win-x86-net64.zip (NOT x64) binary for now on Windows, OR (preferrably) invoke the recently added M-x omnisharp-install-server command which should setup the server for you. You need to comment out the(setq omnisharp-server-executable-path ..) line in your init.el for the code to pick up the auto-installed server binary.

Otherwise I think this issue can be closed

[jfmcbrayer]

Ahah! omnisharp-install-server does not seem to work on Windows yet. But I will install the x86 binary. Thanks for finding the cause. Perhaps this needs to be added to the documentation before it is closed?

[razzmatazz]

@jfmcbrayer could you check why omnisharp-install-server does not work for you? I would really like to have it working for everyone..

I have just (yesterday) added an implementation of omnisharp-install-server for Windows (that requires PowerShell v5 to be installed, though it — present by default on Windows 10, and must be installed manually on 7+). It is available on melpa (not on stable.melpa.org, though):

• https://melpa.org/#/omnisharp

Can you paste the contents of *Messages* buffer on your emacs that are emitted on M-x omnisharp-install-server?

I think I mentioned the issue with 64bit binaries on emacs/windows in README.md for this project site, it should be there.. Or did I miss something?

[jfmcbrayer]

It's just that my omnisharp-emacs is not that up-to-date. Did not update from melpa this morning.

omnisharp: sorry, omnisharp-install-server does not support windows-nt yet, please see https://github.com/OmniSharp/omnisharp-emacs/blob/master/README.md#installation-of-the-omnisharp-roslyn-server-application

[razzmatazz]

@jfmcbrayer it should there already by now..

[DustinCampbell]

Just wanted to check in on this issue. Has everything been addressed? Can we close this now?

[razzmatazz]

@DustinCampbell emacs crash should be resolved, don't know about the other issue with failed Import; @jfmcbrayer ?

[jfmcbrayer]

The failed import was due to using the wrong OmniSharp package to avoid the emacs crash. So I think it can be closed, though some documentation might be a good idea.

[razzmatazz]

the standard install procedure via M-x omnisharp-install-server will avoid 64bit version for older emacs versions. so i think it is ok..