So you have configured a new build for your ASP.NET application: the source code compiles without errors, there are no unit tests failing, the deployment package is generated and published as an artifact – great! Now it’s time to deploy it. Everything seems to be fine (no errors logged), but when you try to run your application you get an YSOD like this one:
There are many things that can go wrong with a deployment, so it is important to configure your deployment pipeline to verify that the deployment itself was successful. You can do it by using smoke tests.
I have an Azure App Service that is hosting 5 different WebJobs. I have configured a release on Visual Studio Team Services (VSTS) to deploy each WebJob to Azure, independently from each other.
Deploying a WebJob deletes the other WebJobs that were already deployed!!!
Tick the “Set DoNotDelete flag” – current files/folders in the App Service in will be preserved while publishing website.
The scenario – I am working on a new functionality solution that has many members marked as Obsolete (some are not being used at the moment and others will be removed in the future). When the solution is compiled warnings are being generated as follows:
And this is how things are supposed to work – other developers working in the same solution will know straight away that these members should not be used. It’s perfectly fine to diplay these warnings locally, but honestly I don’t think it makes sense to display them on the build server.
MSbuild has a property named nowarn that can be used to suppress compiler warnings. In my case, I want to suppress warnings CS0612 (‘member’ is obsolete) and CS0618 (‘member’ is obsolete: ‘text’).
In VSTS add the following to the MSBuild arguments to your Visual Studio Build task:
That’s it! No more ‘member’ is obsolete warnings will be displayed when running a new build. Remember to add the same arguments to other tasks that might use MSBuild (for example, I have another task that generates an ASP.NET deployment package which was generating the same warnings).
Add a new Powershell++ task after generating the package and configure it as follows:
The command takes the path to the SF package folder as a parameter. I usually set the SF project as the working folder.
Queuing a new build, you can see the results of the build and in particular the task that tests the SF package:
That’s it! With this solution you will know immediately if something is wrong with the package, saving you from the frustration of a failed deployment. This doesn’t mean that deployments will never fail, but hopefully you will be able to detect most or all of the errors in the deployment package every time you trigger a new build 🙂
I’m using Visual Studio Team Services (hosted agent) to automate the builds and deployments of .NET Core solutions.
You probably noticed that .NET Core builds take much more time compared to the traditional .NET builds. For example, when you run the command dotnet restore you might have noticed something like this being logged:
2016-09-15T11:15:39.1510337Z A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
2016-09-15T11:15:44.7529135Z Decompressing 0%... Decompressing 1% ... (text removed for brevity) Decompressing 100% 5523 ms
2016-09-15T11:16:05.7899968Z Expanding 0%.... Expanding 1%... (text removed for brevity) Expanding 100% 20548 ms
2016-09-15T11:16:29.7176084Z log : Restoring packages for C:\a\1\s\Development\Source\MyProject\UI\project.json...
As you can see, caching of the packages took almost 1 minute! As suggested in Stop wasting time during .NET Core builds, adding the following environment variables to your build definition can reduce the build time:
So basically DOTNET_SKIP_FIRST_TIME_EXPERIENCE will prevent the caching of the packages on the build machine, and NUGET_XMLDOC_MODE will prevent the download of the XML documentation for the packages. Unfortunately I couldn’t find much documentation about these variables, but check the blog post above for more details.
This happened to me today – I was getting the same error whenever I tried to debug an ASP.NET application using Visual Studio:
Unable to start debugging on the web server. Could not start ASP.NET debugging. More information may be available by starting the project without debugging.
My initial reaction was to check if there was something wrong in IIS, and I was right: the application pool used by the application I wanted to debug was stopped!
At that moment I realised that I changed my Windows password 2 or 3 hours before trying to debug the application. Given that the application pool was running under my credentials, all I had to do to fix the issue was to right-click the application pool and go to Advanced Settings > Identity and update my password 🙂
I was configuring a new build on Bamboo CI server for a ASP.NET application. The solution built locally just fine, but consistently failed on the build server. This was the error:
(BeforeBuild target) -> C:\Bamboo\src\MC-BUILD-JOB1\MyProject.Web\MyProject.Web.csproj(1851,5):
error : Could not write Destination file:
Access to the path 'C:\Bamboo\src\MC-BUILD-JOB1\MyProject.Web\Config\AppSettings.config' is denied.
So basically the TransformXml task was failing because the file Config\AppSettings.config was checked out as read-only in the build server.
Fortunately there is an easy workaround. The trick is to apply the XML transformations to a temp file and then use the Copy task with the OverwriteReadOnlyFiles attribute set to “True” to overwrite the file Config\AppSettings.config:
As part of an deployment project on Bamboo CI, I was running a powershell script to deploy an ASP.NET application to a Cloud Service on Azure.
Even though there was an error executing the script, Bamboo was setting the status of the Deployment to Success. Why? Because the exit code returned by the powershell script is always 0 (zero means successful execution).
After some research I was able to find a way to return the correct exit code in case of failure. I added the following lines to the top of my powershell script:
The trap statement includes a list of statements to run when a terminating error occurs – in this case, every time an error occurs the error message will be displayed and then the script will return a correct exit code indicating a failure. I am returning 1 but any value different from 0 (zero) will do the trick 🙂
public class FooService
private readonly ILogger _logger;
public FooService(ILogger logger)
_logger = logger;
public void Foo()
// Foo code goes here...
catch (Exception ex)
public void Bar()
// Bar code goes here...
catch (Exception ex)
This is a very common scenario that I’ve seen in many different places over the last few years – each method has some code wrapped in a try-catch block. To get rid of the code duplication is easy, we can move the try-catch block to a new method that will take a delegate as a parameter (code to be executed):
A few months I had to estimate how much time/effort was involved in localizing one .NET application. As part of this task I had to search for all the hard-coded strings in the source code that should be localizable, which is a tedious and very time-consuming task.
The good thing is that Resharper has good localization support which can save you many hours or even days of work – imagine having to go through all files and search for the strings manually! In this post I’ll show you how you can use Resharper to detect localizable strings and how you can enable or disable localization for a particular project, class, method or even an individual string.