Following the instructions on the ASP.Net Core 2.0 announcement blog post I was quickly able to get a website updated to ASP.Net Core 2.0 and run it locally.
The website is hosted on Azure in the App Service model and unfortunately after publishing my project I encountered IIS 502.5 errors. Luckily this was in a deployment slot so my public website was unaffected.
After a bit of head scratching I found two extra steps were required to upgrade an existing web site.
Firstly In your .csproj file you should have an ItemGroup like the one below:
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.1" />
You need to change the version to 2.0.0.
Secondly you need to clear out all the old files from your Azure hosted instance. The easiest way to do this is to open Kudu (Advanced Tools in the portal), navigate to the site/wwwroot folder and delete them.
After that if you publish your website again it should work fine.
Hope that saves someone a few hours of head-scratching.
Modern applications are complex and often rely on a large number of external resources increasingly accessed using HTTP – for example most Azure services are interacted with using the HTTP protocol.
That being the case it can be useful to get a view of the requests your application is making and while this can be done with a tool like Fiddler that’s not always convenient in a production environment.
If you’re using the HttpClient class another option is to pass a custom message handler to it’s constructor but this relies on you being in direct control of all the code making HTTP requests and that’s unlikely.
A simple way of capturing this information without getting into all the unpleasantness of writing a TCP listener or HTTP proxy is to use the System.Diagnostics namespace. From .net 4.5 onwards the framework has been writing HTTP events to the System.Diagnostics.Eventing.FrameworkEventSource source. This isn’t well documented and I found the easiest way to figure out what events are available, and their Event IDs, is to read the source.
Once you’ve found the HTTP events it’s quite straightforward to write an event listener that listens to this source. The below class will do this and output the details to the trace writer (so you can view it in the Visual Studio Debug Output window) but you can easily output it to a file, table storage, or any other output format of your choosing.
To set it running all you need to do is instantiate the class.
If you’d like to see this kind of data and much more, collected, correlated and analysed then you might want to check out my project Hub Analytics that is currently running a free beta.
I recently moved a bunch of documentation into the Markdown format as I wanted to render it into multiple output formats and inside multiple hosting technologies – including an AngularJS based single page applicaiton.
While doing this I decided it would make sense to have a single source of truth for these files and so placed them as content inside my MVC 5 based website that is entirely public access. After dropping them into the website the first step is to configure ASP.Net to serve the content which involves adding the below to a web.config file:
Hope it’s useful to you.