v1.0.10 doesn't download 32-bit OmniSharp binaries on 32-bit machines

[markgarcia]

To clarify, it does download but 64 bit files.

https://github.com/OmniSharp/omnisharp-vscode/blob/master/src/omnisharpDownload.ts only has x64 download links.

Is this a temporary situation? If so, when can we expect to have 32 bit support?

[DustinCampbell]

Honestly @markgarcia, we've had nearly 200k downloads of the extension and yours is the first request for 32-bit Windows support. 😄

Updating the extension to pick the x86 binaries is not challenging. However, you also mentioned in Slack that the x86 OmniSharp builds contain 64-bit binaries. Our initial investigation (also in Slack) looks like this might actually be a .NET CLI issue. We'll take a look.

[chuckries]

Just a heads up, debugging is currently only supported for 64 bit as well.

[DustinCampbell]

Thanks for the heads up @chuckries.

[markgarcia]

@DustinCampbell I'm willing and happy to help. Going bleeding edge on an old machine sure is interesting sometimes.

[DustinCampbell]

😄

[hal-ler]

Referencing issue to help with tracking OmniSharp/omnisharp-roslyn#558

[asztalosb]

Any progress on this?
(Just checking in to show that @markgarcia isn't the only one who develops on a 32-bit machine. :) )

[markgarcia]

@asztalosb high five Currently I'm building omnisharp-roslyn myself as drop-in replacement for use by the C# extension. Works like a charm, though I try to use OmniSharp releases that match the ones used by the C# extension. I do hope they get on this on the next release, and I imagine running a build on a 32-bit VM should be easy.

[Schlicki2808]

Same problem here! The point is not that we are using "old" machines, but some devices cannot run 64-bit windows (I want to develop on an Intel Atom based device which only runs 32-bit windows), so it would be nice if x86 components will be loaded if I am using x86 DotNET Core.

[Eraph]

Another developer with an Atom machine here.

[kepeter]

Hi,
I just got the same issue (and actually reported on the vscode issue page)...
Using a low resource, old machine while checking out new technologies is a good idea... While we, developers, used to have cutting edge machines it is not the case with the end users...
In any case, the real problem is that you can not add a 64 bit only extension to a 32 bit installation... You can decide, that 32 bit not supported and we will make our decisions, but the current state is no good... :-)

Regards,
Peter

[Fetandrey]

+1
I would also like to see a 32 bit Windows support

[JDemortier]

I'm also using an atom based computer when working in the train, seems quite difficult to avoid using Visual Studio right now...

[mcquiggd]

Another Atom based laptop user here, just hit this problem.

Very surprised at the lack of 32 bit Windows support... for something intended to be cross-platform.

[gogolevsergey]

Why x86 support is disabled? I have tried to change "%USERPROFILE%.vscode\extensions\ms-vscode.csharp-1.4.1\coreclr-debug\project.json" runtime to "win7-x86". Build was succesfull, but it doesn't helps. I am also on Atom with 32 bit Windows 10.

[mcquiggd]

