Azure-pipelines-tasks: .Net Core 1 & Deploy AzureRM Web App

[Kizmar]

Getting "Error: Source does not support parameter called 'IIS Web Application Name'. Must be one of (). Error count: 1." when using a "Deploy AzureRM Web App" task to deploy a .Net Core 1 app package build with "dotnet publish". I tried these suggestions with no luck.

I realize Core 1 has not been tested with this task, but wanted to open a new issue to see if it can be reviewed again.

The msdeploy command being generated is this (some values replaced with "---" for security reasons): "C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package="C:\a------\drop\287.zip" -dest:auto,ComputerName="https://---.scm.azurewebsites.net:443/msdeploy.axd?site=mySite",UserName="myUser",Password=---,AuthType="Basic" -setParam:name="IIS Web Application Name",value="mySite" -enableRule:AppOffline -setParamFile:C:\a------\drop\src\WebApi\setParameters.xml -userAgent:"---"

Note: I have tried this with and without adding either of the setParamFile or declareParamFile arguments. None helped.

[Kizmar]

I ended up getting this to work by using a Command Line task instead of the AzureRM task. I think the problem is that task adds -setParam:name="IIS Web Application Name",value="mySite", which is not necessary, and is causing the issue. You don't need the parameters.xml for the deploy to work.

This worked:
Tool: C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe
Arguments: -verb:sync -source:package="$(Build.BuildNumber).zip" -dest:auto,ComputerName="https://mySite.scm.azurewebsites.net:443/msdeploy.axd?site=mySite",UserName="$mySite",Password=$(Password),AuthType="Basic" -enableRule:AppOffline

[eriksteinebach]

I have been trying this as well. I could get rid of this error by creating a webdeploy package with parameters.xml file containing:
<parameters> <parameter name="IIS Web Application Name" defaultValue="MySite/MyApp"> <parameterEntry kind="ProviderPath" scope="IisApp" match="@defaultValue" /> </parameter> </parameters>
And using msdeploy to build the package:
msdeploy -verb:sync -source:contentPath=%cd%\bin{APPNAME}\ -dest:package=$(Build.ArtifactStagingDirectory){APPNAME}.zip -declareparamfile:parameters.xml

Then on deployment I add a setparams.xml file:
<parameters> <setParameter name="IIS Web Application Name" value="{APPNAME}" /> </parameters>

But then I got stuck with another error:
Error Code: ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER
More Information: Unable to perform the operation ("Create Directory") ....
Error: Access to the path 'C:\a' is denied.

I get the impression that the contentPath is now not correctly recognized, it is a path and not the name of the website (which it should be I think):
Info: Adding MSDeploy.contentPath (MSDeploy.contentPath).
Info: Adding virtual path (C:\a\1\s{SOLUTIONNAME}\src\Client\bin{APPNAME})
Info: Adding directory (C:\a\1\s{SOLUTIONNAME}\src\Client\bin{APPNAME}).

The msdeploy command running is:
-verb:sync -source:package="C:\a\ca433ad96{RELEASEBUILDNAME}\drop{APPNAME}.zip" -dest:auto,ComputerName="https://{APPNAME}.scm.azurewebsites.net:443/msdeploy.axd?site={APPNAME}",UserName="${APPNAME}",Password=**,AuthType="Basic" -setParam:name="IIS Web Application Name",value="{APPNAME}" -enableRule:DoNotDeleteRule -enableRule:AppOffline -setParamFile:"C:\a\ca433ad96{RELEASEBUILDNAME}\drop\parameters.set.xml"

