free html hit counter
Posted on: Tuesday, 10 January 2017 by Rajiv Popat

I’m obviously late to the party but I’ve been hooked on to Visual Studio Code both as an editor and a complete IDE for developing .NET Core Applications and all I can say about Visual Studio Code and .NET core is that I am loving everything I see.

Getting up and running with .NET Console applications is really easy with Visual Studio Code and something I'll probably cover in a different post. This post is focused more around building and debugging ASP.NET Core applications using Visual Studio Code. In the posts to come we will build a simple real life application using .NET core and Visual Studio code.

I recently needed a simple application where I can store excerpts from various books and research papers I read for future reference and so that's the project I'm going to work on for the purposes of these posts. The code that we build during this series will eventually be open sourced and posted on GitHub.

In this post we get started with a simple ASP.NET Core project using Yeoman and the .NET Core CLI and we will then debug it using Visual Studio Code. Why do all this when we can build the same application using Visual Studio 2015? Even though we will build this application in Windows we want the toolset and code to be portable so that we can easily move to Linux or Mac and start developing there whenever we feel the need to do so; which is why we won’t use anything that we cannot use in a Linux or a Mac environment.

In fact, once we get through a couple of posts, we will actually move to a Linux machine and start developing there.

Let’s start by creating an ASP.NET Core app and setting up the debugging using Visual Studio Code. You can of course do this using two ways:

Approach #1: The .Net Core CLI:

This is probably the simplest and provides you with a nice clean ASP.NET Core application. Pretty similar to doing “File / New / Web Application” in Visual Studio if you happen to be a Visual Studio developer in the past. Some folks may love this because it’s straight forward. Others may not like it because it bundles a bunch of things (like the Entity Framework, Membership and stuff you may not even be interested in using). Plus as of now, it doesn’t seem to integrate things like bower out of the box (more on this later).  However, if you are looking to get up and running with a simple ASP.NET Core app up and running quickly you can start a command prompt window, go to the folder you want to create the project in and do:

dotnet new -t Web

This creates a simple Web Application project. To fetch all the dependencies the project needs you would have to do a:

dotnet restore

And to run the project (which also builds it automatically) you would do:

dotnet run

This would start the development web server and host the application which means you can now access it using http://localhost:5000:

And if you open your browser and hit the URL you have the application running:

We’ll come to the debugging part in a minute. Of course if you are not happy with a bunch of extra things that were added to your environment you can of course get more control over the templates that you use for stubbing out your application using Yeoman, which of course brings us to the second way of stubbing out your ASP.NET core applications.

Apporach #2: Yeoman Templates:

You will have to install Yeoman before you begin with this, which of course would mean installing NPM (and the simplest way of doing that is installing Node JS). Yeoman also fetches your Javascript files and files like the bootstrap.css from the right locations using Bower. So you are better off installing bower up front before you proceed.

Once you have Yeoman installed you can do a:

yo aspnet

From your command prompt once you are in the folder where you would like to create the project. Yeoman of course gives you larger control over the project you stub out by letting you pick from a host of templates that you can use (which would in turn decide which dependencies get installed):

In the above sample / screenshot we have an option of picking from different templates. We can pick a basic web application without Membership and Authorization OR just “Web application” which has everything (including membership and authorization pre-configured).  Of course with this I also get to pick between the UI framework that I would like to use for my project:

In the above example I’m going Bootstrap. Once done you would specify the name of the project and once that is done you can go ahead with::

cd research
dotnet restore
dotnet run

In the above command we switched to research folder because yo command creates a folder with your project name. Once you run the code with ‘dotnet run’ You get a similar application this time as you did with .NET CLI only this time around you don’t see the Login link on the top right corner of application:

Now that we have the application up and running (with both .NET CLI / Yeoman, depending on what you pick), let’s get to debugging it using Visual Studio Code.

Debugging Using Visual Studio Code:

The more I use Visual Studio Code the more I seem to like it. It’s light. It’s elegant. Works on multiple platforms and what I love about it is the ecosystem of plugins that turn a lighting fast editor into a full blown IDE! If you don’t have the IDE, grab a copy from here and install it on your machine. Now from the command prompt you can navigate to your project folder and type a “code .” (without the quotes) and you should see your project open. The “.” of course, stands for the current folder and in Visual Studio Code you don’t work with projects / solutions, you open specific folders. Which means if opening the project from command prompt doesn’t make sense to you, you can open Visual Studio Code and Open a Folder from File / Open menu. The moment you open the codebase in Visual Studio Code, it looks for required assets and asks you if it should import those. Click on Yes.

