Visual Studio for Mac Preview | Hacker News Reader

Visual Studio for Mac Preview

visualstudio.com

397 pointsclbrook144 comments

FWIW, this is actually a rebranding of Xamarin Studio, so it only handles C# and F#. It's a bit puzzling, as VSCode seemed to be the tool that was going to take over all the Xamarin Studio features.

XS/MonoDevelop worked with Visual Basic last time I tried it, so perhaps VS for Mac will as well?

If I had to really take a guess here, this is what I'd speculate.

This is only the first step for Visual Studio Mac. The next will be to begin bringing feature parity to the Mac version (My gut feeling is that VB.NET won't make the leap, but with Roslyn, maybe I'm wrong).

I feel this isn't stated enough. VSCode, albeit made by Microsoft, goes way beyond Microsoft's core interests. Given that you can now enable language support for around 470-ish languages, I don't think that their game here is to be a replacement for anything. I have an even crazier suspicion about what VSCode is really about.

So if you've lived with Visual Studio for years, you know that it's been COM based for a looonnnnggg time (since inception). I think VSCode serves two interests. The first interest is to bring non-Microsoft users in the fold with the hopes that they may go "This ain't so bad, maybe I'll give other stuff a try". I think the second is that they need a playground to figure out how to, excuse me here, "unfuck" the core architecture of Visual Studio. If they can write suitable replacements for core functionality, let them bake and mature for some time, then BOOM! they can replace the VS components.

Like I said, just a crazy opinion based on what I've seen so far.

I agree, but would add that I think their core motivation is to drive developers to microsoft azure. I am sure they believe they would love mac users to buy more MS software but targeting non-ms devs this hard seems like they want to compete with AWS && google.

AWS UX is a dumpster fire. Azure was quite nice from what I can tell. I love VS code and am a mac user. I also strongly dislike AWS as it is extremely complex and annoying. If there was amazing tooling, I would consider switching from digital ocean to azure.

I'm currently undergoing a very long evaluation of both products. I agree, the AWS UX is a dumpster fire. Even simple things seem to make no sense, and if I had to guess without checking I'd say they went through a hyper growth of their cloud.

I also agree that their long-play is Azure. You just wait, they'll put a major investment into IntelliJ or Eclipse to make it more Azure friendly too.

Mozilla underwent a process of "DeCOMification", because they went too far with XP/COM, and wanted to dial it way back.

https://bugzilla.mozilla.org/buglist.cgi?query_format=specif...

Can someone link to a synopsis describing what "COM" is? It's hard to search for. (e.g. microsoft com visual studio)

https://en.wikipedia.org/wiki/Component_Object_Model

Yeah, COM and .NET are notoriously tough to Google because of their similarity to TLDs!

I believe that .NET binaries, at least on Windows, are actually built atop COM but I'm not sure. Been a while since I've cared =)

COM = Component Object Model.

https://en.wikipedia.org/wiki/Component_Object_Model

.NET binaries can export COM components (just as C/C++ and other languages may), but are not COM components by themselves.

There is some confusion here because the part of the "export surface" design for .NET binaries/modules was originally designed to replace COM's "interface design language" (IDL) in a version of COM that was never quite finished. Coming back full circle the .NET "export surface" design was indeed recycled for the WinRT component model (the COM replacement of the WinRT/UWP stack) in its library metadata format (.winmd), which to .NET tools look like a .NET binary that is missing all of its (IL) code.

