Visual Studio Online Supports Cross-Platform Development
blogs.msdn.com
blogs.msdn.com
This is a major change in terms of what I would hear from a Microsoft Blog Post on Software Development Tools and especially Visual Studio.
I am afraid though that a lot of current .Net developers won't like this ( colleagues and because vNext is more command line based )
5 years ago I wouldn't even be surprised if MS websites intentionally didn't work in browsers not IE. Now this.
Arguably Microsoft opened quite a lot of stuff recently. After ASP.Net and .Net Core I remember WCF, Visual Studio Code and VSO offers like this (plus the git integration).
Can we please see the good here instead of asking for everything (and unrealistic stuff, tbh), now?
① Liberate your documents or Fosdem t-shirt is the common setup here..
Across a market, having two to five differently implemented competitive products results in innovation instead of stagnation with just one.
If you do something for the wrong reason, is the work tainted? Or is everyone who does your work on your side, regardless of who or why?
I agree the past few years was a mess for MS, but things are changing and so should the public opinion.
*In the end we wound up buying a new Mac Mini. We needed Mavericks for website testing.
I also don't understand what happens with my Windows 8.1 license after that ... so if I format my laptop after that first year, will I still be able to install Windows 10 on it? I'm not so sure I can, plus their wording on Windows receiving upgrades for "the lifetime of the device" is confusing; so does this mean that the notion of a retail license that you can move between PCs is gone?
So you see, Microsoft has yet to reveal their new licensing model, therefore I wouldn't be so quick to jump to conclusions ;-)
Your license of Windows 10 doesn't.
Windows 10 upgrade is going to be free to a large amount of users; I'd be willing to bet further Windows releases will also be free so at least that's one issue possibly resolved.
Are you saying "why would I spend 150 on a Windows 7 upgrade instead of paying $1299 for a Mac laptop where OS X is free?"
Is there a reason that you are not including the MacBook Air (not that it gets you that much closer to the $299 price-point).
You get what you pay for. You cannot compare the kind of computer Dell sells for $299 with the kind of computer Apple sells for $1299. When I need most mobility I got myself a $199 Asus Chromebook-like Windows box that now runs Ubuntu beautifully. It's cheap plastic, but I won't be terribly sad if it breaks.
Last time I bought a Mac, it was slightly cheaper than a similar Dell and much cheaper than a Thinkpad, which I'd have to reinstall and, possibly, deal with compatibility issues.
Compare to Windows, I am able to continue running very old software without having to upgrade them. OSX is not free (as in freedom). You can't legitimately virtualise it on non Apple hardware, yet running Windows on Mac hardware is very straight forward.
If I had to pick a platform for web projects though, I'd actually pick Ubuntu. It's very easy to automate.
Ubuntu is my preferred OS for work. Matching the servers my code runs on is great, even though I run my code inside VMs or containers (often with the last LTS release). As you mention, it's exquisitely automatable - I can do and redo configurations in seconds.
I also started to notice that to keep using the PowerPC Mac that some developers weren't releasing updates for PowerPC.
Specifically, maintaining backwards compatibility on OSX while marching forward with newer versions of the os has been a very big pain. We recently dropped support for OSX 10.6 because we simply could not get QT to statically compile on Yosemite, even after extracting the 10.6 SDK from a legacy xcode download. We did manage to keep 10.7 support though, thankfully, using the same SDK extraction method.
On Linux, the upgrade from QT 4.8 to 5.4 was the roughest. the number of dependencies dramatically increased, complicating the compilation of QT and breaking compatibility with older distros (specifically CentOS 6.x, where we hear the most complaints)
Windows & visual studio has always been our preferred developer environment, with the latest version of both. Maintaining support back to Windows XP has been particularly easy and painless. Where on Linux, it seems like the glibc requirements march forward with every release of gcc, and on osx it becomes dramatically more difficult to support older versions of the os with each new release.
A side note about QT on Windows - compiling QT and your application on the newest version of Windows helps a lot for customers on that platform - for instance, before we compiled on Windows 8, the application UI would default back to the legacy battleship grey theme, and simply rebuilding on Windows 8 with no source modifications fixed it.
I'm not suggesting you shouldn't try or use this option (I've always been a fan of most of Microsoft's dev tools), but I've been using bitbucket as my "side project" source code control system for free (incl. private repos) for years.
Do it. And I'm saying that as your fellow .net guy.
The only downside is that you will start hating TFS at work for being so God damn dinosaury afterwards ;)
This looks similar, but the following line made me want to give it a shot:
git-tfs is designed to work outside of any existing TFS workspaces.
Now the version control part of TFS is TFSVC and yes TFS does have the ability to host Git repos, but the number of Git repos at Microsoft is significantly, significantly smaller than then number of TFSVC based projects.
http://blogs.msdn.com/b/bharry/archive/2015/06/03/team-found...
Microsoft as a whole "gets" the need to move to better version control tools such as Git....but the larger products will take decades to move off of the internal version control tooling for example: Windows (Perforce\Product Depo), Office (Perforce\Product Depo), SQL Server (TFVC), etc.
That you'd want to use it at home makes me question your sanity.
honestly, i'd be really happy if my company ditched github enterprise to either of those.
Windows-the-desktop is fine, though I don't like it. Windows-the-workstation is, even with the plus that is Visual Studio, still a considerable distance behind even Linux, to say nothing of OS X.
Which wonderful Linux and OS X tools offer the debugging and profiling capabilities of Visual Studio, specially for multi-threaded code?
Which wonderful Linux and OS X tools offer code navigation across large scale enterprise projects and architecture design?
Which wonderful Linux and OS X tools offer UI tooling like XAML and Blend?
"...even with the plus that is Visual Studio,... "
And you're touting things you value in VS.
I think that he poster was saying that for them the good parts of VS don't make up for other shortcomings of windows as a workstation...
I have studied the Alto and Star and I can't imagine why you would think they are similar to Windows except in their insularity.
I am not aware of any UNIX shell that offers a REPL like capability by allowing to interact with system libraries, do IPC with existing applications or system devices.
.NET, COM and WinRT play a similar role as the rich programming frameworks Interlisp-D, Smallatalk and Cedar had.
Focus on a mixture of AOT and JIT code for the programming environments, with memory safe languages. Memory unsafe languages currently used on the lower levels and performance hotspots.
An IDE with graphical debuggers and incremental development support, as the main way to develop applications.
Focus on being a good workstation OS first, with server abilities as second focus.
Have been using Linux off and on since 2000. Later my job required .NET, so got into the MS stack but still kept playing around with Linux for things like IRC bots etc.
Then at work there was a major open source push, and we did a big project using Drupal. Used Eclipse and Netbeans(mostly this), deployed to Ubuntu server for dev and RHEL/CentOS for prod. I can sling Vim but never like Emacs(you need a second nose to type some of the shortcuts!)
I was DevOps because only I in the team had Linux experience beforehand. There were some good things but C# vs. PHP was no contest as was VS vs. Netbeans/Eclipse.
Ubuntu vs. CentOS/RHEL was quite annoying because there were small meaningless fragmentation differences like Apache daemon as httpd in one and apache2 in the other. Really? Why? I found myself raging at them sometimes.
After doing that for a year, back to VS and .NET and it felt like a relief. I liked the power of nginx though which we used as a reverse proxy for the Drupal project.
But, more to my original point: I like .NET. I've been using it since 2005. I have Visual Studio open in Parallels right now. But I do recognize that the environment is a trash fire the moment you consider doing anything remotely outside the lines, and the lack of a serious, user-focused glue system (PowerShell ain't it, it's obviously not designed as a REPL language from the jump) is crippling. Peter Bright over at Ars has suggested reviving the subsystem model for Windows and incorporating a FreeBSD layer, and I'm all for that. Because I don't dislike Windows. I just can't get things done in it.
If you could stop and take the time to learn the prescribed PowerShell way of doing things... its really very good. I used to be a VMS admin in another life and I've worked with free and commercial *nix and I love it.
I wouldn't dislike PowerShell as intensely as I do if I didn't know it. It's a convergence of bad design in the small--the grammar and the syntax--and in the large--how exploratory programming at a REPL is actually done. Maybe it's great for sysadmin work where something's on fire and must be addressed right-then-and-there, but I'm a programmer and I work to eliminate the need for sysadmin anythings. A shell is literally just a REPL for recording tasks for automation and desperately needs to not suck at that job.
Comparing it to zah/bash and ruby illustrates my point. It's got some fundamental differences to those environments. Providing a common argument parser is one. PowerShell is actually more than a Shell. Its an environment that can be hosted in a shell. That's my point. Commands are actually objects that are processed by the environment. If you get passed the "I know how things are supposed to work" attitude and look at how PS is meant to be used to administer a large number of windows systems you would see that it makes quite a bit of sense.
It is different then what you are used to and probably been using since you were in university. I wasn't rude or mean. I certainly can't be as indignant about things as you are while I'm on HN because of the downvote brigade. But hey, like you guys always say...you're right and I'm wrong because you have karma. Honestly, I tend to be pretty sharp when reacting to people as well so I'm trying to not take things as personally.
But your appeal to authority doesn't scare me...I've used stuff for a long time too. I just don't think that I'm better than other people because of it.
The job of "administrator" in an IT shop is a largely make-work one that can be done by automated systems and process-aware developers, and as an infrastructure and automation developer I am working towards that goal. PowerShell makes that harder than it absolutely has to be because of how blindingly difficult it is to actually iterate on a problem in a way that can be factored into a reusable process--the actual hands-on-keyboard experience is so stilted and stupid that finding the solution in the exploratory manner I described is significantly harder than it should be. As I've said elsewhere in this tree, it's easier to just solve a problem in C# than try to explore the space in PowerShell and reify it into a script. That's as scathing an indictment of a programming environment as I can make.
And absolutely nobody says that somebody's right because of karma. I've read through some of your posting history, though, and you go to that well a lot. Consider that maybe nobody likes that you play the oppressed martyr.
read this: how bout we just disagree and you leave me alone? there's no need to even reply to this. just leave me alone.
Which is why I think it's unfortunate that I don't really but that a Unix subsystem is the way to make programming on Windows better. All my problems with Cygwin or git bash all lie on the boundaries of interactions. The most annoying things are when you can't run a batch file in bash or when you launch a Windows program with a Unix-style path and ends up with garbage because no file actually exists with that path on NTFS. Adding transparent proxying or something similar just ends up being more of a pain because now its really difficult to debug when something inevitably goes wrong. Perhaps more importantly, even if you solve the filesystem issues you're still stuck with things like /proc.
Overall, I think I'd rather just have really lightweight and transparent VM access.
Even if you decided to re-invent all your UNIX scripts and tools on PowerShell, you'd be missing most of the composable tools that make UNIX what it is.
And PowerShell as a user interface is quite poor compared to, say, a 15-year-old version of GNOME Terminal.
Even if you decided to re-invent all your UNIX scripts and tools
on PowerShell, you'd be missing most of the composable tools
that make UNIX what it is.
Do you mean that PowerShell can't achieve the same composability that can be achieved on Unix, or that PowerShell lacks for example `cut`?
And this is especially egregious with the lack of a Swiss-army-chainsaw scripting language in .NET to begin with.
PowerShell is much more composable. Just consider how all nix commands must pack insane numbers of output options. In PowerShell - just because of composability - output formatting is not the responsibility of each command - it has been delegated to a small set of general-purpose output format cmdlets.
As for substitutability: this should be obvious. I can't substitute it because it isn't interoperable with literally everything else in the stack. It is Microsoft for Microsoft's sake and incompatible with the rest of the non-Microsoft universe in ways that, it must be noted, Apple did not do; while they have proprietary tools in their environments I can still use it with the bog-standard tools that exist on every other Unix machine I ever touch.
But personally I find working out command names in powershell much more sane, because of the Verb-Noun pair naming convention.
I learned Powershell mostly from Get-Help. I can usually figure out where to look for a command based on the naming conventions - essentially (one of x verbs)-(one of x nouns). They aren't always fantastic, but for example, Select-String is a little more obvious than grep.
A shell is a REPL. If your language makes actually writing things in that REPL hard, it is definitionally bad at Shell Stuff. I find it significantly easier to write code in C# and then transliterate it to PowerShell than to actually write PowerShell. That's a disastrously bad situation for a shell.
Yes, I am calling you out. I am challenging you to provide concrete examples where Powershell has less discoverability than bash or zsh. I am challenging you to explain why ISE - an environment designed specifically to combine REPL with script authoring - is "unacceptable".
And please, no more hyperbole or condescending remarks.
I would love to see it in other ecosystems, and the prediction that PS could go open source, along with the recent open sourcing of .NET core and CoreCLR gives me hope.
Cheers!
There is nothing about PowerShell that cannot be discovered through those 4 cmdlets.
If you frequently need to dig down to .NET you are doing it wrong.
Contrary to your previous assertions, PowerShell was designed for REPL from the outset, and it achieves that much better than any Unix/Linux shell, bar perhaps fish.
PowerShells commands (cmdlets) are inherently rich on metadata. You cannot create a cmdlet without exposing metadata which is then used by the shell to drive automatic type coercion, syntax charts in help as well as tab completion.
It is so intrinsic to the concept, that you'll automatically get tab completion for your own functions, and even for your own script files.
PowerShell was definitively NOT designed as an RPC layer. You claim to "know PowerShell probably better than most people", and yet you are unaware that PowerShell was specifically designed as a hostable engine.
It is hostable precisely because Microsoft wanted to have reusable script engine which could be used in-process (!) in administrative GUIs.
Unlike traditional shells, PowerShells cmdlets share memory space with the host (the shell when used as REPL) because it SHOULD NOT use RPC to manipulate objects.
You frequently use "appeal to authority" arguments, but the substance of your posts gives you away. You are certainly no expert on PowerShell.
PS is interesting and powerful, but tends to fall at the last hurdle in annoying ways (eg truncate text to window even when diverted into file), and doesn't have the same user community.
Even the path separator is different.
Powershell is certainly not a substitutable shell, but as a terminal emulator, what does it lack that you need as of Windows 10? My only real complaint is the lack of tabbed windows.
Though I am much more experienced with bash than Powershell, everything I've seen indicates that Powershell is anything but inferior. You have to learn new things (the built-in aliases help a little) but throwing around objects instead of text makes so many things less painful. SSH would be nice (I think the closest thing would be WinRM?) but that's coming now too.
I don't think everything needs to be Unix. Unix is great but it's showing its age.
Given the direction of MS, I'm hopeful that they'll do some real change under the UI hood of Windows, making it a real alternative to Mac OS X. Some of the apps I need to run (e.g., Lightroom) only work on Windows and Mac.
Don't put anything in there that you really care about, without using something like git-crypt.
You are more likely to leak information by just using your browser. Remember chrome does sent full URLs of your downloads/malware sites when detected back to its HQ. [1] or post a comment on Slashdot and get your entire computer port scanned for free. [2]
I thought it was common sense by now that if you have something sensitive to share do NOT use a cloud based chat or repository!
[1] Information regarding a potentially harmful site or executable file download (including the full URL of the site or executable file download) may be sent to Google to help determine whether the site or download is harmful. - https://www.google.com/chrome/browser/privacy/
The first time I noticed Microsoft was doing it, was not long after the skype purchase and moving to a centralized comm model; gchat for sure was not at the time, and decentralized skype wasn't either. Furthermore, following that chat, Bing started scanning a server that was not linked from anywhere on the internet. I find the correlation more than suspicious.
Anecdotal, but skype ads on a friend's computer tend to reflect chat subjects - which is NOT just "malware protection". I wouldn't know - I only use it with an iPhone 4 and its old adless client when I do.
> I thought it was common sense by now that if you have something sensitive to share do NOT use a cloud based chat or repository!
I thought it would be too. But I keep meeting people who have the general idea that "well, all my email is already on gmail/the cloud, and it's working ok - so I guess all cloud services are trustworthy". And it seems for this kind of people, until their own gmail gets hacked, nothing gets the message through - and sometimes even if their own gmail gets hacked.
I was a consultant for one (rather successful) company who keeps all their precious data on AWS (a few TB of it), without even a local copy, and I couldn't convince them that yes, even though Amazon probably has better IT and security than they do, it's still a SPOF, and if anyone (e.g. hacker) changed their data-at-rest, they would be none the wiser.
Common sense is not all that common.
I agree with apalmer and worry that as soon as they get some leverage over you, you are still in trouble. I can't predict the future, but I've found past behavior to be one of the best predictors, for better or worse.
But the thing for me is the cash is pretty damn good and some days you can get so much done its unreal. I've worked with Unix platforms for the same time (20 years now) and know both inside out and windows is way more flexible, particularly when it comes to the end user.
What comes after exbrace, extend is no longer extinguish though. Any sane person these days makes portability choices. We're rebuilding our stuff as microservices now (4MLoC C# projects won't survive without this). Now their stack is getting a look in because we're already experienced with it but if they shaft everyone this time, its trivial to port our services away to other tech. We rewrite most of our stuff perpetually so they'll evolve into zero risk.
I'll believe Microsoft has turned a new leaf once they've open sourced their Operating System's Kernel and their Browser Engine and stopped development on DirectX or handed it over to Khronos or ISO/IEC and/or open source it.
It's fine to have reservations about new technologies and companies' strategic shifts. Being a little skeptical is healthy. Objectively, you have to admit that there has been a massive sea change happening at MS over the past several years, and it's all moving if a common direction toward a more open embrace of the non-MS, open-source development community (I was as surprised as anybody when I saw that Azure supported non-Windows VMs, and I doubt they'll pull support for those).
While it's entirely possible (though I'd argue not very likely) that they could shift back to their old ways at some point, ask yourself this: Do you and the projects you work on stand to benefit from Microsoft's new direction? If so, you would be doing yourself a disservice not to try their products and services when you're ready. If they don't offer anything appealing to you, then what's there to worry about?
It would be interesting to poll HN to find out who got actually burned by EEE and how.
> We make it easy to integrate your custom tool or third-party service with Visual Studio Online using open standards like REST APIs and OAuth 2.0.
Other IDEs have auto-completion (even for Javascript) as well.
Some also have vi[m] plugins for edit keys, so it's the best of both worlds.
I've pondered learning how to use a tool like gdb or lldb and then using SublimeText for editing the code, but it looks like a lot more work than just clicking to set a breakpoint in an IDE. I'm curious to hear what non-IDE developers are using for debugging.
Typing in a method call on the line where you want to debug isn't much of a leap from clicking a breakpoint.
I am sure the situation is similar in other languages.
Honestly, back in 1994, gdb (as well as Borland Turbo Debugger) did way better auto-formatting of data than the MS C IDE did.
I have not used VS since 2005, but it's debugger seemed no better than Eclipse or NetBeans. I started using IntelliJ this year, it's portable, and it rocks. But it costs money, just like Visual Studio.
There really isn't much difference between typing :make and hitting F5. Both have syntax highlighting.
Where Visual Studio beats all others is:
- Debugger
- Intellisense
There are lots of other nifty features, but those two are what make me choose to use Visual Studio for some projects over Vim/shell tools.
Like NetBeans, JetBrains also have a vi[m] plugin, so you get both vim style rapid edit commands AND auto-complete, lookup, debugging, etc.
Does Visual Studio have the "Awesome Edition" on all 3 major platforms?
I recall having trouble with a library crashing under Linux. I looked over the build scripts for it, created a corresponding Visual Studio project for it in Windows, and got it compiling. I then stepped through it with the debugger, edit-and-continue to fix the issue, and then copying the working source code back over to Linux.
I probably could have used gdb, but the debugger in Visual Studio is so good it was worth it. Debugging in gdb is more work than it was to port the library over, and that sucks.
I use vi for files no larger than a page or two unless it's Java then right into Eclipse. I guarantee whatever you think you can do fast without a good IDE, even Visual Studio or NetBeans, I can do 5 to 10 times faster and better and more bug free and prettier and more stable and more maintainable.
Performance has not been a valid argument in this question for the past 5 years. And just because an ide has project wide refactoring and semantic search doesn't automatically mean it doesn't have good hotkeys or text transformation tools...
> Where is the line drawn between ide and text editor anyway
If you work with a dynamically typed languages and/or web things then things aren't so black and white.
Somehow though, I can't seem to silence the inner voice in my head that keeps asking: "Can a Leopard really change it's spots"?
It'll take a few more iterations of MS's displays of commitment to "Openness" to get me to believe that they have fully embraced the concept.
I won't be holding my breath ...
And, judging from the comments, its greatest strength is when it emulates git, ignoring their previous 2 source control products?
So, it depends. If you just care about a place to put your code, I'd say that's quite decent. If you want issue tracking I'd say 'you can have that'. What was shit/terrible in the past?
(My experience is based on a TFS setup on-premise, latest version/patches. VSO is usually ahead and better)
The thing about Visual Studio Online is frankly...
Really TFS isnt better than anything comparable for project management related stuff, meaning: scrums, work items, bug tracking, release planning/scheduling, kanban boards, burndown charts... Its just not that good.
TFS isnt really strong in source control either, for really super big enterprise stuff perforce vault etc are generally preferred, for large scale collaboration projects decentralized as in git is where its at, and small scale or 'slow to change' either git or svn is a better fit...
TFS is a deployment nightmare, and migrating between versions is a terrible time consuming experience...
Really TFS at this point's only real strength is good Visual Studio integration...
So a TFS client that's not in Visual Studio..... just isnt really competitive with 'average' tools, not even considerable against 'best of breed' tools
The thing is, I mostly care about my VCS. And TFS supports git natively now. No need to interact with anything else if you don't want to. No need to use the VS integration. Or the website (although that one did improve a lot in the last couple of iterations).
WorkItems are .. well. What do you expect from 'extensible objects based on XML that are used for tasks, tickets, and whatever you can come up with'? So .. yeah. I'd say it's subpar at builds, tasks, issues etc. - but again: You can host your repository there and ignore it, if you want (I do).
Especially your line about TFS's source control seems confusing, because I explicitly said that it only supports git or crap (TVCS or whatever that thing is called).
When I first joined, I couldn't believe what a cumbersome mess it was but as I've had to work on some of the infrastructure from time to time I am really impressed how it all fits together and how much can be surfaced right inside Visual Studio. (A separate team maintains our actual instance, thank god.)
The true pain as a developer comes from the poorly thought out UI which makes every little task click heavy. To make things worse, the UI is poorly threaded and seems to prefetch nothing. This means that drilling down into any area, especially the source control view leaves you waiting 1-3 seconds per item you expand.
There's also some weird usability holes, like why after 5+ years is undo unchanged a command still only found in the optional power tools utility?
The version control in TFS I'm not so sure about, and it seems obvious that some things aren't as powerful as they are in git, but if I rule out git because of repo size then TFVC looks quite appealing as far as centralized vcs goes. (really git only works up to a couple of gig of total history which is ridiculously small if you have a 10+ year project with a decent amount of binaries you want full history of). Most of the TFVC-bashing I read is from the early days (<2010) when TFVC seemed to want to emulate SourceSafe, by requiring checkouts. It's very hard to find any info on how TFVC 2013/15 compares to the alternatives.
TFS upgrading and maintenance scares me, but if you rely on VSO instead of on-premises, that part also feels manageable.
- Slow as molasses for every operation
- No offline commits. You do have 'client workspaces' now, which just basically means that the broken and insane 'The server remembers your last known state' goes away and you have something similar to svn: A local 'baseline'
- Branches are 'copies'
- Merges are a PITA
- Conflicts are a PITA
- Depending on what you're doing you probably _WILL_ need to get a specific version (and yeah, please overwrite) because get latest is broken/doesn't work (probably not relevant for client/offline workspaces anymore)
- (The UI is terrible. Far worse than the git CLI could ever be, in my world)
So, my preferences:
- Git
- Any other DVCS
- SVN
- CVS
- TFVC, SourceSafe etc., because they're the same thing in terms of usability for me (now, safety/stability is something else. TFVC would probably win when we check out the camera at the finish line).
It is really, really limited and bad.
I never got along with TFS source control, but git source control on VSO works great for me. I've worked with several private repos on VSO, then pushed to external on GitHub when they were ready to go public, and it was a non-event - commit history and everything came over as you'd expect. It's standard git hosting.
VSO also has a lot of other handy features like cloud-hosted load testing (https://www.visualstudio.com/en-us/explore/vso-cloud-load-te...) - 20,000 virtual user minutes free every month. If you have an MSDN account, you can apply your monthly Azure credits to test hours. It's a pretty good way to hammer a site, I've used it to test autoscale.
Disclamer: Microsoft employee (until they notice I'm posting on HN instead of replying to e-mails)