Like I said before, it’s the plugins that turn this code editor into a powerful IDE. I’ve jumped to the plugins tab, searched for and have grabbed the the following plugins I need to get started:

At this time if you were using Yeoman and had bower properly installed Your Launch.json should have the following value correctly set and you should be able to debug your application using debug tab and selecting “.NET Core Launch (Web)” from the debug type drop down and hitting the play button of the familiar F5 key:

If you started with .NET CLI tools (instead of Yeoman), you may not automatically get all bower dependencies configured in your bower.json file like Bootstrap and JQuery. So when you run the project with “dotnet run” it runs fine but when you Debug using Visual Studio Code so see things like Bootstrap and JQuery aren’t properly imported and you see your application looks like this (and the Javascript functions inside the application don’t work either):

This is where is pays to understand how Bower really works and how these templates are generated. The reason why your application runs fine when you execute it using “Dotnet Run” and doesn’t when you execute it using Visual Studio Code is that both (Dotnet Run / Visual Studio Code debugging) execute the applications in different modes. While “DotNet Run” executes the application in production mode, Visual Studio Code runs it in debug / development mode.

If you open your _layout.cshtml file you would notice that the template has generated a layout file that picks up bootstrap, Jquery and other dependencies from “~/lib” folder for Development environment and directly from ASP Net live CDN in case of production and staging environments. Since we are running in Development environment when debugging from Visual Studio Code we need the dependencies to be present in the “~/lib” folder.

If you check the wwwroot folder however you’ll see that the lib folder is missing:

To get the dependencies in the right folder we’ll use Bower to download the dependencies in the right folder. Where bower downloads the dependencies is defined in “.bowerrc” file:

And as the above picture shows our .bowerrc file does have the right location. We also have the bower plugin installed. So Let’s hit CTRL + P and Type “> Bower” in the search bar  that pops up:

Now you get a list of bower commands from which you can select Bower Install and hit enter:

The moment you do bower should grab all required dependencies for you and you should now see a new lib folder with the right dependencies:

And you are also able to debug the application properly now with Bootstrap, Javascript and other dependencies working fine:

Personally, I like Yeoman primarily because it provides a larger choice of templates and runs the “bower install” command pretty much automatically (assuming you have bower installed) but both .NET Core CLI and Yeoman should help you get started quickly with your first ASP.NET Core application. Both work across platforms and which one (Dotnet CLI / Yeoman) you use is just a matter of which templates you prefer.

As far a Visual Studio Code is concerned I love it. While Visual Studio 2015 Professional versions manage some of these tasks out of the box, Visual Studio Code is really nice because for me it hits the fine spot between showing me what’s happening under the hood at the same time keeping me sufficiently productive. This post covers two ways of getting up and running with an ASP.NET core project and you can use either of the two and all it takes us is a minute to get started with the setup and debugging on a new ASP.NET core project using Visual Studio Code.

In the next post we’ll get started with the actual application using ASP.NET Core where we will be creating a simple application where you can store experts from various books and research papers that you might be reading for future reference. As the series of posts proceeds I’ll dump the code on GitHub and also try and host it using the cheapest most scalable cloud options.

posted on Tuesday, 10 January 2017 13:52:02 UTC by Rajiv Popat  #    Comments [0] Trackback
Posted on: Tuesday, 06 February 2007 by Rajiv Popat

I've often said that the really good part about Windows is What can be done, or sometimes... what happens ("seemingly automatically"), can be undone (and explained). The same is also true for Visual Studio 2005. At rare occasions there are errors in the IDE which seem magical and mysterious. With the right debugging techniques, commands, some time the mysterious errors can be fixed and explained.

I've been busily coding away at Windows Workflow Foundation for a few months now. Currently I'm using the final released version of Windows workflow foundation with the released version of Workflow extensions for Visual Studio, and my experience with WF has been very good. So when this strange error popped up today without any particular reason, I was a little surprised.

The error wasn't very helpful in describing what was going wrong. All it stated was: Package Load Failure. It basically said - "Package 'Microsoft.Workflow.VSDesginer.DesignerPackage, Microsoft.Workflow.VSDesigner, version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' has failed to Load Properly (GUID = {some_guid}..." and then it went on to ask me If I wanted to disable my workflow foundation extensions for now.

