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).
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.