I quite like it. A few notes about some issues I had:
Don’t mix testing frameworks (MsTest, NUnit, xUnit). Live testing will use one or another test adapter, but only one at the same time. Depending on which one is active you will have tests excluded from live-testing.
Update your references. If can’t debug your unit-tests anymore with Live Unit Testing enabled, have a look at this support case. You might need to delete your existing project reference to “Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll” and install the NuGet packages MSTest.TestAdapter and MSTest.TestFramework instead.
Choose your tests wisely. You might want to exclude your long-running integration tests and other tests from being executed by Live Unit Testing: Right-Click on your test project, go into that “Live Unit Testing” entry and include and exclude what you need to be covered by Live Testing.
Included test files not updated automatically. If you have included test-data files in your project that are copied to your Output Directory by the build process: These are not updated automatically. I had to Stop and Start Live Testing in order to access added or updated files.
I just had an issue with a deployed ASP.NET app on Azure: I changed the connection string in the deployed web.config using the new App Service Editor in the Azure Portal, but the changes had no effect in my application!
This answer from StackOverflow gave me the hint I needed: My connection string was being overridden by an Application Setting in the Azure App Service. I didn’t even know that it was configured.
To see if you have a connection string defined in your Azure App service log into the Azure Portal, open your App Service and go to Settings -> Application Settings -> Connection strings.
Delete the connection string in the Azure application settings. Now you can change the connection string in the web.config using the App Service Editor, for example.
Use the Azure application settings to manage your connection strings. The values defined here will always override the connection strings from your web.config.
The ReSharper unit test runner doesn’t like test methods which are declared as “async void”.
Unfortunately you won’t get any compiler or intellisense warning to tell you. When trying to run the test in ResSharper unit test runner it will first get a blue question-mark icon and when you run it individually it will get the test result Inconclusive.
public async void This_Test_Will_Cause_Inconclusive_Message()
public async Task This_Test_Will_Run_Ok()
If I want to display a PDF file in the browser instead of downloading a copy, I can tell the browser via an additional Content-Disposition response header.
This code example assumes that the file content is available as byte-array, reading the content from a database, for example.
// Get action method that tries to show a PDF file in the browser (inline)
public ActionResult ShowPdfInBrowser()
byte pdfContent = CodeThatRetrievesMyFilesContent();
if (pdfContent == null)
var contentDispositionHeader = new System.Net.Mime.ContentDisposition
Inline = true,
FileName = "someFilename.pdf"
return File(pdfContent, System.Net.Mime.MediaTypeNames.Application.Pdf);
Please keep in mind that ultimately we don’t have control over the browser. We can politely request to show the PDF inline, but this can be overridden by a user configuration, for example.
Staring at our screen all day long can take a toll on our eyes:
I was forced to wear glasses a few years ago for which I blame my screen-time. Since then I am more conscious about the health of my “biological data interface” (eyes) and just got myself computer glasses with blue filter, although I am not sure if they are necessary. The information available on the web is contradictory, but I have an acquaintance who fixed her problem getting tired with computer-glasses.
What DID convince me though is this free tool for Windows-User: EyeLeo. It will ask me every now and then to exercise my eyes. Together with Tomighty Pomodoro timer I get the frequent breaks I need to finish my work days without my eyes hurting.
If you just published your web app to Azure with Visual Studio you probably won’t have a FTP account configured in your App Service. I just want to share how to set it up to enable downloading logs via FTP.
If you go to “MONITORING-> Diagnostics logs” in your App Service you should see the text “No FTP/deployment user set” in the field FTP/deployment username:
Use the page “DEPLOYMENT -> Deployment credentials” to set up a new FTP user:
If you go back to “Diagnostics logs” you will see the FTP/deployment username you can use to access the logs with the FTP client of your choice (On Windows I like to use WinSCP):
Important: You have to use the full FTP username shown on the “Diagnostics logs” page consisting of the App Service name, a backslash followed by the FTP username:
Hint: Try to avoid FTP and use FTPS instead to protect your credentials and data.