If they free up the developer license, MS will get lots of Apps in for their phone versions as well..They are already supporting javascript for native apps..
Node.js Tools for Visual Studio
111–120 of 127 posts
Re: Node.js Tools for Visual Studio
#112Honestly, it's good to see a lot of .Net developers getting to see some sunlight. A lot of really interesting things have happened in JavaScript land over the past few years, and there are a ton of really good programmers who have been in .Netland for far too long.
Re: Node.js Tools for Visual Studio
#113Earlier quoted context omitted.
Is this going to make it easier to deploy NodeJs apps to Azure then? Love Azure, but had a hard time getting my NodeJS stuff up to Azure without some major issues.
Same, and I gave up trying to get Node to work with SQL Server. Ended up at Heroku because of this.
The node MS SQL bindings are still terrible, so I haven't really bothered much with Node because of it
Re: Node.js Tools for Visual Studio
#114Gotta hand it to Microsoft. Behind the times on web dev for so long, now busting out open source left and right, teaming up on Angular with Google, jumping on with nodejs, modernizing their tools, "gently" pushing locked in MS web devs out of the darkness of that Web Forms madness into the light of real web development. I've always been a LAMP stack dev but they have at least caught my attention as of late.
>"gently" pushing locked in MS web devs out of the darkness of that Web Forms madness Minor nitpick on your otherwise positive comment, we have been using ASP.NET MVC for almost ten years now (ok eight). Webforms have long been a thing of the past, at least in the circles most devs I know move in.
From my admittedly limited perspective, it just NOW seems that Microsoft is really pushing for devs to meet up with real web development.
I can't tell you how many conversations I've had with MS devs who only know how to develop with web forms. They've never heard of grunt, node, MVC (the concept in general, let alone the option in .NET), SASS, NoSQL, RWD and the list goes on and on. It's like they've been living in a closet.
Not that they have to use ANY of those I listed -- but to KNOW such things exist!
For so long it seemed MS's mantra was "keep using only our stuff, its okay, don't look out the window at everything else going on". And so many that I've met just said "okay".
Now I feel there is a concerted effort from them to reverse that and really push education beyond the MS closet; it is very interesting to watch devs come out into the sun, blinking.
Again, just amongst the MS devs I've had the pleasure of working around, talking to online and off, at meetups and at jobs. But yes, only from my limited circle. Never meant to imply anything other than: I'm excited for MS devs and myself, as I'm actually wanting to dip my toe in the water as well and pick up .NET.
So nothing but excitement from me on it.
Re: Node.js Tools for Visual Studio
#115This is great news, but aren't there bigger fish to fry with really supporting node.js & npm on Windows? The 255 character path limit bug has been around for a long time and still unresolved/broken on Windows (see https://github.com/joyent/node/issues/6960 and https://github.com/npm/npm/issues/5641 ). Suggestions to fix it on the Windows side have been closed too: http://visualstudio.uservoice.com/forums/121579-visua…
MAX_PATH is the gift that keeps on giving . Thanks to Microsoft's fanatical dedication to compatibility I don't see how it will ever get fixed. I think they could take a lesson from Apple here and have DLLS/EXEs contain SDK versions against which they are built, then mandate that Windows 10 apps must support a larger MAX_PATH. Of course if they were into learning lessons, they'd have done fat binaries so a single ins…
Since the problem seems to be mostly with cmd.exe (and tools that use it), could not Microsoft ship a cmd.exe (with a modified name, so it does not break old stuff) that handles long path name by using the unicode API ?
Re: Node.js Tools for Visual Studio
#116Earlier quoted context omitted.
It's super cool for people wanting to do node on Windows. I used the beta while doing a small side project at my last job, and they worked well for that project. My issue isn't necessarily azure and VS. It's the state of node on Windows. It's a second class citizen compared to the versions for posix compliant OSes. There are things that just don't work on Windows without installing VS, which is undesirable for deploy…
Fwiw we have remote debugging to any OS, so you can remote debug your app regardless of whether or not it's running on azure. We are striving to streamline this experience as much as possible, so any feedback or ideas you have on how to mitigate some of windows issues you've run into would be super helpful. :-)
The two major issues I have run into with doing node on Windows are likely out of your control. First is the file path length limitation, which conflicts with the nesting of npm dependencies. Second is dealing with any packages that depend on node-gyp for compilation. It shouldn't require an entire IDE to be installed in production just to build your dependencies that need node-gyp compilation. Not to mention that the process is problematic even in dev if you're not lucky enough to have installed the exact expected dependencies. I found it easier (and more portable) to just use a VM running some *nix flavor (Ubuntu for me) and deploy to a similar environment.
Re: Node.js Tools for Visual Studio
#117Earlier quoted context omitted.
Technically... - connect is for filing bugs - uservoice is for "ideas and suggestions" How people use it, of course, is a completely different story... And then some teams (like us) have public issue trackers, which are the best approach if available because everything goes directly to the team: https://nodejstools.codeplex.com/workitem/list/basic
Ah I see. Yes I put a powershell bug/missing feature request on connect and looked through some other tickets. I don't envy whose reading that. I think Ms is doomed to get people complaining about unrelated junk any time they open a platform up.
Any ideas for how a problem like that can be solved? User feedback on a closed-source project at massive scale?
Re: Node.js Tools for Visual Studio
#118Earlier quoted context omitted.
Same, and I gave up trying to get Node to work with SQL Server. Ended up at Heroku because of this.
The node MS SQL bindings are still terrible, so I haven't really bothered much with Node because of it
Re: Node.js Tools for Visual Studio
#119Earlier quoted context omitted.
See comments on this thread re: max_path problems, workarounds, and how we help mitigate it in NTVS: https://news.ycombinator.com/item?id=9265694 Otherwise, yeah - we don't like it either... here's the not-closed uservoice request ;-) https://windows.uservoice.com/forums/265757-windows-feature-... EDIT: Re: fish: Indeed - we have some big fish to fry, but luckily msft is a big company that can fry multiple fish at a…
Why can't you (or node?) use the \\?\ syntax?
Node uses the Unicode functions so no need, but lots of tools in windows break (cmd.exe notably) so things like child processes don't work on long filepaths. You can actually watch `npm` write to files past the limit by using the Unicode functions, but trying to access them via child processes generally fails (and things like IDEs can't see them). The other problem is that using the longer paths turns of filepath expansion.
* https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
Re: Node.js Tools for Visual Studio
#120This is great news, but aren't there bigger fish to fry with really supporting node.js & npm on Windows? The 255 character path limit bug has been around for a long time and still unresolved/broken on Windows (see https://github.com/joyent/node/issues/6960 and https://github.com/npm/npm/issues/5641 ). Suggestions to fix it on the Windows side have been closed too: http://visualstudio.uservoice.com/forums/121579-visua…
Once again, these limitations are not with Windows itself (see all the C++ Unicode file functions / file longpaths). In general Node supports long paths just fine (you can watch `npm` write past the 260 [wtf?] char limit). The limitation is in other programs trying to respect MAXPATH even when they should be moving to Unicode functions for compatibility reasons / lack of knowledge. It should be noted that compatibility breaks not just from long paths causing errors, but automatic file expansion does not occur on long paths. So we get into even more special snowflake situations where sometimes files with expansions work with older functions but not with newer ones.
But the fact that Unicode functions don't expand adds an interesting problem for us; the MAXPATH respecting (and outdated) _A filesystem functions can cause a collision for non-expanded paths we get to fun things where you can have different FILE objects if you use old _A functions vs _W functions. The inverse is also true where you can collide by moving from _W to _A.
So! If we do start using old _A functions we actually can cause problems by directing to new files that would cause expansion because of file expansion being turned on.
* https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
* https://msdn.microsoft.com/en-us/library/ms813802.aspx
PS. Don't get me started on FS permissions...