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 - ) - 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 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. 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. Definitely keep the feedback coming 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.
MonoDevelop is an open-source integrated development environment for Linux, macOS,. 'Looking for Bugs in MonoDevelop'. ^ Cogswell, Jeff (4. First, open Safari β unless you installed something else on the Mac already β and download Xamarin Studio for Mac. This is simple β go to Xamarin.com, and download the installer. Open the installer on your Mac from the Downloads folder, and click Open when it warns you that itβs an application downloaded from the Internet.
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? 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 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.
![]()
SighI can and I do. Don't be so unimaginative.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. 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?
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 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. 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. 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! 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.
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 pythonWasn'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. 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. 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:).
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!
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. 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 extensionsXamarin Studio = MonoDevelop + extensionsMonoDevelop = 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.
![]() Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
January 2023
Categories |