Long story short, .NET was not built on top of COM but parts of it were designed to backwards compatibly replace it/inter-operate with it. (...and then some of those same parts reused in COM's eventual actual replacement.)

com is a windows technology for IPC. https://en.wikipedia.org/wiki/Component_Object_Model

COM is the Component Object Model: https://en.wikipedia.org/wiki/Component_Object_Model

This was how a lot of system and third party libraries provided large amounts of functionality in the windows ecosystem for quite some time. These are usually in the form of a DLL (Dynamic Link Library), libraries of COM components, packaged as a ".dll" file. This is related to the re-use and versioning issues known informally as "DLL hell". Most COM components are native C and C++ based, exposing a standardized COM interface for component reuse.

Dot net was a new ecosystem, but much of the Win32 related dot net API is wrappers over existing native COM components. There are also extensive dot net facilities for repackaging and working with existing COM libraries through a Com Interop layer. https://msdn.microsoft.com/en-us/library/ms173184.aspx

The COM system provided an approach to interoperability and reuse for a long time, but compared to our current generation of cross platform compatibility, the venerable COM system components are proving to be a significant legacy challenge for cross platform implementations.

I don't think COM is going away either, despite the cross platform ideas. The entire Windows system is built on COM, and the new UWP apps are COM apps but they do not inherit directly from IUnknown - they inherit from a child of IUnknown (if only I could remember what the interface is called, sorry).

Why are you speaking in the past tense?

COM usage on Windows only increased after Windows Vista and is at the heart how UWP works and user space drivers.

Yes, good point. It was discussing in past test in the context of "DeCOMification" mainly. It would be interesting to have some insight into new component creation vs use of existing components.

Well it is just plain old COM, with a new base interface IIspectable that inherits from IUnknown and using .NET metadata instead of TLB files.

Using it from C++/CX is quite painless compared with the old ways, as it is quite similar to .NET, Delphi and C++ Builder ways of using COM.

For a little pain ATL style, you can use Windows Runtime Library.

Kenny Kerr and his team are pushing for C++/WinRT, a new C++ projection (language binding), based on pure Modern C++, with the goal to eventually replace C++/CX. Currently WIP, though.

For those that really like to suffer, the old way of using MIDL compiler with C is still possible for UWP applications.

From our projects, I would say most UWP developers use .NET for UWP controls and only resort to C++/CX if integration is C++ code is required.

OMG I feel so old when I read your question. Component Object Model is what it stands for.

Glad you asked! One of my favorite topics. ;)

COM is essentially a formal way of using C++ vtables [1] from C and other languages, so you can create and consume components in any language, and call back and forth between them. It's a way of expressing a rational subset of how C++ classes work and format in memory, in a way that can be implemented in other languages.

It was the outcome of the C / C++ / Visual Basic language wars at Microsoft.

The original 16 bit version of Visual Basic version 1 through 3 had a plug-in extension mechanism called VBX -- Visual Basic Extensions [2].

They were extremely popular and became a victim of their own success, after a whole industry grew up around them, and people started using them for all kinds of things they weren't intended for, and wanted to use them from other languages and frameworks like Borland. Microsoft had to do something about that to mitigate the success disaster of VBX, so they invented COM.

At the time, Microsoft was transitioning from Win16 to Win32, so they came up with the 32 bit COM definition, also known as OCX's, or OLE Controls, which they later called ActiveX, because COM was so hard to search for, and they wanted to take the spotlight away from Java with a new buzzword.

So they brewed up a bunch of ugly C macrology that enabled C programmers (or Visual Studio wizards) to define COM interfaces in header and implementation files that just happened to lay out memory in the exact same way as vtables of C++ pure virtual classes.

While C++ programs would use other ugly macros to declare actual honest-for-god C++ classes to implement COM interfaces.

And Visual Basic programmers would ... do whatever it was that Visual Basic programmers did.

COM's IUnknown::QueryInterface [4] method is essentially like C++'s dynamic_cast [5]. But it also adds some object aggregation features [6] that let you compose multiple sub-objects together by aggregation instead of using monolithic inheritance. You could implement "tear off interfaces" [7] that lazily create aggregated sub-objects on demand, useful for implementing callback interfaces.

MFC (Microsoft Foundation Classes) is a set of C++ wrappers around the lower level Win32 interfaces, plus a huge framework for implementing GUI widgets and dialogs on top of Win32, and for wrapping rube-goldbergesque OLE Automation interfaces around C++ classes. For some time MFC was the primary way of implementing COM interfaces in C++, but it was infamous for being horribly complex, with all its ugly macros, Hungarian notation, and bizarre programming conventions.

Later on Microsoft came out with the C++-only ActiveX Template Library (ATL) [8], which, although it was still necessarily quite ugly, was a more elegant and powerful way of implementing COM components in C++, didn't have the baggage of supporting C, and let you implement COM/OLE/ActiveX components without the hideous MFC framework. ATL was popular for implementing all kinds of Internet Explorer plug-ins.

OLE was actually a layer of COM interfaces and MIDL (Microsoft Interface Definition Language) on top of COM, which adds the IDispatch interface for dynamically querying and invoking methods and properties at runtime, and variant types [9]: tagged unions for representing polymorphic data (i.e. VB data types) and passing parameters to OLE IDispatch functions.

OLE was the glue necessary for integrating COM components into the Visual Basic runtime, so it directly supported Visual Basic data types, calling conventions and semantics like indexed properties.

OLE also provided an interface definition language (ILD) you could compile into binary type libraries, use to generate boilerplate C and C++ interfaces, and OLE also had COM interfaces and structures for providing those type libraries at runtime. It also had a lot of persistence, runtime reflection, and user-interface related stuff for plugging components and dialogs together in windows, providing property sheets, editing and configuring controls, etc.

