I have a TFS build using Web Deploy to publish changes to a high traffic website. Build places an AppOffline.htm when it starts. A lot of times build fails due to some dll file in use. Tried recycling app pool and stating/stop website before build, still fails.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets (4255): Web deployment task failed. (The file 'xxx.dll' is in use.
Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)
Only way to publish successfully is to stop the website for whole duration while publish is going on.
Check for any files marked read only.
Some have said anti-virus can occasional cause this error as well. Try ignoring your web files.
I'm also seeing an issue where a VS2015 Web Publish to an Azure Web App has recently started to throw an error advising that a DLL file is locked...
See
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment-272504519
Related
Short Question
Is there a way to programmatically download all of the Nuget packages needed to build/publish a solution and output them into a single directory that can be moved to a local Nuget repository?
Some Background
Where I work, most development is done on an air-gapped network (no internet). On a recent project, I was able to develop on our internet-enabled network. This happens to be the first application developed on the internet-enabled network and the first ASP.NET Core app we've ever developed. The solution builds, runs, and publishes just fine on the internet-facing network. I am now trying to move the solution to the air-gapped network, but I am having issues getting all of the dependencies moved over.
At first, the solution wouldn't build because of missing ASP.NET Core nuget packages; so I copied ALL of the nuget packages from the local cache on the machine that I used to develop the application to the local Nuget repository on the air gapped network. Now the application builds, but I can't seem to publish the web project (ASP.NET Core). I'm getting 25+ errors along the lines of:
Unable to find package runtime.any.System.Diagnositics.Tools. No packages exist with this id in source(s)...
Unable to find Nicrosoft.NETCore.App with version (>= 2.1.6)...
Unable to find...
I'm also getting a runtime error "This page cannot be displayed" when I try to run from visual studio (using IIS Express), but I'm not sure if that's a related issue. The unit/integration tests run fine.
I could try manually downloading each nuget package from Nuget.org and moving them over to the air gapped network, but it takes hours to get things moved from one network to another. Is there anyway I can automate the retrieval of all nuget packages required to build/publish a solution so that I can make a single transfer from one network to the other instead moving what I have and waiting to see what breaks? Preferably I'd like a exe or a PowerShell script that could look at a sln file and drop all the necessary nuget packages into a specified directory.
On your internet enabled dev env, you can browse to the root directory of your project and use:
dotnet restore --packages .\package\
This will use the directory called 'packages' as the local cache for the solution and all nuget files will be copied to it.
You can then include the same switch in your build, to ensure that the local cache is used.
dotnet build --packages .\package\
I answered two very similar questions a few weeks ago. Have a look at these answers to see if they help
Command to download a Nuget package with all dependencies to a folder
Is it possible to create a cache of nuget packages for computers without internet?
No matter how many times I attempt to deploy my recently migrated ASP.NET MVC Core 2.0 app from VSTS CD, I only see old builds that were created before I migrated the project and VSTS CI build steps.
No error messages. Everything is making happy noises. However, I have the build number injected into the appsettings.json so I can see which build is in production, AND I've made several tiny aesthetic changes just to know for sure there's a new build of the software out on production and I am 100% confident the latest build is not being served.
I migrated my web app from ASP.NET MVC Core 1.1.2 to ASP.NET MVC Core 2.0.0. The last two successfully deployed 1.1 builds were #259 & #260.
I updated the VSTS build process using the "preview" 2.0 steps and got it producing successful builds. This new build is #270.
The VSTS release process reported no errors when deploying to Azure Web Apps Websites in a Staging slot.
I swap the slots without any errors.
However, I only see builds #259 and #260 as I try and re-try to re-release build #270 manually and re-swap the slots after VSTS CD gives me a successful response.
At this point, I'm considering going into Kudu and just deleting everything to force Azure Web Sites Web Apps to give me an obvious error message.
Before I do that, however, I wanted to ask if there's anything obvious I'm missing? Unlike the CI feature, VSTS CD has no verbose logging (AFAICT) and I can't locate any logging on Azure Web App's side regarding deployment attempts.
Here's a history of the builds ... all successful:
For context, here's the overall pipeline:
Here's the definition for Azure App Service:
Update 8/24 10am:
This morning, based on #starain-MSFT's comment, I did the following:
In Azure, I stopped both staging and production slots.
Back in VSTS in the release definition, in the "Azure App Service Deploy" task, I checked and yes, "Publish using Web Deploy" was already checked.
I added a checkmark to "Remove additional files at destination".
I created a new release (#110).
I check the logs for the "Deploy Azure App Service" release task:
2017-08-24T14:53:01.7169084Z ##[section]Starting: Deploy Azure App Service
2017-08-24T14:53:01.7419076Z ==============================================================================
2017-08-24T14:53:01.7419076Z Task : Azure App Service Deploy
2017-08-24T14:53:01.7419076Z Description : Update Azure Web App Services, Web App On Linux , Function Apps, Mobile Apps using Web Deploy / Kudu REST APIs
2017-08-24T14:53:01.7419076Z Version : 3.3.13
2017-08-24T14:53:01.7419076Z Author : Microsoft Corporation
2017-08-24T14:53:01.7419076Z Help : [More Information](https://aka.ms/azurermwebdeployreadme)
2017-08-24T14:53:01.7419076Z ==============================================================================
2017-08-24T14:53:03.7273244Z Got connection details for Azure App Service:'beastmuffin'
2017-08-24T14:53:04.4099686Z [command]"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='d:\a\r1\a\BeastMuffin-CI\drop\270.zip' -dest:contentPath='beastmuffin',ComputerName='https://beastmuffin-staging.scm.azurewebsites.net:443/msdeploy.axd?site=beastmuffin',UserName='********',Password='********',AuthType='Basic' -enableRule:AppOffline -userAgent:VSTS_3ba069a5-b836-4fd5-9b7a-158f8f07399f_release_1_110_110_1
2017-08-24T14:53:05.4251931Z Info: Using ID '5285835e-1d30-414e-bcb6-288c207678ac' for connections to the remote server.
2017-08-24T14:53:16.2964958Z Info: Deleting file (beastmuffin\Accessibility.dll).
2017-08-24T14:53:16.2964958Z Info: Deleting file (beastmuffin\Accessibility.xml).
... about 3000 lines later ...
2017-08-24T14:54:43.0840845Z Info: Deleting file (beastmuffin\zh-Hant\System.Spatial.resources.dll).
2017-08-24T14:54:43.0840845Z Info: Deleting directory (beastmuffin\zh-Hant).
2017-08-24T14:54:43.0840845Z Total changes: 3009 (0 added, 3009 deleted, 0 updated, 0 parameters changed, 0 bytes copied)
2017-08-24T14:54:43.0980858Z Successfully deployed web package to App Service.
2017-08-24T14:54:44.9961584Z Successfully updated deployment History at https://beastmuffin-staging.scm.azurewebsites.net/deployments/1101503586484042
So, it looks like it deleted the old files, but did not deploy / add the new build's files to Azure -- HOWEVER the COMMAND to deploy (per the logs) did not throw any exceptions.
Just to confirm nothing really got deployed, I visit the site and see this now:
So, I'm guessing there's no files in the production slot at the moment.
Update 8/24 1pm:
One new pertinent detail as I continue to debug this.
The new (preview) App Service Editor shows that the .zip file has been moved to the /wwwroot folder, however it does not unzip it.
Based on the logs and the .zip file, I'm beginning to think that the "Deploy Azure App Service" task doesn't yet support ASP.NET MVC Core 2.0.
To that end, I've opened a support issue on the vsts-tasks GitHub repo:
https://github.com/Microsoft/vsts-tasks/issues/5111
This issue was resolved out on GitHub (github.com/Microsoft/vsts-tasks/issues/5111).
In a nutshell, the new Build step "dotnet publish" (under preview as I write this) allows you to zip up the artifacts.
However, I already had the old "archive files" build step that I never removed from the previous build definition for ASP.NET MVC Core 1.1.
So, the result was the build was zipping up the zipped publish. During release, the publish was unzipped once, leaving the inner zip file unzipped as it moved it to the Azure website destination.
My company uses TFS 2010 to deploy our web apps from our local environment to our development environment. Here's the compiled output in my local directory for one of our vended web apps, ProGet, (http://inedo.com/proget/overview) in question that isn't deploying correctly. I expect all of what I see below to deploy to our development server:
Here's my .xaml build file:
Finally, here's my solution in Visual Studio:
When I queue the build, this is what's built out to our development server - notice it's missing a bunch of files/folders, but it does include "Resources" and "bin" and web.config:
This app is a vended application, ProGet, an already developed corporate Nuget repository that we purchased a source code license for. Does anyone have any ideas what I might be doing wrong?
EDIT
Here's a screenshot of my local IIS and the window to the right is a result of right clicking the website and choosing "Explore". Notice the *.cs files. Weird they don't compile down.
The Default Build Template (DefaultTemplate.xaml) should output the same files you get when you compile locally.
However, from your screenshots it looks like you are using a custom build template xxxx_DeploymentProcess.xaml that is obviously doing something different with how it outputs the build files. There is no way for us (stackoverflow community) to know what your custom build process is doing.
You could try switching back to the default template, and we'd be able to help you then. But, there's a good chance that you are using a custom build template for a reason, and you might not want to eliminate it before you know what it's doing.
We have with success been updating our development web site at a daily basis using msdeploy from TFS2010.
This was working fine until we upgraded to VS2012, our application from .NET Framework 4.0 to 4.5 and ASP.NET MVC from 3.0 to 4.0. It look like all is well and assemblies deployed but nothing has actually been deployed.
I have been looking into this for two days now and can't figure out why this is happening and now I am running out of ideas.
Below is part of my build script in the way it has been working before the upgrade.
<MSBuild
Projects="$(SolutionRoot)\My.Web\My.Web.csproj"
Properties="MvcBuildViews=False;AllowUntrustedCertificate=True;AuthType=Basic;Configuration=Dev;CreatePackageOnPublish=True;DeployIisAppPath=dev.myweb;DeployOnBuild=True;DeployTarget=MsDeployPublish;MSDeployPublishMethod=WMSvc;MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd;UserName=UserName;Password=Password;UseMsdeployExe=True"
ContinueOnError="False"
/>
When the upgrade was initiated and my problem discovered we were using Web Deploy 2.0 but now we have upgraded to Web Deploy 3.0. I have also made sure we are building with ToolsVersion="4.0".
UPDATE --
msbuild.exe /p:AllowUntrustedCertificate=True
/p:AuthType=Basic
/p:Configuration=Dev
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath=dev.myweb
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:MSDeployPublishMethod=WMSvc
/p:MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd
/p:UserName=UserName
/p:Password=Password
/p:UseMsdeployExe=True
E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj
Now I also tried to run the above msbuild command from our TFS and no response which frustrates me completely. Nothing in the event log of TFS, nothing in log file no matter verbosity... Any ideas?
It does work using msdeploy directy like below;
<Exec Command=""C:\Program Files\IIS\Microsoft Web Deploy V3\MSDeploy.exe" -verb:sync -source:contentPath="E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj" -dest:contentPath="E:\dev.my.web",computername=https://10.xxx.xxx.xxx:8172/MsDeploy.axd,username=UserName,password=Password,authtype=Basic -allowUntrusted=True"
ContinueOnError="false" />
--
UPDATE 2 --
It appears Microsoft added a check for what type of projects that are publishable projects and our web application are not, since the Output Type is Class Library. This has been valid with v4.0 but apparently not for v4.5.
Anyone have an idea of what to do make it work again? Do I need to change the project type? Create publishing package up front and then deploy that? Or what?
--
Anyone else that has had the same problem? Have you found a solution to share?
Could there be an issue with version of MSBuild?
Here is what I would recommend. In VS2012 we have made it easy to automate publishing your web projects using the publish profiles which are created by the publish dialog. In your case create a new MSDeploy profile. When you create that profile we will save the settings into a file under Properties\PublishProfiles (or My Project\PublishProfiles for VB). The extension of this file will be .pubxml. Those files are actually MSBuild files, which you can customize if needed. You can continue to use the publish dialog as well. The password will be stored in a .user file and encrypted such that only you can decrypt it.
After you have created that profile you can publish with the command below if you are building the .sln file.
msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password>
If you are building the .csproj/.vbproj then you need to tweak this a bit in the following way
msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password> /p:VisualStudioVersion=11.0
More on why VisualStudioVersion is required at http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx.
Once you do this you will be able to build+publish just like you did previously. FYI we have shipped all these new web publish features for VS2010 in the Azure SDK https://www.windowsazure.com/en-us/develop/net/#.
Also in your question I noticed that you are specifying some custom properties, like MvcBuildViews. You can now place those properties directly inside the publish profile (the .pubxml file) if you want. Of course you can still pass them in on the command line if that makes more sense for your scenario.
More info on this at http://sedodream.com/2012/06/15/VisualStudio2010WebPublishUpdates.aspx.
If you take a look at the approach that we had for developers to automate publishing it was to specify properties and targets to be executed during the build. The problem with this approach is that this limits our ability to enhance the web publish experience. In the new release we have introduced an abstraction, the publish profile, which allows us to change the underlying targets of the web publish pipeline and your automation scripts will continue to run. Hopefully from this point forward you will not have to re-visit this issue.
I had much the same problem today. I too was trying to get a .NET 4.5 web application automatically deployed using a machine that did not have Visual Studio 2012 installed on it. There were a couple of minor differences in my situation, however: I was using TeamCity instead of TFS, and our solution was created with .NET 4.5 as opposed to being one that had been upgraded from .NET 4.0.
Nonetheless, I did have the same problem described. I'd use MSBuild to build the web app and deploy it to IIS, in much the same way. This approach worked fine on my dev machine. However, when I ran MSBuild on the CI server, it quite happily built the web app, but it stopped after that: no errors, no warnings, nothing, just a message that the build was successful. There wasn't the slightest hint of an attempt at deploying the app to IIS.
It seems MSBuild was missing the relevant targets to perform the web deployment.
The fix was to copy the folder C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web from my dev machine to the CI server, copying it to the same place on the CI server as it was on my machine.
Once I did that, MSBuild then grumbled about needing Web Deploy 3.0, but that was fixed easily enough. After installing that on the CI server too, MSBuild quite happily deployed the web app.
To extend Luke Woodward's answer:
I, too, found that deploying C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ from my local machine to the build server was the fix.
However, the real fix is to install the Microsoft Web Developer Tools as part of the VS 2012 installation, which will create this folder, among other things. This addresses Ieppie's licensing objection.
I tested this by...
Deleting C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\
Running the VS 2012 installer and adding MS Web Dev tools.
Verifying that, after the install, C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ was back.
I installed WIF runtime and SDK on my machine. I added Microsoft.IdentityModel.dll to my azure web application and locally everything is running great. I build simple web application which use Azure AppFabric Access control. I follow azure labs for that and as I told, local everything is great. When I published my web application to Azure, I'm getting following error :
Unable to find assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
I get it after Appfabric Relaying part is going to return url, after sign in on identity provider. The weird thing is that I set Copy Local to TRUE, because that .dll is not part of Azure GAC. I tried to publish it again, but I received same error. I found few same problems on the internet but with no concrete solution. Does anybody here had something similar and probably have a working solution? Thank you in advance
For anything that I need to deploy locally to Azure I make a copy of the DLL's in my project folder and reference them from there while setting copy local to true. Since doing this I no longer have any issues with DLL's not being published to Azure. I also do all of my building through the command line using MSBuild and publish the cspack by hand. This means that I do not rely on Visual Studio for doing the build or deployment.
I have run into this and solution described in this blog helped. You will need to run this command from your role startup task:
gacutil /nologo /i .\Microsoft.IdentityModel.dll
This startup task has to be run with full privilegies.
Have you tried disabling encryption on the creation of the deployment package and verifying that the dll is indeed present?
Create a new environment variable called: _CSPACK_FORCE_NOENCRYPT_ set the value to true.Restart your visual studio.