Ok, inspired by @markgarcia `s comment earlier in this thread

I revisited this again this morning, and built Omnisharp on my Dell Venue Pro 11 (Atom based, Win 10 x86).

To do this, I cloned the OmniSharp.Roslyn repository.

Initially when attempting to build, OmniSharp.Abstractions threw up a lot of errors regarding .Net Framework 4.5.1 reference libraries.

I attempted to install .Net Framework 4.5.1, but the installer claimed that version was already installed.

Following advice found here, I copied over

C:\Program Files\Reference Assemblies\Microsoft\Framework.NETFramework\v4.6.1

to

C:\Program Files\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.1

The Omnisharp project built successfully.

Next, to get VS Code to recognise it, I opened File > Preferences > Workspace Settings, and in the automatically created settings.json, entered the following path to where I had the Omnisharp build output.

"csharp.omnisharp": "C:\\OmniSharp\\default\\netcoreapp1.0\\Omnisharp.exe"

Now Omnisharp started complaining about paths, and failed to start. This was overcome by adding the following to the project.json, under publish options:

"exclude": "node_modules"

And finally, success. Omnisharp provides intelisense, suggests and executes fixes, shows the light bulb etc.

But, no luck with debugging, which does seems to be x64 only, as previously mentioned. Everything starts, but after compilation, the debug control bar appears, but subsequently nothing happens, and all that is displayed is the blue "doing something" indicator.

[SergioMorchon]

Yet another 32-bit user here! If there is no cost in build Omnisharp for 32-bit, it would be very helpful.

[DustinCampbell]

FWIW, I've updated OmniSharp to include a build that works on 32-bit Windows. Until we get the C# extension updated to take advantage of it, you should be able to do the following:

• Download and unzip omnisharp-win-x86-net46.zip from the latest OmniSharp release.
• In VS Code, select Preferences->User Settings to open settings.json.
• In settings.json, add the following line:

"omnisharp.path": "C:\\path\\that\\you\\just\\unzipped\\to\\OmniSharp.exe

Be sure to update the path in the line above and remove any setting for "csharp.omnisharp" if you have one.

[mcquiggd]

@DustinCampbell

All progress is welcome... we 32 bit Windows users were feeling a little unloved... :)

My understanding is that the 'official x86 Omnisharp release' was removed from the downloads due to issues with the related debugging of dot net core only supporting 64 bit.

@sayedihashimi - Sayed, I don't suppose you could enlighten us regarding plans to release 32 bit support for dot net core debugging, or who might be able to...?

David

[DustinCampbell]

@mcquiggd: I just fixed the official x86 OmniSharp release. 😄

[DustinCampbell]

You're right that .NET Core debugging does not work on 32 bit. However, that is orthogonal to OmniSharp working. The x86 OmniSharp release wasn't removed because of debugging. That was more of a justification for not prioritizing (i.e. "well, debugging doesn't work, so it's probably OK that IntelliSense doesn't work... 😄).

FWIW, @sayedihashimi doesn't own .NET Core debugging for VS Code. @gregg-miskelly could chime in though.

[gregg-miskelly]

I am not sure what to say other than - yup, the debugger currently doesn't support 32-bit Windows. Its not all that small of a work item for us, so we haven't found time to implement support. Visual Studio has support though, so that is what I would recommend.

[DustinCampbell]

True. VS Community is definitely an option for 32-bit Windows.

[mcquiggd]

Hmm.

A great shame, as an Atom or similar low spec laptop with Win32 is probably the ideal use case for VS Code rather than Visual Studio (even Community).

Microsoft pushes VS Code for developing ASP.Net Core / SPAs etc, and the workflow is actually better in VS Code in many such cases.

These days it's getting frustrating that Microsoft prioritises other platforms rather than its own products (yes, I have a Windows Phone too...)

I guess that's why all the ASP.Net Core team have iPhones, and all demos are done on a Macbook rather than anything running a Microsoft OS... ;)

[gregg-miskelly]

Just to be clear -

• Its not 100% fair to say that we are prioritizing other platforms in this particular case -- we have no support at all for 32-bit Linux (macOS too, but I am not sure 32-bit macOS is even a thing), as an example. On 32-bit Windows the runtime and framework work. We also have, IMHO, the world's best IDE. We just haven't yet found time to also provide support for VS Code.
• We are definitely NOT trying to push VS Code over VS on Windows. If folks want to use VS Code, that's great, and for folks who want super thin editor - use it. But VS is our flagship product. If you, like me, really love having an IDE -- stay with VS. You certainly may see some Microsoft folks who really like the thin editor experience, but that is certainly not everyone, and VS is not going away.
• Most VS Code demos (and some .NET Core demos) are likely going to be on a Mac because we are trying to show off the fact that we finally have offerings there. But that doesn't mean we don't care about Windows. Its just that in the VS Code case, for the first time ever, we don't care more about Windows than we do other platforms -- we are trying to make everything work.

[Eraph]

I for one am grateful for everyone's efforts here. Keep up the good work! 👍

[mcquiggd]

@gregg-miskelly

Well, if I hit a nerve, that was not my intention. That is what I read, and see, and work around.

Still, keeping on subject, I think its interesting that Visual Studio itself is 32 bit, and can run on 32 bit Windows, and can debug .Net Core. It has its own separately developed debugger for .Net Core? Would be interesting to hear more on this...

@Eraph Seconded ;)

[ghost]

And another x86 user here, signing in.

[gregg-miskelly]

@mcquiggd no worries, and I definitely wasn't offended. I just wanted to try and be clear that from Microsoft's perspective you should NOT think of VS Code as the new fancy version of VS that deprecates the old thing (like Microsoft has a tendency to do). In this case, VS Code is another choice meant to fit the needs of folks that maybe VS wasn't a good fit for - folks on non-Windows, or folks who like lighter weight tools. But VS is very much alive, maintained, and, IMHO, a great product.

Probably 90% of the code in the VS Code debugger is shared with full VS. But how it connects to the UI, the system we use to build the code, and how we package up and get the debugger to your computer all different. These are the systems that we need to fix to support 32-bit Windows and thus far there has been other work that has taken precedence.

[Fetandrey]

@gregg-miskelly
The problem with Visual Studio is that it weights a lot and you can't even install it on any other partition except your system drive. And if your PC has only 32 GB of internal memory this can be a real problem.

[JDemortier]

@Fetandrey
Exactly my problem. But Microsoft seems to be aware of it, as VS '15' preview 5 is quite a lightweight compared to previous versions of VS.

[DustinCampbell]

Yes, that problem is somewhat orthogonal and being worked on separately. VS has definitely gotten very big over the years!

[mcquiggd]

@gregg-miskelly

Thanks, that makes sense regarding the interaction with a debugging host...

And, same as everyone else; Visual Studio is a substantial chunk of limited SSD space. VS Code would be ideal. And I take your point about Visual Studio, but, that is not the whole story as portrayed by Microsoft`s Developer Evangelists and famous people named Scott, for example ;)