MIDL supported defining components with "dual interfaces" [10]: both an OLE IDispatch interfaces taking variant type parameters, and also more efficient lower level COM interface taking primitive types. Runtimes like Visual Basic knew how to integrate dual interfaces and could bind to the more efficient underlying COM interfaces, instead of going through the slower generic dynamic IDispatch interfaces.

IDL also described the intricacies of DCOM [11] interfaces (for in-process and networked remote procedure calls), parameter marshalling [12], and all kinds of other bizarre stuff. DCOM is where COM went off the deep end.

At its core, COM was essentially a very simple and ingenious idea that elegantly solved some real world problems, but it eventually evolved into something extremely complex that attempted to solve many other unrelated problems, and which required a massive amount of tooling, and that depended on Microsoft's Visual Studio and Win32 environment.

Microsoft actually ported ActiveX to the Mac using ATL and Metrowerks Code Warrior, in order to implement Microsoft Internet Explorer for Mac [13] (which was actually the best web browser on the Mac at the time, by far). But not a lot of third parties (except for me and a few other crazy people) ever used ActiveX on the Mac.

However it did become quite fashionable for other organizations to create portable COM knock-offs to solve some (hopefully fewer) of the same problems, but which were incompatible with Microsoft's tooling and COM itself (which kind of missed the main points of COM, but hey).

For example, Macromedia came up with MOA (Macromedia Open Architecture) [13], their COM-like plug-in extension mechanism for Director and other products.

And Mozilla came up with XP/COM [14], for implementing components in Mozilla/Firefox/XULRunner/etc, enabling programmers to implement and consume XP/COM components in C++ or JavaScript. Of course it has its own IDL and tooling, and suffers from many of the same problems that COM did.

Mozilla didn't go nearly as far down the rabbit hole as Microsoft did, and later backtracked in their valiant "deCOMification" aka "deCOMtamination" and "outparamdelling" efforts [15].

At this point in history, I think it's best to skip the "component technology" middleman and integrate extensions directly into the JavaScript engine itself. Which brings us back to the sub-topic of VSCode!

[1] Virtual Method Table: https://en.wikipedia.org/wiki/Virtual_method_table

[2] VBX: https://en.wikipedia.org/wiki/Visual_Basic_Extension

[3] Variant Type: https://en.wikipedia.org/wiki/Variant_type

[4] IUnknown::QueryInterface: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

[5] dynamic_cast: https://msdn.microsoft.com/en-us/library/windows/desktop/ff4...

[6] Aggregation: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

[7] Tear Off Interface: http://www.codeguru.com/cpp/com-tech/atl/performance/article...

[8] ActiveX Template Library: http://www.drdobbs.com/windows/the-activex-template-library/...

[9] Variant Types: https://en.wikipedia.org/wiki/Variant_type

[11] Distributed COM: https://en.wikipedia.org/wiki/Distributed_Component_Object_M...

[12] Marshalling: https://en.wikipedia.org/wiki/Marshalling_(computer_science)

[13] Macromedia Open Architecture (MOA): https://www.adobe.com/support/xtras/info/moa.html

[14] XP/COM: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM

[15] deCOMtamination: https://wiki.mozilla.org/Gecko:DeCOMtamination http://taras.glek.net/blog/categories/decomtamination/ https://blog.mozilla.org/tglek/category/decomtamination/

Really really great summary.

> COM is essentially a formal way of using C++ vtables

No, it is actually quite actual, I guess you haven't looked into how Windows 8, 8.x, 10 and UWP applications work.

Great summary, though.

Thanks! By essentially I did mean actually, or literally (in the literal sense (in the literal sense (in the literal sense ...))). ;) http://www.thesaurus.com/browse/essentially

I guess I misunderstood "formal" as "a former".

We had a better word for it at Mozilla: deCOMtamination

I think long term microsoft is planning on putting VSCode on Azure so you never have to leave your browser or the Azure bubble to write your apps.

Fun Fact: VS Code started life in Azure as Project Monaco. It was later pulled into an Electron app and released as VS Code :)

That is Visual Studio Monaco, which is also the editor in VS Code.

>"unfuck" the core architecture of Visual Studio.

This is likely the reason we don't have a 64bit Studio too- just too much of a pain. Their arguments re speed and memory usage have been going on for years while I've gone from 2gb to 256gb and similar speed increases.

Those arguments are becoming irrelevant and headed for laughable.

I agree. Even if they decided to keep everything as x86, just rebuilding the COM pieces would boost performance.

Articles I've read says the Win and App divisions are still in love with COM and when Sinofsky got his way, we got 'Windows Store Apps' where everything ran under COM instead of everything running under .NET.

