I’m running lots of Angular 2 using the CLI on OSX (and loving it).
I have one small issue…
Often after stopping the app, when re-running it I get
‘Port 4200 is already in use.‘
Here is a little linux magic for you:
lsof -t -i tcp:4200 | xargs kill -9 | ng serve
This will find the process using port 4200, kill it, then re-serve your application.
(Posted for my FireBootCamp students that are having this issue.)
http://tv.ssw.com/6628/asp-net-5-de-b… The change from ASP.NET 4 to ASP.NET 5 brings a whole lot of awesome to web development, but it’s the biggest change since MVC was introduced and the learning curve is massive.
SSW shipped 2 enterprise apps on ASP.NET 5 while it was still in Beta (wow, that hurt).
Don’t spend weeks trying to understand how to get your new project right.
This session isn’t just ‘hello world’, it’s the stuff we wish we’d known in those first head-scratching weeks.
Continuously deploying from GitHub to Azure should be easy. In this video I discuss 2 issues I found when deploying an API using ASP.Net 5
Here is what I was trying to do:
- I had a simple ASP.Net 5 Web API project.
For this demo, I just went file | New and chose the Web API Template for an ASP.Net 5 project
- I checked it into GitHub
- I went into Azure and created an API app (I could do the exact same demo using a Web App)
- Then I went in and configured continuous deployment in the Azure portal
It should have been simple…..
There are two issues:
#1: Even the most basic ASP.Net 5 project requires at least a B1 Azure instance size. For Free and Shared instances, there will be insufficient space for the build, even though they give you 1 GB of storage.
#2: If you want to successfully deploy an ASP.Net 5 project, even if it doesn’t require the wwwroot folder, you need to include it for Azure to recognise the project as an ASP.Net 5 project that needs to be deployed.
i.e. even for a pure web API project that serves no static content. If you don’t have a wwwroot folder the project won’t be published to Azure, the repo will just be pulled… then the app won’t run. (the project.json webroot setting appears to be ignored)
For the Microsoft Team:
- #1: I would like to be able to create a simple ASP.Net 5 API or Web project and continuously deploy it to Azure via GitHub.. and have it work on the Free instance size.
- I think it is important for developers interested in Azure to have the freedom to experiment without worrying about getting charged
- This may involve expanding the size of the free tier on Azure, or maybe it means making some exceptions about what is counted towards the 1 gb of storage…. but we want a frictionless entry to continuous deployment of ASP.Net to Azure
- #2 The second thing I really want to see is a few more smarts around how we identify if an application is a .Net app and if it needs to be pulled straight into Azure from GitHub, or wether it needs to be compiled and published. It appears at the moment it is looking for the existence of a wwwroot folder to make the decision. Suggestion: should we be checking for the existence of a project.json or a hosting.json and then checking for the webroot setting to assist in this determination? similar to the work being done on default logic around the webroot https://github.com/aspnet/Announcements/issues/94
ASP.NET 5 (formerly known as ASP.NET vNext), along with .NET Core, is Microsoft’s ground-up rewrite of the .NET Framework. It is designed specifically for modern cross-platform web-application development and involves a number of breaking changes and new concepts that the .NET developer will need to be aware of.
While everyone is making the move to MVC 6 (and it is pretty awesome), not everything is there yet.
Until it works out of the box, here is an easy way to wire up your MVC 6 project to log all exceptions to Application Insights.
Create the Application Insights resource via the Azure Portal
- Sign in to the Azure portal, and create a new Application Insights resource. Choose ASP.NET as the application type.
A resource in Azure is an instance of a service. This resource is where telemetry from your app will be analyzed and presented to you.
The choice of application type sets the default content of the resource blades and the properties visible in Metrics Explorer.
The key identifies the resource, and you’ll install it soon in the SDK to direct data to the resource.
Create the Exception Filter to log all exceptions
Figure: Add the ApplicationInsights.Web NuGet package
Figure: Create the Telemetry class to instantiate an instance of the TelemetryClient with your InstrumentationKey & the AiHandleErrorAttribute class that will log exceptions to Application Insights.
Figure: Wire up the ExceptionFilterAttribute in Startup.cs
I L.O.V.E. developing on my 15” MacBook Pro, but I had some fiddling to get it just right.
Here is a quick post about how I have it configured.
– Software: Parallels for Mac (I intend to check out VMware Fusion when I get some time.)
– I don’t use a BootCamp partition.
If you run Parallels from a BootCamp partiton you lose the ability to take snapshots, which I love.
In the future, when working more with mobile emulators, I might find that I need to boot natively into Windows and change to working from a BootCamp partition.
Figure: I allocate 8 of my 16Gb of RAM and 4 of my 8 ‘virtual’ CPUs because Visual Studio is still awesomely fast, and I often use the spare Ram and CPUs for other VMs (e.g. for testing older browsers)
Figure: My sharing settings.
The ‘Shared Profile’ setting determines if you integrate Windows into OSX. I don’t enjoy this experience at all.
Tip: Install DropBox on OSX, not in Windows and then tick ‘Shared Cloud’
As always, I love feedback and suggestions.
Yesterday Adam Cogan nominated me to take the ALS Ice Bucket Challenge, the idea of which is to raise awareness and funds for amyotrophic lateral sclerosis (ALS).
For those that don’t know much about it, ALS is a degenerative nervous disease that affects nerve cells in the brain and spinal cord, and causes them to die.
It’s a truly terrible disease, it’s cause is still a mystery and there isn’t a cure.
Please take a few minutes to read about this terrible illness. http://www.alsa.org/about-als/
Even better click the ‘Donate’ link on http://www.alsa.org/ and contribute to researching better treatmentments, and maybe one-day a cure for this terrible disease.
Here is Adam C issuing the challenge http://bit.ly/als-adamcogan
Here is my attempt
I get asked a lot about the secret to the success of FireBootCamp, and how we get such great results from our intense developer training.
The SSW.TV team kindly put together this collection of behind-the-scenes footage.
If you want to see more of the actual bootcampers in action during sprints 1 and 2 check out the following (more serious) videos
And here are the highlights from graduation day
I seriously love my Windows Phone… except for the availability of apps.
Making Visual Studio the best environment for multi-platform development will be key to the success of Windows Phone. If developers that need to build IOS and Android apps move to Visual Studio from the native options in order to get cross-platform compatibility, they are far more likely to ship Windows Phone apps as well.
Here is a very brief overview of the options for creating cross-platform applications in Visual Studio. If you aren’t across these options already, you should get reading. This is way forward!
Stay tunes, I’ll be writing a lot more about each of these options.
Option 1: Cordova for building web based cross platform applications
Watch Out: It takes effort and know-how to make these apps slick on underpowered, occasionally connected devices.
Option 2: Xamarin for building native cross platform applications
Build apps for iOS, Android & Windows Phone by writing all your common code in C#, and then building separate native User Interfaces for each platform.
Great Because: You get the full native experience on each platform
Watch Out: You need to build a separate UI for each platform
Option 3: Universal Windows Apps
Build apps that will run on Windows Phone, Windows 8 & XBox.
Great Because: The Windows platforms are converging. This is great news for Windows Phone.
Watch Out: You don’t get IOS or Android support.
One of the most common issues I am finding with teams moving from Team Foundation Version Control to TFS-Git is that they are including files in their repositories that they shouldn’t. The most common offenders are .suo user settings files, Nuget packages and Azure publish settings. Luckily, the solution is straightforward.
1. Ensure you have no pending changes.
2. Close the solution
5. Open the .gitignore file from GitHub that is specific to Visual Studio projects and copy the contents to the clip board. https://raw.githubusercontent.com/github/gitignore/master/VisualStudio.gitignore
Figure: the .gitignore includes a list of all of the files that you want to avoid committing to your repository
10. If you have included files in your repository that you wish to exclude from the repository but not delete from your local working directory refer to
on my page for