I find the naming "Visual Studio for Mac" pretty deceptive, since apparently it is not anything like the win32 VS environment, but instead based on Xamarin Studio. Even the tagline is deceptive: "The IDE you love, now on the Mac".
I would guess this won't let you build/debug win32 or winforms or wpf applications, or install any .vsix extensions from the visual studio marketplace (of which there are lots of useful ones, such as this one to manage translations - https://marketplace.visualstudio.com/items?itemName=TomEngle... ) - correct me if I'm wrong, but if I can't install my .vsix extensions, this is not "the IDE you love, now on the Mac".
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.
* when .Net first come out, everything was suddenly .Net
* for a while, everything was Live
* they had two technologies called Win RT
* they pick names already in use by others (Metro, Skydrive)
* Visual Studio Code? It's not Visual Studio
Sometimes they do a good job:
* Edge
* Xenix
* Azure
* XBox
"Surface" started out pretty strong, but I'm not sure it means much anymore.
Except that "Surface" started out as a table, which is now called "PixelSense". Oh, except they've also now started to use "PixelSense" for their Surface Book displays.
Oh, how I would have loved to have been in the meeting where it was decided that the ideal name for a new, thin, light tablet device was the name previously used for a giant, immovable table.
Groove Music [1] (formerly known as Xbox Music, Zune Music and Microsoft Groove), Groove Music Maker [2] (an unreleased Windows 10 app), Office Groove [3] (a.k.a. SharePoint Workspace) or Groove (now known as OneDrive for Business - the service formerly known as SkyDrive Pro) [4].
I'll do you one better. Before all of that, Groove was a workgroup product, started by the famous Ray Ozzie, which was acqui-hired by Microsoft, and then spiked. It was brilliant. There's been nothing like it since. (Except maaaybe Slack.)
I get that his comment didn't include any reference to machine learning or industry disruption, but did it need to be flagged into oblivion? seems like overkill. Just delete the whole subtree if it's offending people, keeping the sub-comments doesn't make any sense.
And ActiveMovie, which became DirectShow. (which I only remember since Apple lampooned it by internally naming a window used by QuickTime "InactiveMovie")
I think the name Visual Studio for Mac is another bad decision like all the rest. They say it's using a lot of code from Visual Studio, but to me that seems like an implementation detail and I don't care. In fact, if it feels like Visual Studio, then they've failed. It should feel like a Mac application.
My first choice would have been to stick with Xamarin Studio. On the other hand, this sounds like a significantly new product, and so if it deserves a new name I would have seized the opportunity to launch something new that's going to get developers attention. Visual Studio for Mac does the opposite. It makes me feel like I know what it is and I'm not that intrigued.
I also would have called Visual Studio Code something else. It's almost like they don't want attention from developers.
I have to say Metro was one of the coolest names they picked and Bing is by far the worst.
For being one syllable, Bing sure is a physically difficult word to pronounce. You have to do weird things with your mouth. Also it means nothing. It has no meaning
> I don't know if it's true, but I was told once that bing means disease in Mandarin.
Sort of but not really. It depends on the intonation and even with the right intonation (bing4 / bìng), the sound maps to several other possible words aside from "disease".
I'm pretty sad about this. Most companies let the product orgs own naming after a legal check, but we let Marketing. They're supposed to do market research on names? You would not believe the hurdle that naming causes and how many empty cycles get spent on just coming up with a name. It feels like a battle of attrition.
Misleading. Emacs and Vim are installed by default with macOS since the first release of OSX. Xcode is a free download, as Eclipse and NetBeans have been since the dawn of time. I have no idea what they are talking about.
Now, seriously, I move smoothly between Mac and Linux (and did between both and Windows 7 back when 7 was new) with very little trouble. Now that I keep my config on Github (https://github.com/rbanffy/emacs-config) moving between machines and OSs is even smoother.
I mean what's not to love? Phantom bugs that disappear after closing and reopening the app, substandard refactoring support (if it even exists for the language being used), commonly occurring crashes, removal of compiler support for the non-latest version of Swift in new Xcode versions, etc.
Haha, I love his reply. Sounds just like my investor. I've worked with him for 10 years and got to the point where I do my best to send yes or no questions and no more than a paragraph.
I'd spend even more time writing it as I'd try to condense everything critical into basically a few bullet points for him to digest along with his other 200k emails a day.
His PA probably co-managed his inbox and would read and respond to this type of e-mail. Perhaps they also only forward on emails to Steve's "priority" inbox if they're worthy of his time?
Since there's a PM here from Microsoft, I've got a couple questions regarding the requirement to "sign in with your Microsoft account":
With all your branding changes over the years, what's considered a Microsoft account today? My old Hotmail account, that existed from the days before Microsoft bought Hotmail? I think it's still alive, but I haven't logged in in the better part of a decade to find out. The accounts created over the years for various Xbox machines? I think those are still around, but I doubt I could get into them at this point. The "Live" account I had to create for MSDN many years ago? Once that job and associated need for MSDN ended I've not logged in to see if it's still around.
Which one(s) should I try to find login information for to use?
Furthermore, why must I sign in in the first place for the free version? I can understand signing in to associate the install with a paid version with extra features, but I see no reason to require it for free versions without any paid features.
> My old Hotmail account, that existed from the days before Microsoft bought Hotmail? I think it's still alive, but I haven't logged in in the better part of a decade to find out.
I have some bad news for you...
This is literally the reason I signed up with gmail when it came out. Microsoft used to have a log-in-within-30-days-or-we-delete-everything policy for Hotmail. Maybe it was even 90 days.
Hi there! To answer your first question, it's any of the above :) If you use Hotmail, Outlook.com, Xbox Live, etc. they all are associated with a Microsoft Account. You can also associate your existing e-mail address, which you regularly use with a Microsoft Account, if you prefer that.
As for why, it's really a good way for us to stay in touch with you and keep you updated about what's new, help you get started, and make you successful in general. Visual Studio Community on Windows has the same behavior for the same reasons. Hope that helps!
> As for why, it's really a good way for us to stay in touch with you and keep you updated about what's new, help you get started, and make you successful in general.
I've essentially lost my Microsoft account. My password doesn't work, and it wont email me the security code. I try the "alternate email" option, which does work, but when I answer the validation questions it fails -- doesn't believe I am who I say I am, I guess.
And when I try to contact support, it wont let me contact a person unless I login to my Microsoft account...
That's true. I found it useful when I recently paved my machine and had to reinstall everything. It's also helpful when you move to a new version of VS.
And yeah, I use a different login between home and work too.
I used to be a big VB, VC++ fan boy a long time ago. 1995 :-)
Have since move on....
Tried built a few opensource apps with VS once a year for the past few years and found that I can't even compile a single Windows open source packages from github, sourceforge after weeks of trying.
The code might claim to be able to build with VS10, VS12. The dependency libraries will need completely different VS version of .xml, .proj, .sln build systems.
I challenge the PM of VS product try to build a few popular MS projs such as python, VLC, or anything in http://opensourcewindows.org/. Document the process of building the app and dependence library. Compare that to the process of try to build that same packages in Mac (with brew) or in Linux.
In Linux, for all the packages I like play with. "./configure && make" handle most of the the build in a few minutes. Even easier on Ubuntu with apt-get source/build commands. Very similar process in Mac.
Even linux kernel, I can build it easily with pretty much the same 1-2 commands for the past 20 years.
Sounds a bit cherry-picky/anecdotal to me: I regularly build open source projects using multiple versions of VS, and have created some, and it either works out of the box (because the project maintainers spent time on it - both on project system and on portable code) or else at least doesn't take weeks. Likewise on linux/mac: building from source usually works. But also not always (it is better than in 1995 though, where I'd spend hours figuring out exactly which dependency still needed building and hoping I'd find the correct patch etc. Things seem more unified now, at least to me). Also since VS2013 (possibly VS2012 as well, don't have that anymore to test) you can actually have one single project file for any version up to the latest since they all use the same format.
Don't get me wrong: configure/make is way more mature but you almost make it sound like nothing works at all with VS/msbuild which is imo often just because people don't really know how to work with it (which in turn might be because of lack of documentation/proper examples/...), or because project maintainers don't care for VS support, and/or because there is no standard dependency managment (yet? cmake does a pretty good job, vcpkg looks promising).
such as python
Wasn't that just 'msbuild path/to/python.sln'? At least for the core, might be different for other modules. But I definitely remember getting a working python.exe just by building the supplied project files.
They're sort of trying to work on this, see https://github.com/Microsoft/vcpkg. If things are strictly C++ and build using cmake, then MSVC is okay. Anything autotools or relying on inline assembly or overly complicated makefiles or scientific code that still depends on Fortran numerical libraries is a mess though. Much easier to use mingw-w64 gcc for those - bonus is you can cross compile and not have to do dev on Windows, just test the binaries.
Not to distract from your point but compiling something on Linux has always been a massive pain due to dependencies.
I often have to run configure multiple times and hunt down the correct version of whatever library it needs before re-running it and finding yet another library that it can not find (it gets even worse if you actually have the library installed but it's not in the search path...)
Compiling something on Linux is a piece of cake, even with dependencies, compared to Windows.
In Linux, the dependencies are just apt/dnf/yum away. In Windows, you have to build them, including their dependencies. There is no ./configure, no cmake config, it either has VS solution file (if you are lucky, it will even work with your version), or not. If you have the dependency library somewhere, you have to edit that project file tell the VS manually where it is. If you weren't lucky with an existing sln file, it's time to make your own.
Reading README to learn about dependencies and running configure with some flags is fine, compared to that.
Give me a couple of examples? Python is tied to an older Visual Studio normally. VS12 was different for reasons I can't remember but anything from VS13 onwards (for desktop) should build fine.
Relatively easy. I gave you an example, that has several dozens of dependencies, with several different build systems, of which not all of them support building with VS.
And that's targeting py3. For py2, you would need to build with VS2008, which some packages flat out refuse (for example, icu wants at least VS2010).
How many of them don't support MSVC due to requiring features that MSVC can't handle (like inline assembly or Fortran), vs not wanting to deal with build system contortions?
Honestly, I have no idea about the current status. Last time I tried, it was some two years ago and it was a major PITA. Since then, when I need newer versions, I just use either Linux or Mac.
I really wish Microsoft had made UWP cross-platform. Would be pretty amazing if I could use UWP/C# to target Windows, Linux, macOS, iOS and Android properly. With UWP being limited to just Windows I don't see it ever being a success.
Why? UWP is the future of application development on Windows. That's like saying Cocoa will never be a success. Also if you can make UWP apps, you can make Xamarin apps which are cross platform (for mobile at least).
> UWP doesn't allow enough system access to ever be the future of Windows.
That's kind of the point. Most apps don't need unfettered system access and many (most?) app authors aren't capable of writing an app that's secure anyway; one of the biggest attack vectors today is through apps.
Is this more than just Xamarin? I'm sorry -- I tried last time and that was the impression I got. I know it says it has asp.net core but can I truly build .net web services based apps now without parallels?
Hi, Rajen Kishna here, Product Manager on Visual Studio for Mac. It definitely is more than Xamarin, we brought in support for creating web apps and services with .NET Core/ASP.NET Core, game development with Unity and C#, and cloud integration with publishing your web apps/services to Azure directly from within the IDE. We're also announcing some preview features coming very soon, including Docker and Azure Functions support, as well as targeting IoT devices like Android Things. Lots of goodies to be had!
I used to think that way too until I opened my project in Visual C++ (with the Visual Assist addon).
The productivity boost was so great that I've decided to never use Xcode for C++ again and do all my development in a VM if I have to.
Best alternative is Qt Creator and it's probably what I'm going to use for my next C++ project on the mac. Many people recommend CLion, but I've never really managed to actually use it (and it isn't free and runs on the jvm).
Still VC++ is a powerful tool for C++ development, which is probably quite hard to beat, so having it on the mac would make using Windows totally optional :).
VSCode is constantly improving. I haven't used Qt Creator in years, so I can't compare, but ... for my uses it is way ahead of PyCharm and WebStorm; I suspect it rivals QtCreator by now (as long as you're not writing a Qt based project)
You can write C++ in Xcode (and I do so on a daily basis), but it's pretty terrible. None of the IDE features more complicated than build-and-run actually work reliably, and the debugging experience is miserable compared to VC++.
Purists like me would do to a simple text editor (in my case Sublime) and command line tools..
Anyway.. I will give it a try... it's nice to have a competitor IDE to xCode, although they don't look like targeting the same audience.
Qt Creator is quite good when editing. The main area where I really miss Visual is for debugging apps. Visual (the real one :) has the best debugger in the industry. Qt Creator is barely OK.
The only problem I have with MS's ecosystem is their love to have a lot of concepts and name for everything. I am literally lost and I do not know what .NET/<whatever> is what and how it is used.
My pet MS naming peeve is that they decided that "locale" is not good enough for them and decided to name it "Culture" in .NET, even though it is the exact same thing and "locale", being a rarely used word outside of technical circles, is much more precise.
Hi there! Rajen Kishna, Product Manager on Visual Studio for Mac here. Visual Studio for Mac is a full-featured IDE to create apps, games, and services for mobile, web, and cloud. Creating mobile apps with Xamarin and C# is definitely one of the workloads available, but there's a lot more with .NET Core, Unity, and Azure. You can view .NET Core as the cross-platform implementation of .NET you can code against and share code across apps and web on Windows, Linux, and macOS. Hope that helps clear things up!
It is different, though. In Apple-world, when you say "XCode," you mean a very specific thing. They don't have "XCode" the IDE for Macs and then also a bunch of completely different products running on different OSes that work completely differently, which all also happen to be named "XCode."
Microsoft's inability to understand how branding works is longstanding and legendary.
No idea you might be right but I have no problem navigating in Ruby/Go/JavaScript ecosystems.
While with MS I have the feeling they produce new tech and new names every week.
Seems mostly a matter of getting used to it. What's a 'gem'? And a 'bundler'? A rake, a rack, a rail, a tilt, a merb?
Make sure to browserify your webpack, take a moment, don't react, have a mocha before, gulp, bowser comes to get you. Wait no, it's fine, it's just bower.
Those are specific module names, in the case of JS at least. Not really comparable with framework-specific jargon. A better comparison would be redux concepts like "action", "store", and "reducer".
Microsoft is trying to mitigate the hemorrhage that is the mass exodus of its customers from Windows to competing operating systems. It's not about "real support" for Linux or Mac. It's a sad attempt to keep people tied to Microsoft products, by enticing you to use these tools even once you've abandoned Windows.
What they should be doing is fixing the critical issues people have with Windows; namely, Windows 10's (lack of) privacy settings, advertisements in Explorer, harassing people with taskbar notifications for using Chrome instead of Edge, and the utter shitstorm they allowed to take place with malware-levels of bullshit with forced and unattended upgrades to Windows 10. With the way in which Microsoft pushed out Windows 10, I can't understand why anyone is still using Windows except for gaming. That maneuver should have cost them so much more than it did. Microsoft has lost all credibility, and trust is unlikely to ever be regained.
tldr; Microsoft Windows' users have had enough of this crap, and are migrating elsewhere. Instead of fixing the issues people have with Windows that are causing them to abandon it, Microsoft is creeping into the competition's ecosystems in some desperate attempt to maintain a partial grasp on its users.
Hi there, Rajen Kishna here, Product Manager on Visual Studio for Mac. If you haven't tried it out yet, I would definitely say check out the released version of Visual Studio for Mac. It has support for mobile apps with Xamarin, but adds so much more to build web apps and services with .NET Core and even games with Unity. We also announced preview support coming very soon for Docker and Azure Functions and are definitely planning on adding more over time.
> Hi, Rajen Kishna here, Product Manager on Visual Studio for Mac
Hi, a minor procedural point (I'm a mod here): it's good to say this once in a thread, but repeating it after that breaks the feeling of normal conversation, so could you please not? Experience shows that users figure it out.
It would be really nice to have a microsoft rep in here to answer questions. Because what I really want is visual studio that can build C++ win32 MFC executables without having to run Windows in a virtual machine. Can it do that? I don't know.
Scott wouldn't be able to help... I don't believe he has any influence at all with the VS Team. (or team that works on VS for Mac since it's a different team because it's built with Xamarin)
It is based on the MonoDevelop core with many new extensions to support new workloads (.NET Core, Azure Deployment, Unity development).
Additionally, over the past year we have replaced started to replace the internals of MonoDevelop with code from Visual Studio that we have been open sourcing.
In addition to what has been open sourced and integrated so far, we have a strong pipeline of additional features and capabilities that will bring even more Visual Studio code into the IDE.
We are roughly on a 6-8 weeks release cadence that aligns with the Visual Studio release cadence, so you will see various subsystems get new capabilities continuously from this point on.
More than that, if they're willing to deliver a port of Xamarin/MonoDevelop to Mac and call it VS, it's at least funny that they won't do that for Linux. There is no actual need for that, but since they're refactoring Xamarin...
Where do we speak up about this? I remember when Xamarin Studio was released on Mac, and I tried to look for a Linux build, there wasn't a place where I could ask about it, except a Reddit AMA. Hacker News discussions around release time of a non-Linux product don't seem like a good place to ask about Linux support either.
And I'm pretty sure I'm one of few who even hopes for it anymore.
It would be great if in addition to voting, you can articulate some reasons for why you care, add a personal touch, in the end, we would love to know what our users care the most about.
Many people don't seem to understand the internals of all this... MonoDevelop is the core of XamarinStudio and Visual Studio for MAC, so essentially when these guys add features they are in reality adding them to monodevelop. So think of it as:
Visual Studio Mac = MonoDevelop + macOS extensions
Xamarin Studio = MonoDevelop + extensions
MonoDevelop = Libraries, ASP.Net, GTK#, Xwt, Console Apps, etc.
What's important here is that porting over the real VS to Mac or even Linux is not practical. You won't also see mfc/win32 support on mac or linux (on the foreseeable future) because those are extremely tied to the windows architecture which is far from being compatible with unix, most people just don't get it. Same case for developing say, iOS applications, you just can't do that without macOS because you need the tooling, so its not really up to Microsoft.
What I think could be accomplished relatively easy is a XamarinStudio/VisualStudio/Monodevelop on Linux with support for Android development since you already have the tooling available there, the IDE would just wrap up the core code/tools. Also, there is no truly multiplatform desktop framework as each platform has its intricacies but there's an actual toolkit (poorly named, btw) called Xwt which is what monodevelop uses in some parts and draws native widgets depending on the platform is running, something like what Qt does.
I sincerely would LOVE to have an F# development IDE that didn't ask me to install Mono. I don't have anything against Mono, per se, I just want to see that Microsoft officially supports it across the three major platforms.
They're promoting this as a new dev environment for .NET Core, but there's still ZERO tooling for Razor. I tried starting a simple example project and the .cshtml files didn't even have any syntax highlighting, let alone syntax/type checking.
I don't know how you work on cross-platform ASP.NET for this long and still not have the tooling for your templating engine ported.
(You can get there from the linked page, click Release Notes, then Downloads link in the third paragraph, then "How to install offline" at the bottom, just above the fold.)
And the offline media build failed, just after 18GB download:
[Exception] System.AggregateException: One or more errors occurred. ---> System.IO.FileNotFoundException: /Users/<username>/Library/Caches/XamarinInstaller/Universal/downloads/repository-10.xml does not exist
How in the wrong order? Exactly as described on the page.
There is not much wiggle room, launch the installer with the switches, select a directory where to build the installer, go. There's not much that you can reorder.
Of course, on the second try, although the downloader caches whatever it downloads, it does not use that for the next round, it will throw it away and redownload everything. So 36 GB of traffic later, I gave up.
Oh I see, you found yet another set of instructions. I meant these: start the regular installer, pick manual installation from the app menu, it gives you a readme with direct download links. Download the components you want (none seem to add up to 18 gb, for me at least), install and run.
I don't understand. I've been using VS on Mac for the past 3 months to develop C# applications for a class of mine. Was that just a beta? What's so different about this?
Visual Studio vs Visual Studio Code. 2 different applications with really similar names. Visual Studio Code is lighter weight - more similar to Sublime/Atom.
Looks like during Xamarin installation: /Users/USER/Downloads/Install Visual Studio.app/Contents/MacOS/Install_Xamarin - Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSScrollView heightAnchor]: unrecognized selector sent to instance 0x6080003c0870'
More good news from the MS / Xamarin camp. A few years ago I 'bet the farm' on using Xamarin for Mac to develop a Mac version of our PC application (with shared code in a PCL); since that time Xamarin (and then MS/Xamarin after the buyout) have rarely failed to impress. Kudos to the team.
Any .NET MVC developers here? I always wanted to learn ASP MVC, but never did because I was scared of the deployment situation on Linux. Has anything changed in that regard? Would you say deploying a .NET web app works almost as smooth on Linux as let's say a node.js app?
Just installed Visual Studio for Mac (I've been using VS Code for a while on Windows and Mac) and first blush I'd agree. But to be determined after actual usage.
Code is definitely targeted to be lightweight, and it shows. I also am a fan of Code's look, versus the Mac wrapper around VS for Mac.
I'll probably give VS for Mac a try via a .NET Core tutorial, but for day-to-day JS dev I'll probably be keeping with VS Code.
Same strategy as always. Rebrand current products and call it new. This is not Visual Studio as known from Windows but Xamarin Studio rebranded. Title should be Microsoft release Xamarin update...
Coincidentally I was just using this & Xamarin Studio on mac today. I didn't realize VS Mac had released, I already had the beta.
So far I don't like it as much! Not sure what features are here I actually care about as I'm just using Mono. The pads no longer make sense in VS for Mac. I just have debug pads open all the time. I can't really tell when I've stopped debugging. There's weird buttons on the pads that do nothing. Not sure why all the clutter is here, Xamarin Studio had this stuff figured out.
I've been waiting for this for a while. Only trouble so far is that the installer comes up in the wrong locale for me (it ignores the language ordering in Preferences and displays the installer in my secondary/input language, not English, unlike fully native apps).
Is anybody doing professional development on .NET using VS for Mac? All this time i thought it was just Xamarin tools, but it looks like it actually has .NET Core project templates too. This has been the only thing that kept me away from Macs as a .NET dev.
Visual Studio for Mac's shell code is written in gtk+ 2. We have supporting code in gtk+ to allow mixing gtk widgets with native widgets.
But the glue code isn't used here, because there is another interesting mechanism at play. The root window created by gtk on macOS is actually an NSWindow (see GdkQuartzWindow), thus you can use Cocoa APIs on the window. We just set the title visibility to hidden and set the native titlebar widget.
That's not the opinion of everyone. Gedit for example has an up to date Windows version. Inkscape and GIMP both have macOS and Windows versions, but I think they still run version 2.
GNOME definitely is the focus as their resources are quite limited. That's why I welcome Microsoft using it and hope to see some improvements for Windows and macOS in the future.
I know ... am I the only one facing this predicament?
I have an early 2009 Mac Pro with OSX 10.9. I don't want to break anything so I haven't updated to Sierra but more and more apps are incompatible with my computer now.
So this Visual Studio for Mac is Xamarin studio repackaged as Visual Studio with tools and compiler/transpilers for .NET Core and the rest so you can do your usual stuff (in any other language) + apps on iOS/Mac/Android with C# with the Xamarin magic. Or ?
No. The Winelib implementation fizzled over a decade ago. Mono's WinForms implementation is managed, invoking a cleanroom C libgdiplus.so/dlyib for GDI+ calls
No Windows Forms, No XAML Windows app, No Windows store apps. .Net Core might run on Mac, .Net Desktop certainly doesn't. Calling it Visual Studio is misleading.
Not Windows Forms, no. But it is pretty easy to make cross platform .Net apps using Xamarin Mac. Business logic can share code, though UI likely needs its own code for each platform.
Definitely something wrong with the installer's language selection, got a Japanese installer when my primary MacOS language is English. Fortunately the installed app seems to respect the language setting.
Does Visual Studio for Mac have the same functionality as Visual Studio for Windows? If not then they should really stop confusing customers by rebranding a product that had nothing to do with Visual Studio for Windows.
I would guess this won't let you build/debug win32 or winforms or wpf applications, or install any .vsix extensions from the visual studio marketplace (of which there are lots of useful ones, such as this one to manage translations - https://marketplace.visualstudio.com/items?itemName=TomEngle... ) - correct me if I'm wrong, but if I can't install my .vsix extensions, this is not "the IDE you love, now on the Mac".