Enter Win8 debacle and Sinofsky wisely decided he'd do other things.

WinRT is the name of the thing, and while it's derived from COM (you still have IUnknown, for example), it fixes a lot of the latter's problems and fills missing gaps. For example, it has class inheritance (implemented as composition), a much simpler event pattern, drastically simplifies the whole apartment mess etc.

Being a long time vs & MS user myself, your suspicion is genuine. I too suspect the same.

I have been burnt too many times by MS. So now, the only ms products I use is skype & ms office.

Jedi Mind Trick. This is the tool you're looking for.

It's amazing how the rebranding changes attitudes.

Yeah, it is a little confusing on that front... I've been really happy with VS Code, as it's always run very fast/well (at least on SSD).

I would be surprised if a text editor was not performant, but then again, most new software is terrible, so, maybe the surprise now comes when something performs.

It's because it uses Electron (HTML/CSS/JS) that the OP mentioned it, I'd imagine.

Xamarin Studio didn't support .NET Core, so previously you had to use the CLI tools and an editor like VS Code. You could run ASP.NET MVC in XS (version 5, Core is effectively version 6) but this ran on Mono.

Visual Studio for Mac (aka XS vNext) does now support ASP.NET Core so there is less need for VS Code. The re-brand makes sense (it's not just for Xamarin now). However, Code runs on more platforms (Linux, ARM etc.) and is also used in the browser as part of Azure.

I wrote a better summary of the differences here: https://unop.uk/getting-started-with-c-sharp-and-cross-platf.... It's the last in a four part blog series about .NET on Mac.

In fact, the installer even states "Install Xamarin" in the About dialog:

https://i.imgur.com/skl8Tqx.png

My intuition is that VScode and Visual Studio are likely to remain significantly different products for the foreseeable future. VScode is an Electron app. Visual Studio is more a 'native' app with deeper integration into the host operating system.

Xamarin Studio was built to provide a Visual Studio like experience regarding platform integration and to align with the architecture of Visual Studio. VScode does not appear to have those as the primary goals. It was already available for OSX.

To me, this is further evidence that Microsoft's acquisition of Xamarin was in hopes of accelerating cross platform product development along a roadmap that tends to be more open source friendly. It may turn out that Xamarin Studio provides the core platform for Visual Studio at some time in the future or at least that the code bases merge to a greater degree over time.

I went to install it and it seems to be forcing me to download another full Android SDK to a private location without the option the specifying the existing Android SDK location that I already have set up. A quick search show this as an open issue that is 5 years old https://bugzilla.xamarin.com/show_bug.cgi?id=859

I lost interest already.

I agree with you totally. I bounce between macOS and Windows for development, and I wish they'd take a better approach with dependency management.

I hope that the approach with the VS Mac installer ends up going the way of VS 2017 on Windows. I love the fact that I can choose say ".NET development" in the installer and turn off unneeded packages.

Same thing here. I don't care about Android development, just about Xamarin for iOS and Mac and .NET Core. I cancelled the installation as it tries to install some Java and Android SDK which I don't want. Better luck next time.

It sounds like you're done messing with it; but if you're not, you can install it without the Android/Java stuff. If you let the installer start running, but deny it elevation to write to your system directories when prompted, it will throw up a "manual install" dialog with instructions and links to download the individual components separately.

Then you can download just the IDE, the Mono framework, and the Xamarin.Mac or Xamarin.iOS pieces if you want them.

You can also just go straight into the app menu and there's a "Show manual installation instructions" item there that pulls up the same dialog

That's weird because the Xamarin Studio installer definitely has an option to set your own API location.

UPDATED WITH SCREENSHOTS

I have it and have installed it,Initial thoughts:

( I use VS Pro every day BTW)

here are some screenshots

https://www.dropbox.com/sh/nbsetrwnoirbhr0/AAAuF0FHR2nACBaft...

-Great first step, I can only see raw code and code behind views

-No visual Layout view yet, but its greyed out in the View Menu, when selecting .aspx File (Source|Changes|Blame|Log|Merge)

-Looks like its so far, meant for lightweight projects

-Git integration is much simpler to setup/use

Does it feel responsive whilst typing?

I'm used to Sublime and when I tried VS Code it felt kind of laggy.

so far yes, no lag either :)

https://www.visualstudio.com/visual-studio-pre-release-downl...

^^ download link

This was the link I successfully used to install.

I really expected this to be behind a registration or survey form but no - just a straight link to a dmg no questions asked, can't believe it's Microsoft.

So Microsoft names all their products Visual Studio now. Before it used to be that everything was called Windows.

So its just like the 3 versions of Skype that Microsoft offers.