The full error message:
Error Code: ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER
More Information: Unable to perform the operation ("Create Directory") for the specified directory ("C:\a\1\s{SOLUTIONNAME}\src\Client\bin{APPNAME}\"). This can occur if the server administrator has not authorized this operation for the user credentials you are using. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER.
Error: The error code was 0x80070005.
Error: Access to the path 'C:\a' is denied.
at Microsoft.Web.Deployment.NativeMethods.RaiseIOExceptionFromErrorCode(Win32ErrorCode errorCode, String maybeFullPath)
at Microsoft.Web.Deployment.DirectoryEx.CreateDirectory(String path)
at Microsoft.Web.Deployment.DirPathProviderBase.CreateDirectory(String fullPath, DeploymentObject source)
at Microsoft.Web.Deployment.DirPathProviderBase.Add(DeploymentObject source, Boolean whatIf)
Error count: 1.

Is this familiar to anyone?

[Ajay-MS]

@eriksteinebach Parameter.xml that you are passing to msdeploy is not complete. Please refer following sample parameter.xml file generated by Visual Studio .

<parameters>
  <parameter name="IIS Web Application Name" defaultValue="Default Web Site/WebApplication1_deploy" tags="IisApp">
    <parameterEntry kind="ProviderPath" scope="IisApp" match="^<PATHTOWEBAPP_CONTENT_FOLDER>\\PackageTmp$" />
    <parameterEntry kind="ProviderPath" scope="setAcl" match="^<PATHTOWEBAPP_CONTENT_FOLDER>\\PackageTmp$" />
  </parameter>
  <parameter name="Add write permission to App_Data Folder" description="Add write permission to App_Data folder" defaultValue="{IIS Web Application Name}/App_Data" tags="Hidden">
    <parameterEntry kind="ProviderPath" scope="setAcl" match="^<PATHTOWEBAPP_CONTENT_FOLDER>\\PackageTmp\\App_Data$" />
  </parameter>
  <parameter name="DefaultConnection-Web.config Connection String" defaultValue="Data Source=(LocalDb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\aspnet-WebApplication1-20160330024648.mdf;Initial Catalog=aspnet-WebApplication1-20160330024648;Integrated Security=True">
    <parameterEntry kind="XmlFile" scope="<PATHTOWEBAPP_CONTENT_FOLDER>\\PackageTmp\\Web\.config$" match="/configuration/connectionStrings/add[@name='DefaultConnection']/@connectionString" />
  </parameter>
</parameters>

Issues you faced - Error Code: ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER More Information
It occurs when following parameter entry is not being defined in your parameter.xml
<parameterEntry kind="ProviderPath" scope="IisApp" match="^<PATHTOWEBAPP_CONTENT_FOLDER>\\PackageTmp$" />

[Ajay-MS]

@Kizmar , @eriksteinebach Thanks for providing your feedback to us. Your feedback are really helpful to us. We are in progress for providing support for ASP.NET core 1 support in AzureRMWebApp Task. This feature will be there soon.

[eriksteinebach]

Thanks for your response. I have been trying it out, but I can't get it to work. I made the parameter file into:

<parameters>
  <parameter name="IIS Web Application Name" defaultValue="..." tags="IisApp">
    <parameterEntry kind="ProviderPath" scope="IisApp" match="^...\\PackageTmp$" />
    <parameterEntry kind="ProviderPath" scope="setAcl" match="^...\\PackageTmp$" />
  </parameter>
</parameters>

Because I don't feel I need the other parameters. But I think I am not filling the match property correctly. I tried the Web App Name, the one you fill in the Web App Name field And I tried the path to the published folder: C:\a\1\s...\src\Client/bin/release/netcoreapp1.0/publish, but both didn't work. Both give the same error. Can you tell me what this match property should look like?

[VaticanUK]

I'm also having this issue.

Weirdly, it _was_ working by simply zipping the output of
dotnet publish -c $(BiuldConfiguration)

without any parameters.xml being present, but at some point since last Thursday it's stopped working and now complains that "Source does not support parameter called 'IIS Web Application Name'. Must be one of (). Error count: 1."

Adding a parameters.xml file with just
<parameters> <parameter name="IIS Web Application Name" defaultValue="..." tags="IisApp"> </parameter> </parameters>

and then adding parameters.xml to "publishOptions": { "include": [] } in project.json has fixed it again, but it this feels really clunky and like it shouldn't be necessary (especially since somehow my deploy _was_ working without it!)

[Ajay-MS]

@eriksteinebach you need match parameter only if your content is not at root folder. To understand it you can create a webapp pacakge from Visual studio and unzip it check its parameter.xml
WebApp Deploy Package using visual studio

[Peter-Juhasz]

We experience the same as @VaticanUK, simply zip the published content of our ASP.NET core web apps which worked fine for many weeks, but now our releases started to break suddenly and we can't release.

On the other hand we can't use the Classic task because files often get stuck in use even if we deploy using Auto Swap, so we need to take the app offline when publishing.

[Ajay-MS]

@Peter-Juhasz can you share logs at [email protected]. It will be helpful to debug issue .

[BernieWhite]

Same issue.

[Ajay-MS]

Current behavior of task works only for package which contains parameters.xml file in it and parameters file should declare parameter "IIS Web Application Name" so that MSDeploy can override this parameter to deploy WebApp package to Azure Website.
But overriding should only be true for MSBuild generated package which contains parameter.xml file in it. For other package like compressing build output of Webapp to zip file , parameters file should be optional.

we have fixed above issue as part of following PR
Parameter file optional

After next deployment of task , there will be no need to explicitly define parameters.xml in web app package.

[buckh]

When will we deploy the updated task?

[Ajay-MS]

@buckh Deployment will start from next week so approx time is nearly one week.

[chrisaut]

I'm also seeing this (just now). I guess it hasn't been deployed yet?

TBH the whole process of getting an aspnet core app published and even just built/tested in VSTS has been less than stellar. I keep running into these issues left and right. Everything worked so nicely with "classic" aspnet apps...there are tasks that are named sensibly and it "just works".

net core one needs to manually add cmd line build steps such as dotnet restore and dotnet publish....instead of the nicely named nuget restore. For test one has to target the project.json files instead of the sln. For dotnet restore in order to be somewhat faster (it seems very slow to me) an environment variable needs to be manually defined so it forgoes the initial cache setup. I'm sure I forgot others.

Can we please have dedicated (named) tasks for these .net core tasks that just default to doing the right thing?

I understand this is early, but it's now my third day trying to setup a nice CI integration with it. It should have taken a few hours at most.

[qin-nz]

@chrisaut ,it is really nicely using classic ?
I try the classic mode and it won't take the app offline which case deploy failure.

[chrispat]

@chrisaut once the tooling settles we will build out tasks that make sense. However, during these alpha and beta experiments with .NET Core we would have ended up creating things that would have been broken multiple times and because we also ship on-prem customers would have had tasks in TFS back in March that would have been completely broken and would be for the next 5 - 10 years until they upgrade.

We have documented how to build and deploy an app here https://www.visualstudio.com/en-us/docs/build/apps/aspnet/aspnetcore-to-azure.

[kmkumaran]

The changes have been deployed. Please feel free to report us back if you still see issue with parameters file.

[mayeager22]

I am getting "System.Exception: Error: Source does not support parameter called 'IIS Web Application Name'. Must be one of ()." when trying to use MSDeploy (through the WinRM - IIS Web App Deployment task) on a zip file that was zipped up from the contents of "dotnet publish".

I do not have a Parameters.xml file, but reading this thread, it seems like I am not supposed to need one. Can someone clarify?

[Ajay-MS]

@mayeager22

Can you confirm if your webapp package that being generated using dotnet publish contains a parameters.xml file or not ?

If a parameters file is present task tried to override name of parameter to deploy webapp package at correct website.
Override parameter WebApp Name

So there should be a parameter with name "IIS Web Application Name" to be declared in parameters.xml . If you still face any issue please share debug logs [ You can enable debug log by adding system.debug variable with value true]

[mayeager22]

4_Deploy IIS App FDeploymentInstallsSupportServicesSupportService.txt

I have tried a number of combinations:

1) Adding a Parameters.xml file in the *zip file, but the task could not find it, so I tried:

