Hi, Rajen Kishna here, Product Manager on Visual Studio for Mac. Our goal with Visual Studio for Mac is to create a native IDE for Mac users with workloads that make sense on macOS. That means "desktop app" development will target macOS and Visual Studio (on Windows) can be used to target Windows.
The core of the IDE definitely has a heritage in Xamarin Studio, but this release has brought in so much more with .NET Core/ASP.NET Core development for web apps/services, Unity support for game development and cloud integration with directly publishing your web apps/services and previews of Docker and Azure Functions coming very soon.
Extensions is definitely another area we're looking to align more over time. Currently, there is an extensions framework, but you're right that it's different from the one used on Windows.
Definitely keep the feedback coming, we're listening and looking to act and prioritize accordingly!
I would like to add that we have been reusing a lot of the existing code from Visual Studio in Visual Studio for Mac.
The code for Visual Studio is just incredibly well architected. It is a design jewel - the core components are independent of the UI, and were already cross platform. It was a great surprise for us.
What you see now is the first drop, we are adding many new capabilities in the coming months as more code is ported over.
I am sure it is a nice product, but the name is causing confusion. In the last few months I have witnessed misunderstandings between clients and consultants who think they agree to deliver a project as a "visual studio solution/project", and only when deliverables start being passed around do they realize that the original win32 visual studio is not the same as the other visual studio offerings, and that you cannot just expect the other offerings to produce the win32 visualstudio .sln and .csproj solution project files or anything that builds with msbuild.exe out of the box etc.
I get how this might happen, but that sounds like there are some fundamental problems at the place where you saw that, I mean if you think that "Windows Phone" for example is the same as "Windows" on your laptop then that I don't think it is Microsoft's fault.
I think that's pretty consistent with the One Windows marketing. Personally, I'd rather have a tool that works with some of the features I want, rather than none of the features I want, because they're taking 5 years to get to feature parity. But that's just me.
Easy. "We are expecting the most recent available version of Visual Studio (by the time the contract is signed)".
Step one level up above the trenches and the people you meet haven't had the time (or even skills) necessary to study the details to determine the fact that "Visual Studio for Mac" is, in fact, not the latest version of Visual Studio in the slightest. And why should they. Delivering a visual studio solution should be as unambiguous as delivering an excel sheet.
That's really interesting. You're not talking about finance or engineering, but yes, it certainly seems possible that there's a business that does things that way.
Code can be well designed from an architectural perspective and still be slow in areas. I imagine it's due to the minimal feature set (which MS defined). Stuff constantly happening in the background when you click or type something, bottlenecks become more apparent with really large projects and they just haven't dedicated time to improving that, etc.
I realize that architecture can't be separated from functionality, but I think the parent was focused on modularity and the ability to reuse various components.
There are valid reasons for that [0]. Would you accept slower compile times and more memory usage just so you could have a 64-bit version of visual studio that your project probably wouldn't even need?
> Our goal with Visual Studio for Mac is to create a native IDE for Mac users...That means "desktop app" development will target macOS.
Feedback: This target ghettoizing mentality seriously hurts my workflow. I just want to cross compile to target Windows. I want to make Win32 MFC C++ executables without having to boot into an operating system (Windows 10) that I never want to use on my development laptop for anything other than running MSVC. It's literally just a set of headers and object files that will, in even the very worst case, produce more applications targeting your platform. Why does Microsoft continue to keep them walled off?
>Why does Microsoft continue to keep them walled off
Isn't the answer obvious? How many MFC devs are there working primarily in OSX or linux? It has to be tiny, even if they had the ability to do so. Great, I can compile; still need to boot up Windows to run it. My userbase is still 100% windows users. We still use Windows on every PC in my company. So who cares? What's the value proposition here?
Because it doesn't have to be that way. You're just arguing from the "we've always done it that way" perspective. Years ago, I took the extra time to compile a Qt application so that it would run on Windows and Linux with the same code base. Why not? Why not compile for Windows and Mac, and let people choose what works for them? You may have no use for it, but I do. Is it worth the effort? Depends on the application? Is it worth Microsoft's time to support? Obviously not. But at this point, the ability to compile for multiple platforms at the same time shouldn't have to be rocket science for the situations where it makes sense.
That's not my argument at all, but whatever, look at yours. You initially mention MFC, a Windows only technology, and follow that up with a QT example. Well yes; QT is meant to be cross platform! The MFC example made no sense whatsoever.
> Isn't the answer obvious? How many MFC devs are there working primarily in OSX or linux?
None, because you can't, the same reason you don't see many iOS developers using windows. I don't know if there are many people that want to work that way or if it's worth supporting, but your current argument is circular reasoning at it's finest.
My argument was that it makes absolutely no sense to develop an MFC app on OSX. I asumeyou'll want to, you know, run the thing, right? well get out your Windows VM!
I guess one value proposition is the devs that refuse to work for your company because you're 100% Windows might re-consider if both your company and Microsoft opened this up slightly?
Kind of amusing considering the platform you (apparently) prefer. However walled Windows is, Apple is at least as bad, if not worse. At least with Windows development one isn't restricted to a particular brand of computer.
Alright, well, since we've veered off on this tangent, I prefer Fedora. Between macOS and Windows, I prefer macOS...though I may never get used to the new capitalization scheme. But I don't see why any of that should be a reason to want to boot multiple operating systems in virtual machines. How do the two subjects relate?
I'm not sure where this is getting confusing. You complained that Microsoft's Mac offering doesn't make Windows apps. It was then observed that this is an ironic complaint because development for Apple platforms is way more locked down.
Allow me to rebut: Someone else being bad isn't a reason to be bad. Ok, so it's a reason, but it's not a great reason. Ok, so maybe it's a great reason, but it's not a good reason. Also that's not what irony means. Ok, so maybe it's what a kind of irony means, but only in a new transgenerational sense where someone else implied to themselves something that I never said. Ah, you know what, that's definitely situational irony.
What's the point, you can't debug or even run such an executable? What developer is just going to compile stuff without testing it? It makes no sense to want this.
For starters, Wine actually works really well. And beside that, time spent writing code is measurable in weeks while time spent running an executable to test or debug is measurable in minutes. The amount of time spent testing and debugging is a tiny fraction of the time spent coding. RDP/VNCing for one of them every second of the day can be a huge pain in the ass. Doing it for the other once in a while is a minor inconvenience.
Next time just say "I'm glad I don't have that problem" instead of "You can't possibly". A mindset like that ends up making you look foolish, because you'll be wrong most of the time.
Despite the negative tone, I think you are correct about the mentality that leads us to conclude that we have the simple solution for every problem and that others who can't see those simple solutions are clearly not up to par. Comments of the form, "Why don't you just...", usually end with something that doesn't fit the situation, just the mental model of the poster. Over time, and with enough experience, you learn empathy for other developers. You've seen enough adversity to know that we solve problems in different ways. I don't subscribe to absolute relativism, but we have to allow for the practical, not just the theoretical.
That said, we also have to be able to encourage others to present their ideas. We clearly can't grow if we don't hear and consider external ideas. It's a difficult balance to strike.
You can run it on a remote computer (or a VM) and debug it from an OS X front-end that connects to the remote-running debugger over the network. It's a pretty common technique, gdb has had it for, what, fiftenn? Twenty years?
Maintaining two separate development environments, on two operating systems that you have to boot into separately is very annoying. Developing for an operating system other than the one you're running is about as old as the personal computer, I think :).
The remote computer is often good enough to run an application but way too slow to productively compile a large codebase on it. Besides, you don't need to maintain two development setups at once.
This is a niche situation only because Microsoft's tools make it a niche situation. It's pretty much how all embedded software on this planet is developed (except that the network is replaced by a serial connection on the lower end of the performance spectrum, of course). In nix world, it's a super-common situation; e.g. at $work, where I write software for networking equipment, no one seriously expects that I'm going to compile stuff on the routers that ends up running that software. Most of them are capable of the required heavy lifting (they have CPUs in the same performance class as a pretty beefy desktop), but why?
We're not talking about just a compiler here. Nobody says "You should try CL.exe, it's really awesome at compiling!" No, they say "Visual Studio is the best C++ IDE you'll ever use." Which is true, but not because of the compiler. And without all the Windows-specific libraries, intellisense and code analysis tools that are second-to-none can't work.
> Why does Microsoft continue to keep them walled off?
The question is backwards. The real question is, why doesn't Microsoft do what is necessary to bridge them. And the answer seems to be simple -- developer man-hours are limited, your use case is not the use case of the majority of people who want a Microsoft development environment on a Mac, they are handling the most common use case, not the edge case.
I don't think so. Win32 with MFC is already in the free VS Community Edition on Windows, so we know that the work to package up those libraries is already done. We also know that Clang and GCC can already cross-compile targeting Windows, all you need are the aforementioned platform libraries.
Visual Studio for Mac is based on Xamarin Studio, which is MonoDevelop. You have to port over everything to support C++ projects to Mac before you can use C++ projects in Visual Studio for Mac. The libraries may be packaged up, they may be portable code, but it's nontrivial. The work is >0. You can argue how close to 0 it is, but it's not like they don't have other work to do.
They already plan to support C++. Boom, done. No, I'm kidding here. I have no idea what they're planning to add. This thread started because it actually looked (I commented on this somewhere else) like it would support C++ from the website interface. I do at least have some reason to believe that they have a C++ dev manager named Steve, and that they will add support for more languages over time.
And when will I be able to develop Mac OS X applications on Windows? Probably never. I don't want to boot into another OS or buy a new very expensive computer...
In what universe is people who want to build more Microsoft Windows executables for other users of Microsoft Windows using Microsoft Visual Studio not part of Microsoft's target market? I have an operating system on my computer already. I don't want two.
How will you test those apps? By installing a second OS no doubt. Why not run visual studio inside that, perhaps with vmware or parallels?
I guess I don't understand what sort of developer workflow you can have building windows apps and not actually running windows, even if it's just in a vm.
Just FYI, your installer seems to be broken for language handling. I'm getting French even though my primary language is English. I can read French fine, but I hope the whole app isn't broken this way. You should respect the preferred language and not force American English on others.
Sounds like its a long jump to say "its the same IDE you love, on the mac"
It sounds like its BASED on the same IDE, but fundamentally provides a completely different feature set, and ability to compile to completely different platforms. That's fundamental enough to suggest its not the same IDE.
If anything, MS is simply capitalizing on the brand recognition, and taking a similar approach. But if the extensions don't work on Mac - its not the same.
That's like saying "Microsoft Word, the same word processor you love, on a mac" and then not support .docx files.
I've began using Rider from JetBrains and it's working well on Mac for .NET Core APIs. VS was always better with Resharper (+ few other tools from JetBrains). Actually VS is the best IDE in the Enterprise, especially combined with some 3rd parties tools. Coverage, profiling, refactoring ...
I'm not sure what you use it for, but I have been really happy with jet brains datagrip product on the mac talking to SQL Server. I know SSMS does a lot of stuff, but for querying, DDL, ETC DataGrip works great.
I'm calling bullshit. You can't use this for the workload that overwhelming dominates it's typically use on Windows. Further it looks different, and is incompatible with other plug-ins.
The core of the IDE definitely has a heritage in Xamarin Studio, but this release has brought in so much more with .NET Core/ASP.NET Core development for web apps/services, Unity support for game development and cloud integration with directly publishing your web apps/services and previews of Docker and Azure Functions coming very soon.
Extensions is definitely another area we're looking to align more over time. Currently, there is an extensions framework, but you're right that it's different from the one used on Windows.
Definitely keep the feedback coming, we're listening and looking to act and prioritize accordingly!