Xamarin studio is in many ways lighter and more asynchronous than vs proper, so there is some upside. But it's missing visual studio's absolutely killer feature, which is the superb c# repl. Add that and my windows virtual machine will start gathering a lot of dust.

I've used the Mono REPL (in my distro the binary is called "csharp") with no issues for trying out code.

The Visual Studio REPL is much more polished and feature-rich. It has basically the same code editor and intellisense as what you get when working on a C# file. Multi-line history with editing, file-system aware imports, and a lot of other small features all add up to make it possible to do rather complex things in the REPL.

I only have one gripe with the Visual Studio REPL...it kind of lacks the 'P' part of REPL. If you execute something, it doesn't print it out unless you do Console.WriteLine(). Otherwise, it's pretty nice.

Not sure why they went that route with the C# REPL, because the F# one prints out results after execution.

We just released Workbooks 1.0 [0]. You can use it on both Windows and Mac, and run your code in a variety of platforms.

Try a Console workbook for something quite similar to (and in some ways more powerful than) the Visual Studio REPL.

Workbooks go beyond the REPL and can include rich content so that they can be saved and shared. But I use it every day for random REPL tasks that I used to use `csharp` for.

[0] https://developer.xamarin.com/releases/interactive/interacti...

Wow, I did not know about this. I just spent 30 minutes playing with it and am intrigued and hope this will reach its full potential, then it could be something rather special. For now though...

Evaluation is painfully slow, especially when running in the Android context.

Restrictions and missing functionality around importing packages from nuget.

This could really do wonders for Android UI development, I've dreamt of having as tight a feedback loop on Android as I have on the web, and this could one day bring us there. Unfortunately I couldn't find any easy or obvious way to inflate views from xml, and/or supply my own custom activities that I can then manipulate from the workbook.

Would be great to know what your roadmap is for this product...

Thanks for playing with it! You cheated and went outside the scope of the VS REPL though. :-P