Even though my workflow project opened and worked perfectly this was just an irritating error which popped up every time I started Visual Studio 2005. Determined to put an end to this harmless yet irritating error, I started my investigation and Google searches.

I started off with basic commands like - "devenv.exe /setup" - which did not fix the issue at hand. Then there were posts out there which suggested that I delete my native images and regenerate them using the ngen.exe tool. That solution did not seem to work either.

After a few hours of Google searches I came across this post which basically described what the issue was. Turns out, a few days ago I had tried my hand at writing Visual Studio Add-ins and had forgotten to delete an Add-In I had written. Remains of my HelloWorld Addin existed in "C:\Users\admin\Documents\Visual Studio 2005\Addins" on my Vista Partition.

All I had to do was to delete the ".Addin" file (which btw, had nothing to do with Windows Workflow Foundation, so it's a little difficult to suspect this would be the cause of the problem) and as soon as I had done that Visual Studio Started without any Windows Workflow Extension Add-in errors.

If this doesn't do the trick for you - here are few other commands / resources which are usually helpful in catching and fixing Visual Studio.NET 2005 IDE issues:

  1. devenv.exe /setup - very useful for a host of other IDE setting related problems or if you just want to restore VS settings to their original state. Did not help in my case because the failed add-in was something I had written myself and my problem had nothing to do with visual studio settings. In my case, the settings were just fine, even though I had initially suspected that they had gone corrupt. 
  2. ngen.exe - Aaron Stebner's Post describes this pretty elaborately. The basic idea here is to delete your Visual Studio Native Image files and regenerate them using this tool.
  3. devenv.exe /log - this generates XML log which can be quite helpful in trouble-shooting various startup issues with the IDE.

And if you're still struggling Aaron Stebner also provides a Definitive list of workarounds for Package Load Failure errors in Visual Studio 2005, here.

We spend so much of our time with the IDE everyday writing code. Mysterious errors like give us a chance to look under the hood and see what's going on. It's just like the joy of fixing that little problem in your car, yourself. After all knowing how to fix minor problems with your car, or knowing how to replace a flat tire, is also important besides knowing how to drive. Isn't it? :)

posted on Tuesday, 06 February 2007 18:02:34 UTC by Rajiv Popat  #    Comments [1] Trackback
Posted on: Saturday, 02 December 2006 by Rajiv Popat

I Posted this Hello World Article on Atlas (of-course, now called "Microsoft ASP.NET Ajax") on Code Project a few months ago. Recently, I've been receiving multiple emails / comments telling me that the article was helpful but I should think about updating it since Atlas is undergoing a lot of changes (including the name:)).

I've spent some time during this weekend to update the article based on the Beta 2 of Atlas (Microsoft ASP.NET Ajax 1.0) and resubmitted it to CodeProject for updation. The article has been updated and is available at CodeProject.

However, if are looking for one single zip which allows you do download the latest copy of article, and source code, you can get it here. This post will be updated when further changes are made to the article.

Thanks to everyone who read the article and commented on it.

posted on Saturday, 02 December 2006 12:33:08 UTC by Rajiv Popat  #    Comments [0] Trackback
Posted on: Wednesday, 29 November 2006 by Rajiv Popat

For the past couple of years my desktop ran on a Windows 2003 Server which was tweaked to make windows look like a Mac. I loved my desktop, but I also loved everything that had been going on the Windows Vista side and had been trying things out on VMWare instances and other non-work machines since the Beta 1 days. I had always stated that I would move to Vista as soon as Microsoft comes out with a Released version. Just wasn't adventurous enough to run a Beta version of an Operating System on my primary work machine. Yesterday, I finally made the move to Vista.

As a developer / geek, there were a few minor hiccups in 'getting up and working' and I'll probably post about all of those and their workarounds in other posts but this post is focused on getting Visual Studio 2005 to run with F5 / Play based Debugging on ASP.NET 2.0 Web-sites. I thought I would post about and document this, since this was the most tricky part and 'almost' kept me awake all night, trying to figure out what the heck was going on.

The Vista Install itself was a Smooth install. Minor hiccups here and there. Surprisingly, there were no drivers issues (things have come a long way since the Beta 1 days, when I had a bad time with the drivers). I didn't have to install a single driver manually. It detected everything on my Dell 700m and pretty much installed it, automatically. Sweet! Most hiccups were compatibility issues with 3rd Party tools, which is expected anyway, because of the enhanced security. Workarounds and alternate tools that work in Vista were pretty easy to find. Yes, there were some very minor issues with the default display drivers - which work fine with extended monitors but somehow, will not let me run on a external projector. I think I can live with that till Dell comes out with their own drivers. [This was resolved. If you googled to this page, in search of Intel-Adaptor-on-Dell Display Driver issues for Vista, see update at the end of the post.]

The real "Opps!" moment however, came when I was done with installing IIS 7.0 and started installing Visual Studio 2005. This is when I was warned that Visual Studio 2005 has known compatibility issues with Vista. I ignored the warning and the installation continued smoothly. Finally I decided to test my installation by making a simple ASP.NET 2.0 Hello-World website. Apparently, Studio would not let me open a website from the Local IIS.

The Warning Said: "You must be a member of the Administrator group on the local computer to access the IIS..."; This however, is a known issues and has to do with the Vista's On-Demand Administrator (i.e. UAC) feature. Installation of additional IIS components, A right click on Studio's Shortcut, followed by a "Run As Administrator" fixes this issue. There's a detailed post on this both as Scott Guthrie's Blog and MSDN. Both of these are pretty helpful and elaborate; So I won't repeat that information here.

After I did everything mentioned in the MSDN / Scott's Post, I could now open web sites from the local IIS. But wait, that was not the complete Fix. Once those steps were applied there were issues with Visual Studio which wanted me to have Integrated Windows Authentication in the Virtual Directory. Now this is something that is not installed by default with IIS 7.0. Which means that I had to explicitly go to "Turn Windows features on or off" and install Integrated Authentication for IIS. (I went ahead and installed all three since I am used-to and use all three - Integrated, Digest and Basic, in different projects. With this done I configured the virtual directory to use Integrated Windows Authentication using IIS Manager.)

So, was that it? Not Really. I still wasn't able to Debug my website. This time Visual Studio showed a security Dialog Box telling me that wasn't able to start debugging on the web server:

The workaround for this is to configure the site / virtual directory (depending on what you're trying to debug from Visual Studio) to run under the "Classic .NET Pool". To Do this just right-click the site on the new IIS Management console and click "Advanced Settings". In the Property Pane that opens up, change the Application Pool Setting to "Classic .NET AppPool" instead of "DefaultAppPool". 

With this done I opened my sample site in Visual Studio.NET 2005 and clicked the Play button (F5 key) and the Debugging worked, just like it should!

Yet another tricky Gotcha here is that changing the Application Pool for the website to Classic .NET pool doesn't seem to change the pool for all virtual directories under it. In other words, if you moved your entire site to DefaultAppPool but are trying to debug a specific virtual directory, you still need to go ahead and manually change the Advanced settings of that Virtual Directory to run Classic .NET AppPool, to enable debugging on it.

There were some 'really convincing' posts out there, that I came across, in a couple of Forums (I can't seem to find the link to those) where people suggested that F5 / Play and Debug is something you cannot do in Vista. I guess, that information is either old (from early beta builds) or just inaccurate. I would have liked to post a reply there and clear this up, but I can't seem to find the link again after reaching the right answer. So, I'm going to post this article here and hopefully Google will index it and help others who're trying to get this to work. 

Update [12/29/2006]: If you are looking for more details and other approaches, Mike has recently provided detailed step-by-step instructions on various approaches you can take and has described several tradeoffs associated with each approach. His detailed post is available here.

Update [02/07/2007]: Even though this post is not directly related to Dell 700m Intel Display Cards and Vista drivers for these cards a lot of people seem to be googling their way to this page in search of similar answers. This update might help. If you are running Intel(R) 82852/82855 Graphic Adaptor on Your Dell 700m and are having problems switching to clone mode with Dual Monitors or running on a Projector by pressing Fn-F8 key, start your Add New Hardware Wizard on Vista, select the manual driver installation process, choose Display Adaptor in the type of device and from the list of drivers Vita offers, choose Intel as Manufacturer, and "Intel(R) 82852 / 82855 GM/GME Graphics Controller (Microsoft Corporation - XDDM)" as your driver, even if Vista had detected your driver successfully during installation. Complete the Wizard and Reboot. Once the reboot is complete, you should be able to see two display adaptors with the same name installed in your Device Manager. Now disable Extended Desktop and should be able to switch to a projector or clone your desktop on your second monitor using the Fn-F8 key.

posted on Wednesday, 29 November 2006 10:52:23 UTC by Rajiv Popat  #    Comments [0] Trackback