2) Putting the Parameters.xml file separately on the target server, it found it, but then I got this error:
System.Exception: Error: The parameter 'IIS Web Application Name' has already been defined., so I tried

3) Removing the Parameters.xml file from the zip and still calling it from the separate location on the target server and that is when I started getting this error:
System.Exception: Error Code: ERROR_SITE_DOES_NOT_EXIST

I will turn on debugging and try again.

Update: Logfile with debugging on attached.

[Ajay-MS]

@mayeager22

Can you share your parameters.xml file.Have you manually added paramters.xml file to zip?

Since task is overriding parameter "IIS Web Application Name" , it should be declared first. So parameters.xml file that you are adding to *zip file should declare parameter.

Sample

<parameters>
  <parameter name="IIS Web Application Name" defaultValue="RandomWebApp" tags="IisApp">
    <parameterEntry kind="ProviderPath" scope="IisApp" match="^...\\PackageTmp$" />
    <parameterEntry kind="ProviderPath" scope="setAcl" match="^...\\PackageTmp$" />
  </parameter>
</parameters>

Don't use param file with setParameter tag as parameter is not yet declared as follow

Still if you face issue, we can have a quick call to resolve it.

[mayeager22]

I have tried 2 different contents for Parameters.xml from the comments above

1) <parameters> <parameter name="IIS Web Application Name" defaultValue="SupportServices" tags="IisApp" /> </parameters>