The appeal of VS Code is not just that it is lightweight, but also it has an active community providing useful extensions for development with front end technologies, that not even Mads Kristensen can keep up with in Visual Studio ;). This is the beneficial side effect of having opened up a tool that open source web devs appreciate. Virtually everything is folder based, CLI based, and this is where VS Code beats Visual Studio hands down. I use both, of course.

So its unfortunate to be sitting on the train during a two hour commute, and not able to fully use the ideal tool for developing on low SSD capacity devices. And many devs go for ARM not because they are cheap, but for battery life that lasts a full working day.

[gregg-miskelly]

I opened #844 to track fixing the debugger (since this bug is for the language service)

[mcquiggd]

@gregg-miskelly

Excellent, thanks for being responsive...

[Fetandrey]

@JDemortier
Thank you for bringing this to my attention, but there are some issues I'm experiencing with it.

[Fetandrey]

@DustinCampbell
This workaround doesn't work. Omnisharp is running, but when I try to run my program, it throws the same 'Debug adapter process has terminated unexpectedly' error. The dotnet run command works though, but it worked without the workaround too.

[DustinCampbell]

@Fetandrey: My change only affects OmniSharp, and hence, only editor features like IntelliSense, find all references, etc. will work. The debugger is entirely different matter. Please see @gregg-miskelly's comments above about the debugger.

[markgarcia]

@DustinCampbell @gregg-miskelly Thank you very much for these. I've yet to try .NET debugging on VS Code and the only reason for not doing so is 32-bit debugging support (I use VS 2015 on my primary dev machine). I think having it would make me love this little Atom machine so much more.

Anyhow, now that Intellisense is back I wouldn't worry so much about needing to hit the debugger as static analysis saves me in a lot of ways. 😄

[DustinCampbell]

This is fixed for the C# editor in the 1.5 release of the extension. 32-bit debugging is being tracked with #844.

[ghost]

@DustinCampbell The debugger still doesn't work for x86 even after downloading your fixed version of ominsharp and adding this to my settings.json -> "omnisharp.path": "E:\omnisharp-win-x86-net46\OmniSharp.exe". The debugger controls appear and again the error appears "The .NET Core Debugger is still being downloaded. See the C# Output Window for more information.". Please let me know if I am missing anything!!

[DustinCampbell]

Yes, the debugger is a different component that OmniSharp and does not support x86 on Windows.