Tools such as Bower, Grunt and Yeoman have surged in popularity recently.
Whenever I've read about them or come across them in an article, I've dismissed them as tools used for Mac-based front-end devs or PC-based but not on the Microsoft stack - Sublime Text etc.
Visual Studio has NuGet, project templates, MSBuild, MSDeploy, TeamCity/TFS Azure etc. and I generally consider VS has being a very highly automated ecosystem (some say it makes us productive at a cost of understanding).
How are these tools being used by ASP.NET devs on VS?
Note: This is not an opinion-based question, I'm looking for real-world examples of how these tools are being used.
There is a Package Intellisense extension for Visual Studio which adds bower and npm package support
Grunt/Gulp launcher extension for launching grunt/gulp tasks
Read this awesome article written by Scott Hanselman for more info:
http://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNpmSupportForVisualStudio.aspx
UPDATE:
These features are now fully integrated into Visual Studio 2015:
http://www.asp.net/vnext/overview/aspnet-vnext/grunt-and-bower-in-visual-studio-2015
Great tips from john papa:
http://www.johnpapa.net/get-up-and-running-with-node-and-visual-studio/
As per Scott Hanselman's blog posting, he says this about the reason why a VS dev might want support for these tools:
Some of you may ask, why not use NuGet for JavaScript? Why not extend
MSBuild for building CSS/JS? Simple. Because there's already a rich
ecosystem for this kind of thing. NuGet is great for server side
libraries (and some client-side) but there are so many more CSS and JS
libs on npm and bower. MSBuild is great for server-side builds but can
be overkill when building a client-side app.
So, use both. These are tools in your toolkit. Adding support for
Gulp, Grunt, Bower, npm (and other stuff, in the future if needed)
means a more familiar environment for front-end devs doing ASP.NET and
it opens the doors for ASP.NET devs to bring in the JS and CSS
libraries communities use every day.
Though I'd still be interested in other people's take on how these tools fit in to the 'workflow' of a VS developer. For example, "Before I installed Grunt, I wasn't able to easily... blah."
Update
I'll stick some updates in here as I learn things.
So, new learning no.1: Yeoman scaffolds front-end, client-side code. Whereas VS scaffolds server-side stuff and project templates (that don't change for months/years), Yeoman can help with boilerplate for fast-changing JS MV* frameworks, for example.
New learning no.2: the tooling is not ready for prime-time enterprise dev.
The first problem is that npm downloads dependent packages into nested subfolders and recurses this model exhaustively, so you end up with folder paths that are 100s of characters long. Windows and some tooling goes nuts. There are workarounds but its a serious flaw.
Latest Node and some added command line options now make this better behaved.
Developers running Windows are often in enterprise settings which means proxy filters and auth. For me, I needed to install Cntlm local proxy to get NPM and other tools to work via our proxy, which violates our IT policy, I just didn't tell them.
Some of NPMs packages seem to want to clone Git repos using SSH! Port 22 is not open; because the community is so Linux/Mac non-enterprise oriented, such issues arise because they're not a problem for so many creative-agency devs and then can hang around for months.
New learning no.3: how dynamically downloaded JS files end up as content in the project file and thus added to an MS Deploy package is still an unknown.
Update on learning 3, we created a build that just transformed the config files, then we used the MSDeploy command line to copy files individually to the destination server. Not something I'd do if I were working alone, it took weeks on and off, to automate all this.
With Bower updates are faster. Every time a new version or update is released we can easily find it in Bower. You no longer have to wait as we had to with NuGet.
So we could say that NuGet continues to be the king in the server side, but Bower is the new king of client-land.
Take a look in this post for more details and see a simple example:
http://nearsoft.com/blog/bower-and-asp-net-5-a-tutorial/
To answer the original question with a perspective from both enterprise and casual development...
History
Visual Studio has always been a standard development tool for efficiently building large-scale enterprise applications for Desktop, Mobile and Web. This included both client-side and server-side web applications built using Forms, MVC and the .NET Framework. Of course, what makes Visual Studio so appealing is the power behind it, which gives developers the ability to quickly generate, or scaffold, common solutions via project templates - allowing developers to focus on solving business problems.
For simple client-side web sites that use a few libraries and require minimal data interaction, a tool such as WebMatrix would often suffice due to being lightweight and able to serve up web sites with ease.
Many of those tools and technologies can be found at Microsoft /web.
Divergence
At the same time, there has existed a burgeoning Open Source community that has been developing many of the libraries and frameworks that have risen in popularity for building modern web sites and web applications.
For developers working with the "Microsoft Stack" of technologies, the gap was originally bridged by integrating NuGet into Visual Studio. Many, but not all, libraries and frameworks were available as NuGet packages; and there was plenty of support from Microsoft for working with these technologies. Microsoft had also created it's own open source mini-ecosystem called CodePlex to support development and sharing of projects, usually focused on their technology in some way.
Unfortunately, while the availability of technologies was fairly up to date for Microsoft developers, it had become more and more challenging to keep up because it wasn't just about the libraries and frameworks, but the workflow and the way these technologies were being made available, integrated and used.
Such workflows include:
client-side package management via Bower from Twitter
(Bootstrap, etc.)
node-based package management via NPM
client-side application scaffolding via Yeoman (e.g. generators for ASP.NET and knockout)
automated task running via Gulp and Grunt
pre-compiling CSS from either SASS or LESS
transpiling languages such as ES6 or TypeScript
testing (Jasmine, Karma, etc.)
bundling and deployment (Webpack, etc.)
Unfortunately, much of this is a manual process, such as identifying the right package for the job or writing different tasks that can eventually be run automatically. Each is truly a subject in and of itself! It's not uncommon to end up simply looking up a package or command for something that in the end could - and Visual Studio developers would say should - be automated.
Convergence
Microsoft has been slowly moving from not only supporting open source development but embracing it. It has made many of its core technologies available to the open source community via GitHub, as well as it's own .NET Foundation movement.
A major effort to converge by Microsoft was to introduce Visual Studio Code for multiple platforms - offering a simplified development experience that caters to the workflow that has become popular with the open source community.
Still, Visual Studio Code can be viewed as a major step back for developers used to much of the power and simplicity offered through Visual Studio through its automation of tasks and project templates. Microsoft introduced Web Essentials for 2010 and 2013 editions to keep up; but as many have observed, this was simply more of an effort to show support rather than a full integration into developer workflow.
Behind the scenes, Microsoft was looking to put it's .NET Framework on other platforms and established .NET Core. As of Visual Studio 2015 - specifically Update 3 and Node Tools - there is much deeper support for the open source development workflow with integration of NPM and Bower, as well as task running. These still require manual intervention but it's on par with the workflow outside of Visual Studio. It still feels foreign, but it's getting there.
The Future
With all that Microsoft has invested, it is clear that the next step is to bring together much of the steps taken to embrace open source development by providing a more visual and automated experience to Visual Studio Developers. This will include templates that generate rich web applications which not only have all of the necessary packages and dependencies defined, but the ability to bundle for distribution.
In the meantime, I think this is a great time for Visual Studio developers to get a feel for the current workflow, if just to appreciate how "the other guys" have been doing it. It won't be long before much of it will be simply a click away.
Related
Upgrading MVC apps done with VS 2010 has been the biggest issue for me. I have an application that I use to run various websites and I maintain and develop this application separetely then upgrade the sites based on it. A lot of things might change during development of a new version - new Views, new Controllers, stuff added into JS files, updated stylesheets etc.
I've searched around the web but nothing useful came up besides this Haack's article but no source code is available.
I also tried making a Nuget package for the entire MVC app and while this works, it doesn't package up the resource files (an issue within Nuget itself) and my apps rely on those so until this is fixed I cannot use this method.
I checked how others do it and this pretty much summarizes Umbraco's way and it's the same painful way of a dozen of steps like I do it now.
Do you have any good advice on it?
You don't specify the target OS, but I create native packages, i.e. .deb for Ubuntu servers.
However this still means you need to specify all files, manage configuration, upgrade database schemes. But if you test this on a CI server it becomes more reliable, and you can do it iteratively. This is all part of good deployment practice. I can recommend the Continuous Delivery book.
we are developing white label web and mobile healthcare application for our clients. our product is evolving rapidly and we are supporting existing clients and going to support new clients.
current development workflow involves SVN for source code, requirement documents tracking and mantis for defect tracking.
We are considering VS TFS 2010 based Application life cycle management for our organization. we are hoping that VS TFS 2010 will help us streamline the following
1) Requirements Management
2) Source code Version control
3) Build automation
4) Test management
just wondering is anybody have experience using VS TFS 2010 and would like to share their experiences? is there any worthwhile alternatives to VS TeamSystem?
Preface: This is a personal opinion and I have no ties to Microsoft other than that I develop with their tools for their platform, even though I come across as a Microsoft lover in this answer. (which I am - I love .NET development)
I haven't used TFS 2010, but I HAVE used the 2005 Team Suite including TFS and the Visual Studio versions supported. We didn't move forward to 2008 or 1020 because of how extraordinarily difficult the 2005 version was to install. However, once we got it installed... Loved it. The project management tools were intuitive, and worked well. Setting up builds was a breeze, and it did everything I wanted it to do simply and efficiently.
Since then, however, we've adopted open source tools to do the same type of stuff. As I said, the install of 2005 was a NIGHTMARE and even though the 2010 version of Team Foundation Server installs VERY easily (I tested it myself and demonstrated it to the poor team who helped with the 2005 version just to show them how much better it is), I was unable to convince my team to give it a second chance. They chose to stick with tools that didn't need to be upgraded as often, and that were easier to upgrade when it did need to be done.
If it were just me, I'd be using it. This is one of those things where things just work right, and work together seamlessly. And the available documentation (MSDN, videos, etc) is exhaustive. I doubt any other set of tools is as well-documented.
It's just too bad that the experience with the older version was so bad that nobody else here will give the newer version a fair shake.
As for alternatives - it's not open source, but Atlassian has a nice set of tools. They work well for Java and we're using some of them in our .NET shop. We're using SVN for source control. That's about the only thing I like better about our new environment than I did the Team System.
I started at a new company 2 months back that uses TFS 2010 exclusively (for source control and issue/task tracking), and I haven't been able to get comfortable with it. Previously, I've mainly used SVN for source control and either OnTime (by Axosoft) or Fogbugz (Joel Spolsky) and have loved them both.
I don't know if it's the way they're using TFS (branching is nothing as nice as it was in SVN... and they have Product Backlog Items, Sprint Backlog Items, Bugs, Impediments, and god knows what else to keep track of) but I find it way too convoluted.
I think the tools a developer uses should assist the dev, not get in the way of. If I have to stop and think about how to branch code or assign an issue, then something's wrong with my tools (or I just need to spend more time learning them... which doesn't make sense to me either).
I'm about to begin building a website using the ASP.NET MVC framework and I'm trying to find a good solution to 1)Source Control Management and 2)Deployment. For the SCM, I'm probably going to use SourceGear since it integrates into Visual Studio nicely, but for deployment, I don't even know where to start. Up until know, most websites that I've built were very static and every time I had to update the site, I would use an FTP program and just drag and drop the files to the server. But now that I'm going to be building a much more dynamic web application, this approach feels dangerous (which, oddly enough, is also my middle name).
Does there exist some kind of idiots guide or tutorial that explains a good way to deploy an update to your website?
Thanks so much in advance for all your help!
Source Control
For source control, I like to use SubVersion at home. I would recommend using VisualSVN Server to install the server - it's free and ridiculously easy to use.
On the client side of things, I use TortoiseSVN (for shell integration) and VisualSVN (for Visual Studio integration). The small ammount of money for VisualSVN is well worth it, but there is a free open source equivilent AnkhSVN.
That's just what I use and there are many alternatives out there.
Deployment
I would definitely recommend using Microsoft Web Deploy.
Scott Gu just blogged today about it - Automating Deploy with Microsoft Web Deploy. There there is also Scott Hanselman's guide - Web Deployment Made Awesome: If You're Using XCopy, You're Doing It Wrong.
I recently came across a couple of posts by Jon Torresdal using Team Foundation Server (SCM), TeamCity (CI), and Web Deploy to implement a 'no-click' web deployment. They make for very interesting reading but they're definitely not what you'd consider idiots guide material.
No-Click Web Deployment – Part 1
No-Click Web Deployment – Part 2 – Web Deploy (a.k.a. msdeploy)
HTHs,
Charles
We will be doing a database driven logistics system for our Software Analysis and Design course. What we want to do is to work on the project simultaneously so that we can finish the project earlier. Is TFS the right tool for this? If yes, how do we start? What are the steps to set up the TFS? We use VS 2010.
Thanks.
This is a very broad question. TFS is an excellent code repository that does allow for multiple developers to have a centralised code base (which sounds like what you are after).
The first thing you will need of course is the TFS 2010 installation disk and ideally a separate box to install it on. Although the installation and set up can differ slightly on differing OS, i would recommend following the installation guide here and posting any specific and more detailed questions as you come across issues.
Is TFS the right tool for this: Maybe. It may be a bit much overhead to use for a course.
How do you start: If you have Visual Studio 2010 Ultimate, TFS should be included. Everything is installation wizard based, and the install (can) give you everything you need. For what you want, a stand-alone installation using SQL Server Express should be fine.
If you're looking for something lightweight that you all could use for source control, you might want to consider some of the git/svn hosting services (e.g. http://unfuddle.com). There's no direct integration with Visual Studio without a third-party tool, but it will give you the basics of being able to share source code among your team.
I zipped an ASP.NET MVC Azure project up and copied it to another computer (both have VS 2008). I thought I could just unzip it in "Documents\Visual Studio\Projects", but I can't quite get it working. My site builds, but the browser doesn't see the master page or Site.css. Should moving projects around as Zip files just work?
My real question is, what's the best way for one developer to share an ASP.NET MVC Azure project among 3 different computers? Should I use something like Dropbox or Live Mesh? Or, github maybe?
OP here. The problem was that "Static Content" was not enabled in IIS on the second computer. The latest installation instructions for Azure (March '09 CTP) omit this crucial step. The first computer originally ran the Jan '09 CTP, whose instructions included the step about enabling Static Content. Moving projects around by zipping them up seems to work fine.
I love using git and github. I've shared my code among many computers with it. This was C# with Visual Studio solution files, so it sounds very similar to your situation.
Of course, I love git for source code management. I'd recommend it to anyone, but there's a decent learning curve if you're new to it. I can recommend resources that helped me, since it was really only about 8 months ago that I delved into it for the first time.
If you're not looking to adopt git as your source code management tool, then you might want to look at other options for moving code between machines.
Perhaps your IIS virtual folders are configured differently on the machines? You said it builds, but does not run. This suggests that configuration of the web site itself might differ between the 2 machines (and we're getting into some things I'm not aware of about how ASP MVC works at this point).
Yes, moving projects around in a zip should work assuming all of your files are in the subdirectory you zipped up. Sometimes you might add files to your solution that aren't in the subdirectory, and that can cause problems. References to other files need to be relative, instead of absolute.
A problem you might encounter is if both of you edit the same file, or accidentally overwrite an edited file with one from a developers machine that doesn't have that change yet.
Most developers use a source control system to share projects. Git is a fairly new one that has a growing audience. Subversion has been around a little longer and is very popular. Visual Studio integrates with TeamFoundation Server.
ProjectLocker.com offers free subversion hosting(so that you don't have to setup your own subversion repository).
Codeplex.com offers Team Foundation Server hosting for open source projects.
It sounds like the type of thing you see if the app-root isn't an application, or if the application isn't handling virtual directories correctly.
With virtuals; for example, you should rarely use "/foo/bar" - because if your app isn't installed at the site root you'll get unexpected behaviour - you mean "~/foo/bar", but this often needs extra code, as discussed here.