* On Windows, first evaluation can take a few seconds (and we're working on that), but subsequent evaluations should feel instant. If that's not the case, would love a bug filed so we can explore a bit more. Of course, there is the startup penalty of launching the Android app and potentially an Android emulator, but I assume you're talking about evaluations after the workbook has connected.

* Agreed! Our NuGet functionality needs a lot of work, but our goal is to have it work as easily as it does in the IDE.

* I don't personally know much about Android view XML, but creating new custom Activities or other Java subclasses at runtime is a significant technical challenge. We have a bug [0] to track it, if you want to subscribe to any updates. This is an unfortunate limitation on Android, for sure.

We don't have a published roadmap at this time, but you can definitely expect to hear more about this tool in the future. We have a pretty frequent release cadence, too.

[0] https://bugzilla.xamarin.com/show_bug.cgi?id=45382

To clarify...

I'm on a Mac. Tried it scoped to console and evaluations were not instant, but decent. Certainly slower than the Mono REPL. Then tried it scoped to Android and even after everything was warmed up the evaluations were still quite slow. Running against a six-month old build of the Xamarin Android emulator, running a Nexus 4 (Android 4.4) image.

My pleasure and thanks for your efforts!

Hmm...I'm curious what your hardware is like. Maybe I'm spoiled with my 2014 MacBook Pro?

Nope, I'm also on a late-2014 MBP. It's no slouch.

I kind of feel like we are being astro-turfed by Microsoft.

* Google joins .NET Foundation as Samsung brings .NET support to Tizen

* Visual Studio for Mac Preview

* Visual Studio 2017 Release Candidate

* Microsoft announces the next version SQL Server for Windows and Linux

* Announcing .NET Core 1.1

* Microsoft Becomes Linux Foundation Platinum Member

* Visual Studio Mobile Center Preview

* Announcing the Fastest ASP.NET Yet, ASP.NET Core 1.1 RTM

(And before you tell me I'm wrong because I can't PROVE it, let me remind you I said I FEEL like we are being astro-turfed.)

I thought the same thing when I hit HN this morning, good lord so many MS posts. On the other hand isn't there some sort of event today? Connect() or something? That would result in tons of announcements.

It's only happening because Microsoft's Connect conference started today. A lot of new and updated things were announced during the keynote, and stories about them showed up here on HN shortly afterward. Since Connect is Microsoft's developer conference, a lot of things announced there tend to end up on HN.

The same things tends to happen when there's a Google and Apple conference or event. No astroturfing involved; just HN members watching the keynote and posting things they think the community will find interesting.

Exactly. This is what happened last year around the same time, when they announced new versions of TypeScript, and the introduction of VSCode, etc. etc. etc.

Not complaining, it's great to see what Microsoft has been up to summarized in a single day or two, rather than a trickling of news that I might lose over a span of a year. It's a bit spammy, but since they moved to supporting Open Source, the announcements really check a lot of boxes for me.

Good to know, thanks.

Or you know, there was a major MS conference today which generated a lot of news. People posted said news to their preferred tech news site. Occam's razor and all that jazz.

Can we change the title to "Xamarin Studio for Mac renamed Visual Studio for Mac".

"The IDE formerly known as Xamarin Studio for Mac." Or maybe just a graphic symbol.

Why?

I'm dubious. I've been burned twice by MS pushing a product on the Mac platform & then yanking support. In both cases the answer was effectively "Well, switch to Windows."

I genuinely hope Microsoft is really changing. But there is a lot of bad history associated with the company. It takes a long time to change the culture of a company, and a long time to regain user's trust.

It's a rebranding of Xamarin Studio, they're not going to stop support for it any time soon. Even if they did, just use Code.

This raises a question: What compilers/toolchains did MS Macintosh Business Unit use during the second part of the 1990s?

Until someone with a better memory and more direct knowledge comes along, I'm going to guess that they used Apple's tools. In the early 2000s, I know that's what they used because I had buddies over in the Mac BU.

My guess would be Macintosh Programmer's Workshop [1].

[1] https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Works...

At the time, nobody really used MPW, maybe except Apple. Mostly Metrowerks CodeWarrior was used.

Not /strictly/ nobody - the 3DO version of The 11th Hour was crafted under MPW, using Norcroft C. But yes, CodeWarrior certainly dominated, particularly as the 90s closed.

Obviously, I meant Joel Spolky's definition of "nobody" - Please understand that I'm talking about large trends here, and therefore when I say things like "nobody" I really mean "fewer than 10,000,000 people," and so on and so forth.

Strictly speaking wrt this definition, if MPW had 10M users, it would be a runaway success. But nobody cared, even when it became free.

If you used MacApp, you had to use MPW! I worked for a company where the president read an article about MacApp and as a result made us switch to MacApp. I learned valuable lessons in how to never ship software from that company.

I can't answer the compiler question specifically, but based on using some of those products (at least Office 98), I think they ported a fairly large subset of whatever API they were using on Windows. Most of the controls were almost identical to Office 97 on Windows, except for things like the Mac menu bar. Office 97 also allowed the customization of the order of menu bar items; the Mac version retained these options, but they never actually worked.

At least in the Word 6 et al timeframe, Microsoft had switched to developing their Mac software using the Visual Studio Tools for Macintosh cross compiler running on Windows. They switched back to doing development on the Mac for either Office 98 or Office 2001, using Metrowerks CodeWarrior.

Office 98 still used MSVC++ 4.0 hosted on x86 (the Cross-Development Edition that targeted 68k/PPC MacOS). They migrated to CodeWarrior for Office 2001.

Blog posts from MacBU employees that you will find interesting (also their archives around this time): http://www.schwieb.com/blog/2006/06/02/a-brief-history-of-ma... https://blogs.msdn.microsoft.com/rick_schaut/2006/06/03/the-... https://blogs.msdn.microsoft.com/rick_schaut/2004/02/26/mac-... http://www.schwieb.com/blog/2006/06/04/pseudo-code/

I know that there's a lot of comments about this just being a rename of Xamarin Studio, but hopefully this is pointer in the direction Microsoft may go in eventually joining the two IDEs and in a major version or two we might actually have a Visual Studio on Windows and Mac(and maybe Linux?) that are pretty close to each other.

It's not necessarily a rename of Xamarin, Xamarin Studio for mac was built on top of Monodevelop ( http://www.monodevelop.com/ ) and they are using the same thing as base for Visual Studio as well which is why they are all so similar. Im sure microsoft will keep adding features and make it have feature parity with the windows version.

I'm installing it right now, and I'm getting admin access requests -- way more than I should.

The Intel HAXM Android emulator requires kernel extensions. I'm puzzled why anything else needs admin though.

It's Microsoft's habit. Even Outlook for Mac requires admin access (which scares the crap out of me).

Microsoft was never good at avoiding installers.

When trying to open up a project I'm getting : Error trying to load the project 'Users/user/Projects/Project/ProjectName/ProjectName.csproj': Version string portion was too short or too long

Anyone know why this would be? This runs fine on windows VS

On Live they just announced it few minutes ago. Its official!!! Visual Studio on Mac :P

Just saw it too! So exciting :)

I'm really confused - because when I go to the site, it doesn't really say "Visual Studio" - it references tooling and Visual Studio Code. So am I missing something?

