Hacker News Reader

Comment by eterm | Hacker News Reader

My biggest hurdle right now with ASP is actually the tooling.

I'm a huge visual studio fan, it's far better than anything else out there for coding, but for ASP it's in a very strange place right now. It's not clear whether dependencies should be managed through nuget, npm, bower, grunt. It's not clear whether unit testing should be done through visual studio or through external test runners especially for javascript tests.

The move to client-heavy libraries has broken down what was a neat model for references and left visual studio looking a bit confused.

I hope what seems to be a move toward npm will help smooth this out.

View on HN

I'm using all of them in my project, as this seems to be the direction Microsoft is taking as well:

- Nuget for serverside .net (.cs, .dll) and msbuild (.target) dependencies

- npm for javascript development dependencies (grunt/gulp)

- bower for clientside dependencies (.less/.scss, .js)

I'm using the new VS online build stuff as well. In git, none of the dependencies are checked in. So the build starts with npm install, bower install and nuget / restore, then it runs gulp and finally msbuild.

I'm pretty happy with it.

this is exactly right. It isn't confused as parent says. They are no longer forcing js packages to be bundled into nuget where they tend to grow stale. The nuget angular package was actually maintained by scott hanselman. Why duplicate the effort when angular is published by the angular team on bower?

Instead of reinventing the wheel, they are leaning heavily on existing OSS that already does the job very well. eg: No more bundling in MVC, that is what gulp/grunt tasks do for the non MS world, so use that too.

No more MSTest which is a poor clone of Nunit, XUnit is the default tool and is used for all ASP.NET internal framework tests.

I agree with what you’ve said. The solution structure, msbuild and the general tooling all seems a bit confused.

It doesn’t help that sometimes dubious tooling was pushed as the correct way to do things, for example runtime JavaScript minification (a.k.a. bundles).

I think generally they are trying phase out some existing tooling while trying to adapt Visual Studio to new tooling.

TLDR; Right tool for the job.

Agreed - other stuff I'm doing has moved completely to tools like webpack with react and having a server that is just providing the API.

I've not yet worked out how ASP.Net and visual studio fit into that way of working.

I've seen plenty of APIs written in ASP.Net using Visual Studio, typically returning json and/or xml data, sometimes to a Javascript web front end.

In the current version, you start in ASP.Net MVC with an ApiController. In vNext, the ApiController is folded into the regular Controller infrastructure (1).

NancyFx (2) is also good for building data apis.

1) http://aspnetmvc.readthedocs.org/projects/mvc/en/latest/migr...

2) http://nancyfx.org/

Reply on news.ycombinator.com