2) <parameters> <parameter name="IIS Web Application Name" defaultValue="..." tags="IisApp" /> </parameters>

And both have given the same System.Exception: Error Code: ERROR_SITE_DOES_NOT_EXIST

I have tried to run msdeploy from the command line and am getting the same error, so I am starting to think my zip file might not be from the correct level. I have zipped it up from "publish" of the "dotnet publish -c Release" command.

So the contents of that zip would look just like what is in the inetpub/SupportServices folder on the filesystem, but perhaps that is not correct?

[Ajay-MS]

@mayeager22

Either put content at root folder or use following property in parameters.xml.

<parameterEntry kind="ProviderPath" scope="IisApp" match="^inetpub\\SupportServices$" />

[mayeager22]

@Ajay-MS

When you say content at root folder, do you mean the contents of the publish directory? That is how I have it. If I unzip SupportService.zip, I get the following under it:

refs
runtimes
Views
wwwroot
*dll
web.config

The property you wanted me to try did not come through in your comment.

[Ajay-MS]

@mayeager22

Yes content of publish directory. Can you share your email Id so that I can send you invite for call and will look into the issue.

[mayeager22]

@Ajay-MS

Yes, please contact me at [email protected].

[melborp]

Looking at the source at MsDeployOnTargetMachines.ps1
in the 1.3.0 task, it seems that if the source is web deploy package then the override parameters always has name="IIS Web Application Name",value="SiteName" in $overRideParams from Compute-MsDeploy-SetParams

It assumes that web deploy package always has parameters.xml file, even though for .net core approach you only do simple content zip.

The version in github is newer. https://github.com/Microsoft/vsts-rm-extensions/blob/master/Extensions/IISWebAppDeploy/Src/Tasks/IISWebAppDeploy/MsDeployOnTargetMachines.ps1
This works. When is it scheduled for release?

[Ajay-MS]

@melbrop

'IIS Web Application Name' parameter is being overridden only if package is being generated by msdeploy in such a format that it can deploy package with dest:auto. So parameters should specify destination so its being overridden. In case of Asp.net core we just package build output.

This feature will be released within one week approx.

[taspeotis]

I've left a comment on a related issue here, but basically, assuming Parameters.xml means -dest:auto is an imperfect solution.