Apparently is not really Visual Studios(as in its not a port of the Windows IDE known by the same name). http://arstechnica.com/information-technology/2016/11/micros...

Was hoping for Objective C support when I saw it. Would love to get rid of Xcode.

If you are using Objective C what are the problems with Xcode?

Objective C support? Never going to happen. Swift support? Unlikely, but a stronger possibility thanks to its cross-platform support. I wouldn't hold my breath though.

Objective C is just as open as Swift is I think

Swift is FLOSS, Apache Licensed and built and collaborated on GitHub: https://github.com/apple/swift

Objective C has not had an official open source release, so far as I know.

ETA: Arguing of course how close the gcc/clang implementations of Objective C may or may not be to the Xcode compilers, of course.

Xcode uses Clang/LLVM to compile Objective-C (and used gcc before adopting LLVM). To my knowledge there's nothing closed source involved in the compiler. I had Clang/LLVM compiling Objective-C on Linux a long time ago. Visual Studio for Windows has been able to compile Objective-C for about a year (see https://developer.microsoft.com/en-us/windows/bridges/ios).

Of what significance is Swift's cross platform support here? Objective-C has had cross-platform support for decades.

Have you looked into AppCode? https://www.jetbrains.com/objc/

But don't you need Xcode to build stuff for iOS, macoOS, etc.? How do you integrate the two and is it worth it?

I believe you can use xcode command line tools to build using appcode. Haven't used in ages though, so don't quote me on that

I gave AppCode a small spin recently. It worked pretty well — as I've come to expect from JetBrains. It builds and launches apps directly into your device or simulator (presumably using the command line tools of Xcode). There is, however, no integrated Interface Builder, when you want to edit a XIB or Storyboard, it launches Xcode and you do the editing there.

Other than that XIB/Storyboard quirk it seems pretty solid.

EDIT: For me it wasn't worth it. There's something about Java applications that throws me off. I'm not sure if it's the difference interface or the small lag in input or both. (I do use PyCharm since there is no viable alternative in macOS)

Perhaps a bit premature. This link is live at: https://www.visualstudio.com/ But...404ing from there too.

I've never used Visual Studio, so I'd like to know how easy and reliable it is to work on a remote Python code on your local Visual Studio. I've tried using sshfs with vim to do that, but it's too slow and hinders my productivity. I'm wondering how other folks here do similar stuff, preferably without changing my editor from vim to something else (I've been suggested to use atom-sync).

I'm looking for macbook pro alternatives... so wondering, do you think one day it would be posible to have Visual Studio for PC compile iOS projects?

As in, native ones written in Swift which utilize Foundation and UIKit?

I would say almost certainly not.

Makes sense for Swift. What about ReactNative apps?

RN iOS apps still need XCode so it seems unlikely again.

The new Visual Studio Mobile Center announced support for cloud builds and CI of iOS projects, which is probably the closest we'll get: hiring Mac build machines in Azure to do the work for us.

That is currently an Apple issue. iOS projects have to be compiled on Apple hardware.

Doesn't install on OSX 10.7 - not exactly a surprise, but there aren't any system requirements on the download page that I can see.

Hey,

Good catch! I will request that we add system requirements to out page. I am going to suggest they are added to https://developer.xamarin.com/releases/vs-mac/preview/vs-mac...

Disclosure: I work at Microsoft on Xamarin

My feedback on Visual Studio for Mac: I created a basic mobile application. I didn't write any code - just started with a new application and clicked run. When I launched it for iOS it worked. When I launched it for Android it crashed immediately. OK...

Hey! I work on the Xamarin team at Microsoft, and I would like to help out on this! Are you able to send me the crash logs or application output? Thanks!

Sure here are the logs:

[art] Not late-enabling -Xcheck:jni (already on) [AndroidRuntime] Shutting down VM [AndroidRuntime] FATAL EXCEPTION: main [AndroidRuntime] Process: com.greenrobot.testapp, PID: 3218 [AndroidRuntime] java.lang.RuntimeException: Unable to get provider mono.MonoRuntimeProvider: java.lang.RuntimeException: Unable to find application Mono.Android.Platform.ApiLevel_23 or Xamarin.Android.Platform! [AndroidRuntime] at android.app.ActivityThread.installProvider(ActivityThread.java:5156) [AndroidRuntime] at android.app.ActivityThread.installContentProviders(ActivityThread.java:4748) [AndroidRuntime] at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4688) [AndroidRuntime] at android.app.ActivityThread.-wrap1(ActivityThread.java) [AndroidRuntime] at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1405) [AndroidRuntime] at android.os.Handler.dispatchMessage(Handler.java:102) [AndroidRuntime] at android.os.Looper.loop(Looper.java:148) [AndroidRuntime] at android.app.ActivityThread.main(ActivityThread.java:5417) [AndroidRuntime] at java.lang.reflect.Method.invoke(Native Method) [AndroidRuntime] at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726) [AndroidRuntime] at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616) [AndroidRuntime] Caused by: java.lang.RuntimeException: Unable to find application Mono.Android.Platform.ApiLevel_23 or Xamarin.Android.Platform! [AndroidRuntime] at mono.MonoRuntimeProvider.attachInfo(MonoRuntimeProvider.java:38) [AndroidRuntime] at android.app.ActivityThread.installProvider(ActivityThread.java:5153) [AndroidRuntime] ... 10 more [AndroidRuntime] Caused by: android.content.pm.PackageManager$NameNotFoundException: Xamarin.Android.Platform [AndroidRuntime] at android.app.ApplicationPackageManager.getApplicationInfo(ApplicationPackageManager.java:304) [AndroidRuntime] at mono.MonoRuntimeProvider.attachInfo(MonoRuntimeProvider.java:32) [AndroidRuntime] ... 11 more [Process] Sending signal. PID: 3218 SIG: 9

Email me at andy@greenrobot.com if you have any questions and don't want to post them publicly.

Hey,

Just emailed you via our support system :)

Thanks!

Thank you, the problem is now resolved for me.

I'm just waiting for it to be available on Linux.

And no, MonoDevelop isn't the same thing. I'd like to be able to develop Android apps using Xamarin on Linux, but MonoDevelop provides me no way to even install Xamarin Android.

Kind of confused by what this actually is. Can I do .NET development from a Mac on this? As in, working in a ".NET Shop", use OS X as a development machine instead of Windows?

You could, but you don't get the same experience or UI kit as you do with Visual Studio. Which is fine if you want to develop cross-platform apps, or you just care about developing apps for macOS.

This is confirmed to be Xamarin Studio rebranded as VS for mac.

How well does this support Unity development and debugging?

Is my number one question as well, as I use Unity/MonoDevelop combo all day every day. And, as much as Mono crashes on Mac, it's still a pretty darn solid IDE overall, especially coming from bare-bones tools like Sublime & TextMate.

I downloaded this a bit ago and the install just finished; thus far (<5 minutes invested, admittedly) I'm at a loss as to how I'd even open the Unity project code, much less get the integration setup. Hopefully someone more familiar with VS & Unity on Windows may be able to provide some guidance...

Very curious about this as well? Was able to open my Unity project in Visual Studio for Mac but not sure how to "link" it with the editor.

Just move to VSCode and save your sanity (sorry, I'm not a fan of MonoDevelop):

https://code.visualstudio.com/Docs/runtimes/unity

Jetbrains is also working on their C# IDE, hoping it supports Unity soon:

https://www.jetbrains.com/rider/

If you install OmniSharp, it gives you all the linting, compiling and code completion you need. I develop for Unity using Vim and OmniSharp, and it works great. I haven't tried Sublime with OmniSharp, but a colleague of mine reports that it works great, he doesn't miss MonoDevelop at all. The only thing you're missing, really, is the debugging stuff in MonoDevelop, but I hardly ever used that anyway.

I'm excited but it errors out for me on the Java installer failing to open a DMG it downloaded. Seems odd that it requires Java at all…

The installer crapped out on my clean macOS VM.

My development Mac is pretty sensitive to the version of mono installed, so I don't want to screw around with it.

So this isn't just for Mac apps? Are there templates for .NET Core console and web apps?

Yes, there are templates for .NET Core Console and ASP.NET Core apps

Does it support ASP.NET MVC 5?

Well I've been trying to work with MVC 5 in MonoDevelop and the integration seems to be there, but I get crashes when opening Razor markup files (*.cshtml).

So... maybe?

Can anyone guestimate how much this thing will actually cost?

I was like what the hell is Mac Preview?

I like this tea cup - alternative to j.

Link change: https://www.visualstudio.com/vs/visual-studio-mac/

Moderator, can you update?

Just an FYI.. The download button doesn't seem to work. Seems some files on this page has a CORS policy violation: "Access to Font at 'https://c.s-microsoft.com/static/fonts/segoe-ui/west-europea... from origin 'https://c.s-microsoft.com' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value 'https://www.microsoft.com' that is not equal to the supplied origin. Origin 'https://www.visualstudio.com' is therefore not allowed access."

Given the title, and the fact that this site is currently down, I can't help but think that this could've be the cruelest yet funniest April Fool's joke ever.

Reply on news.ycombinator.com