Today, I was working on a sample project with ASP.NET vNext. I have been working on this application without any Visual Studio IDE support but I decided to discover what Visual Studio 14 CTP 3 is bring to the table. I know that Visual Studio CTP 3 has launched a while back and I was expecting to have trouble working with ASP.NET vNext beta builds (hot from the developer machine. Find them here). I was partially right. I wasn’t able to run the web application from Visual Studio. However, it’s still possible to debug the application and I have a workaround for you :)
As I was thinking from the very beginning that I would have trouble with VS 14 CTP 3 + vNext beta builds, I started setting up my environment from the command line instead of letting the VS handle this.
However, Visual Studio still insisted on installing the Aplha3 builds of the K Runtime but anyways. That’s not big of a deal as long as I have the beta one as the active runtime. When I open up the solution, everything looked OK. Even the package restore was successful.
The build was also working. Awesome!
So, it was all going great till I realized that I was building with the OutputType set to "Class Library".
As soon as I changed it to Web Application, the build broke:
This is OK and expected as things have changed since Visual Studio 14 CTP 3 shipped. However, I’m unable to debug my application now. Hmm, not entirely. There are still options and I went with the easier one. I switched back to command line and ran the application from there with "k web" command:
All good as you can see. Now, back to Visual Studio and press CTRL + ALT + P to bring up the Attach Process dialog box. We are looking for klr.exe to attach but you will probably see two instances of klr there. We need the one that actually hosts our application. You can find out which one is the actual host by looking at the command line arguments from the Task Manager.
In my case, it’s with the PID 1472. Finally, attach the process and you should be able to debug the application now.
Yesterday, I was looking into AngularJS which is a long overdue for me. I wanted to have a really quick test space on my machine to play with AngularJS. I could just go with Plunker or JSFiddle but I wasn’t in the mood for an online editor.
bower install angular -S bower install bootstrap -S bower install underscore –S
Then, I installed my node module to help me automate a few processes with gulp.
BTW, do you know VS has support for running you gulp and grunt tasks? Check out Scott Hanselman’s post if you don’t: Introducing Gulp, Grunt, Bower, and npm support for Visual Studio
Finally, I have written a few lines of code to get me going. The state the this tiny app can be found under my GtHub account. I was at the point where I would like to see it working in my browser:
As a developer who have been heavily working with .NET for a while, I wanted to hit F5 :) Jokes aside, what I only want here is something so simple that would host my static files inside my directory with no configuration required. While searching a great option for this, I found http-server: a simple zero-configuration command-line http server.
I simply installed it as an global npm module:
All done! It’s now under my path and I can simply cd into my root web site directory and run http-server there.
Super simple! It also observes the changes. So, you can modify your files as the http-server serves them. You can even combine this with LiveReload + a gulp task.
You may wonder why the title starts with "Basics". The answer is simple: I know only the basics of git rebase :) It's only one of the powerful features of git and it allows you to have a clean history in a highly branching workflow. "Rebase" is quite powerful as mentioned and what I'm about to show you is only one of the reasons why to use rebase. I highly recommend Keith Dahlby's NDC talk which he took some time to show the rebase feature.
Let's see the easiest sample where rebase comes handy. We have the following history where we have two branches: master and feature-1.
Typically, what you would do here is to merge the feature-1 branch onto master which is fairly reasonable and it works. However, it creates you a unnecessary commit + a ridiculous graph which would be a mess if you think of hundreds of branches:
What you can do with rebase is to patch the feature-1 branch onto master. Later then, you can merge from there. The following command is what you need to run:
After running the rebase command, we can run "gitk –all" to see the graph:
It's now nice clean history. Notice that the master is still pointing where it was. It's because we haven't merge the feature-1 branch yet. Let's checkout to master branch and run "git merge feature-1" to merge feature-1 branch onto master branch:
Nicely done! Open up the gitk one more time and see the clean history:
After we remove the feature-1 branch by running "git branch –D feature-1", we won't have any trace from feature-1 branch which is absolutely OK as feature branches are just the implementation details, that's all.
Rebase can hurt
With git rebase, at the very basic level, you are messing with the history which can be dangerous depending on the case. On the other hand, when you have a collision, it's not a picnic to solve those collisions with interactive rebase without a deep firsthand knowledge but it's worth looking into even if it seems hard at the first glance
We are all in love with Git but without GitHub, we love Git less. On GitHub, we can maintain our projects very efficiently. Pull Request” and "Issues" features of GitHub are the key factors for that IMO. You can even send yourself a pull request from one branch to another and discuss that particular change with your team. As your discussion flows, your code can flow accordingly, too. This is just one of the many coolest features of GitHub.
There is a cool Git extension for GitHub which is maintained by one of the founders of GitHub: Chris Wanstrath. This cool extension named hub lets us work with GitHub more efficiently from the command line and perform GitHub specific operations easily like sending pull requests, forking repositories, etc. It’s fairly easy to install it on other platforms as far as I can see but it’s not that straight forward for Windows.
You should first go and install msysgit on Windows and I am assuming most of us using this on Windows for Git. Secondly, we should install Ruby on windows. You can install Ruby on windows through RubyInstaller easily.
After installing ruby on our machine successfully, we should add the bin path of Ruby to our system PATH variable. In order to do this, press Windows Key + PAUSE BREAK to open up the Windows System window and click "Advanced system settings" link on the left hand side of the window.
A new window should appear. From there, click "Environment Variables..." button to open up the Environment Variables window.
From there, you should see "System variables" section. Find the Path variable and concatenate the proper ruby bin path to that semicolon-separated list.
Last step is actually installing the hub. You should grab the standalone file and then rename it to "hub". Then, put it under the Git\bin folder. The full path of my Git\bin folder on my 64x machine is "C:\Program Files (x86)\Git\bin".
Now you should be able to run hub command from Git Bash:
Special GitHub commands you get through hub extension is nicely documented on the "Readme" file of the project. I think the coolest feature of hub is the pull-request feature. On GitHub, You can send pull requests to another repository through GitHub web site or GitHub API and hub extension uses GitHub API under the covers to send pull requests. You can even attach your pull request to an existing issue. For example, the following command sends a pull request to master branch of the tugberkugurlu’s repository from the branch that I am currently on and attaches this to an existing issue #1.
hub pull-request -i 1 -b tugberkugurlu:master
I assume that you have probably started using Windows 8 RTM version as you are here checking out this blog post. If the answer is yes, you may have noticed that the usual "chlick" sound is not there when you navigate through inside the Windows Explorer (I am not sure if the preview versions of Windows 8 had this characteristic but if they do, they apparently didn’t bug me that much).
If you are a weird person just like me, it will eat you alive! Fortunately, it is not something hard to get it back. Just press Windows + W and type "system sounds". From the search results, click "Change system sounds" option as shown below.
Then, the Sound configuration window will pop up and from the Sounds tab, find the File Explorer > Start Navigation event inside the Program Events list. Finally, you will see that it has no sound attached to it. Just find the Navigation Start.waw from the Sounds dropdown list and select it as shown below.
When you apply the changes, you will get back the lovely sound back. I am not sure why they felt the need of leaving that out by default but the fix is easy as you have just seen.